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

Dan McGhee beesnees at grm.net
Sat Oct 12 17:41:53 PDT 2013


On 10/12/2013 05:48 PM, Ken Moffat wrote:
> 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
> <joke/>.
Goodness! I'm using ubuntu as my host system. Hope tar works! <joke/ | joke>
>
>> 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 :)
That's a real lesson.  I know.
>
>   But it's all about learning.
Amen!!  And it's the learning that has motivated me to ask my question.  
Some of the people who have helped me on this may roll their eyes when 
they read what I'm about to say.  In my build script, I don't intend to 
use the construction I asked about.  My version successfully does what 
this command indicates.  I learned in the Navy, "If it ain't broke, 
don't fix it."  I'm incorporating the "new stuff" in the package users 
hint into my build script.  Mine stops to review logs and recovers from 
failed <make> and <install>.  There are a lot of little, nit-picky and 
naggy things in package users that will cause make and install to fail. 
It's a real drag to start from scratch for these things.  My script is 
designed to make the process less frustrating.  Rob Taylor has recently 
done some work with wrappers and scripts to further reduce the frustration.

But it's the learning that motivated me to ask my question.  I too have 
had problems with parentheses.  And just like your experience with 
firefox, I like to learn what the _precise_ use of something is.  For 
example, many people will say that <command1 && command2> means "run 
command2 after command1.  And that's generally how it works.  The 
precise meaning is run command2 if and only if command1 has an exit 
status of 0.  That's a real, albeit purely logical and subtle, 
difference.  I've had problems before when using the "common" 
interpretation.  Ergo, I wanted to know why "$(pwd)" is not so good 
syntax.  I have to say it that way because I don't know if the script 
runs "as is."

But, in the final analysis, I fully intend to build the first package of 
Ch 6 with the files from the hint as they currently exist.  Gedit could 
still be the culprit.  I have no knowledge if builds using the current 
scripts are successful.  If the syntax is wrong, the script will abort.  
If it's OK, the build will succeed. If it aborts, although I don't know 
exactly why, I know how to "fix it." (Ooooops! I used parentheses.  Hope 
you can read this in the right color.  <another joke>

Thanks again, Ken.
Dan




More information about the lfs-support mailing list