[lfs-support] Possible Syntax Error in Current "Package User" Hint Build Script
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
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