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
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
