[lfs-support] Possible Syntax Error in Current "Package User" Hint Build Script

Ken Moffat zarniwhoop at ntlworld.com
Sat Oct 12 15:48:42 PDT 2013

On Sat, Oct 12, 2013 at 04:59:04PM -0500, Dan McGhee wrote:
> On 10/12/2013 03:01 PM, Ken Moffat wrote:
> >>
> >   Maybe the syntax highlighting in that version of gedit is missing
> > or broken.  Try vim and see how it looks ('syntax on' in ~/.vimrc or
> > /etc/vimrc).  I use a black background, with ':colorscheme elflord'
> > I didn't see anything unusual when I pasted that line into a script.
> >
> >   Not that vim's highlighting is perfect, it occasionally gets
> > confused but usually only when I scroll a long way through a long
> > script.
> That was one of my first thoughts and so I loaded up a script that I 
> knew worked and looked at it.  It was fine.  BTW it was the build script 
> you helped me with a few years ago.  You taught me how to extract the 
> package name from a tar archive not knowing what the final extender 
> was--gz, tz, bz, bz2.  If you're interested, I've got that down to one 
> line now instead of four since tar -xf works for all the stuff that I've 
> tested.

 Yeah - I think I've still got that in my functions.  As you say, it
hasn't been needed for a few years.  The problem is knowing when the
last system with an old version of tar has gone.  I know, I'll claim
I'm retaining it in case I ever have to build from a debian system

> My thought was, "If there's something wrong in that line, the cd... 
> line, then if I edit it, I might get all the pretty colors back in the 
> rest of the script.  The offensive character I found when I removed it 
> is the " following $(pwd).  When I remove the " gedit indicates that the 
> syntax is OK.  The problem, and it's not really a problem, is that this 
> exact line is the first in every function call of the script for _make), 
> _check) and _install).  I understand the command because it puts you in 
> the right directory to run ./configure, make and install.
> When I first saw this line, I thought that the purpose of all the " was 
> to keep the shell from expanding things execpt a few special 
> characters.  As a matter of fact, after I did some more editing just 
> know, I discovered that it's the combination of () and "" with $pwd that 
> causes the problem.  Either set of characters *used alone* works.  In 
> combination everything after ...d)" including the " is pink in gedit.  I 
> know that last was a highly technical statement of the analysis. :)
> I wonder if the first " escapes the first ( and the last " is seen as an 
> unresolved quote.  Well, at least I found the problem, even though the 
> syntax sin escapes me--no pun intended, but when I read it, it's not a 
> bad one.
> The script has been recently edited.  I don't know how recently tested.  
> Hopefully, we can get the situation corrected.
 Parentheses can be a pain.  In metaflac all tag values are input in
double-quoted strings, but I've never managed to get parentheses in
a tag - I did once manage \( which wasn't at all what I wanted, but
every other attempt got an error report from bash.

 Similarly, a parenthesised subshell which is commented by # in a
here document (e.g. the command to get the libxul sdk in firefox's
mozconfig in the BLFS book) *is* evaluated by bash - took me a long
while to work out where the message :

 Package libxul was not found in the pkg-config search path.
 Perhaps you should add the directory containing `libxul.pc'
 to the PKG_CONFIG_PATH environment variable
 No package 'libxul' found

was coming from when I built firefox without xulrunner :)

 But it's all about learning.

das eine Mal als Tragödie, dieses Mal als Farce

More information about the lfs-support mailing list