Re: [lfs-support] Possible Syntax Error in Current "Package User" Hint Build Script[RESOLVED]
On 10/12/2013 11:27 AM, Dan McGhee wrote: > I'm melding my build script to the current one from this hint. I've > found a possible syntax error and want to see if my thinking is > correct. Since I've been monitoring this list closely again, i.e.; the > last three weeks, I've not seen anyone who has had a problem running > this script. But I think that few people build this way. :) > > Here is the line in question: > > cd "$HOME/xxxbuild/yyysrc" && srcdir="$(pwd)" || exit 1 > > > If <&&> and <||> are logical operators, shouldn't the whole command be > enclosed in double brackets, > [[ command1 && command2 || command3 ]]? The other syntax I know would be > [ command1 -a command2 -o command3 ]. > > Of course, this is all predicated on the use of <&&> and <||> as logical > operators. But if they're not, I don't understand the command. > > Comments? Answers? Recommendations? Rants? > > Thanks, > Dan > I ran this script for two different packages in Ch. 6 and it behaved flawlessly. Apparently Ken Moffat was right when he commented that the syntax function of gedit might be confused. Thanks to all who responded. This was a good learning and "memory refreshment" situation. Speaking of learning situations. I just learned to make sure that there's an "escape route" in scripts run by root. I wrote and ran a script to allow "follow-on" package users to write to directories created by an earlier user. (NOTE: This happens in the Package User hint.) I ran the script and forgot to pass an argument. I just hosed my LFS build. Oh well. I needed to test something else before Ch. 6 anyway. Thank goodness I backed up the tool chain. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Possible Syntax Error in Current "Package User" Hint Build Script
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
> .
Goodness! I'm using ubuntu as my host system. Hope tar works!
>
>> 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 and . 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 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, albei
Re: [lfs-support] Possible Syntax Error in Current "Package User" Hint Build Script
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.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Possible Syntax Error in Current "Package User" Hint Build Script
Hi Dan,
$(...) executes the command within the brackets. It is the same as
having `pwd` (they are backticks).
The reason for the double quotes around the $(pwd) is in case the
current directory name has spaces in it (or anything that is contained
in the $IFS variable to be exact - IFS=the internal field separator).
logically, that line could be written as
if cd "$HOME/xxxbuild/yyysrc"
then
srcdir="$(pwd)"
else
exit 1
fi
hope this clarifies a little more and doesn't cause even more confusion.
regards
Chris
On 12 October 2013 22:59, Dan McGhee wrote:
> On 10/12/2013 03:01 PM, Ken Moffat wrote:
>> On Sat, Oct 12, 2013 at 01:36:04PM -0500, Dan McGhee wrote:
>>> I suppose that the most practical thing for me to do is "jump into" Ch.
>>> 6 and build with the script in the hint as it exists now. I could
>>> "pause" at the end of this command to see what was happening. However,
>>> in a previous life I was an engineer (Oh, no!!) and my OCD has kicked
>>> in. First of all, I want to understand everything the script is doing
>>> and when I looked at it in my text editor (gedit in Ubuntu) I saw a
>>> problem. With that editor the only valid thing in pick is what's
>>> between two quotes in an command. Anything else in pink has
>>> something wrong in front of it--a syntax error. In gedit everything in
>>> the script after <"$(pwd)"> is pink. There's something wrong, and I'd
>>> like to find it before I start.
>>>
>> 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.
>>
>> It's also, of course, possible that there is an apparent error
>> _before_ this which makes the highlighter confused.
>>
> That was another one of my first thoughts--of course that begs the
> question of how many _first_ thoughts can there be. But I'll be
> hornswaggled if I can find anything.
>
> The package users hint now uses a build.conf file to input the specific
> commands from the book for each package. The line in question first
> appears in a function call to add patches if required. Let me repeat
> the whole call for clarity.
>
> -patch)
>cd "$HOME/xxxbuild/yyysrc" && srcdir="$(pwd)" || exit 1.
>patch_commands # no logging for patch necessary
> #test_pipe
> ;;
>
> Everything just changed! I had a moment of clarity. I can't believe it.
>
> 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.
>
> 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
--
_ o , ,
/ | | |_| / \_/ \_| |
\__/ \/ \/ |/ \/ \/ \/|/
(|
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information p
Re: [lfs-support] Possible Syntax Error in Current "Package User" Hint Build Script
On 10/12/2013 03:01 PM, Ken Moffat wrote:
> On Sat, Oct 12, 2013 at 01:36:04PM -0500, Dan McGhee wrote:
>> I suppose that the most practical thing for me to do is "jump into" Ch.
>> 6 and build with the script in the hint as it exists now. I could
>> "pause" at the end of this command to see what was happening. However,
>> in a previous life I was an engineer (Oh, no!!) and my OCD has kicked
>> in. First of all, I want to understand everything the script is doing
>> and when I looked at it in my text editor (gedit in Ubuntu) I saw a
>> problem. With that editor the only valid thing in pick is what's
>> between two quotes in an command. Anything else in pink has
>> something wrong in front of it--a syntax error. In gedit everything in
>> the script after <"$(pwd)"> is pink. There's something wrong, and I'd
>> like to find it before I start.
>>
> 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.
>
> It's also, of course, possible that there is an apparent error
> _before_ this which makes the highlighter confused.
>
That was another one of my first thoughts--of course that begs the
question of how many _first_ thoughts can there be. But I'll be
hornswaggled if I can find anything.
The package users hint now uses a build.conf file to input the specific
commands from the book for each package. The line in question first
appears in a function call to add patches if required. Let me repeat
the whole call for clarity.
-patch)
cd "$HOME/xxxbuild/yyysrc" && srcdir="$(pwd)" || exit 1.
patch_commands # no logging for patch necessary
#test_pipe
;;
Everything just changed! I had a moment of clarity. I can't believe it.
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.
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
Re: [lfs-support] Possible Syntax Error in Current "Package User" Hint Build Script
On Sat, Oct 12, 2013 at 01:36:04PM -0500, Dan McGhee wrote:
>
> I suppose that the most practical thing for me to do is "jump into" Ch.
> 6 and build with the script in the hint as it exists now. I could
> "pause" at the end of this command to see what was happening. However,
> in a previous life I was an engineer (Oh, no!!) and my OCD has kicked
> in. First of all, I want to understand everything the script is doing
> and when I looked at it in my text editor (gedit in Ubuntu) I saw a
> problem. With that editor the only valid thing in pick is what's
> between two quotes in an command. Anything else in pink has
> something wrong in front of it--a syntax error. In gedit everything in
> the script after <"$(pwd)"> is pink. There's something wrong, and I'd
> like to find it before I start.
>
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.
It's also, of course, possible that there is an apparent error
_before_ this which makes the highlighter confused.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Possible Syntax Error in Current "Package User" Hint Build Script
On 10/12/2013 11:56 AM, Pierre Labastie wrote:
> Le 12/10/2013 18:27, Dan McGhee a écrit :
>>
>> Here is the line in question:
>>
>> cd "$HOME/xxxbuild/yyysrc" && srcdir="$(pwd)" || exit 1
>>
>>
>>
>> "Change to the package build directory IF AND ONLY IF the package source
>> directory is the same as the current directory OR exit with a status of 1."
>>
>> In typing this I've also generated a question about the "'s, but it's
>> the use of the logical operators, which I've capitalized, that has my
>> attention. Here's the question:
>>
>> If <&&> and <||> are logical operators, shouldn't the whole command be
>> enclosed in double brackets,
>> [[ command1 && command2 || command3 ]]? The other syntax I know would be
>> [ command1 -a command2 -o command3 ].
>>
>>
> Well, dunno if this is rant, recommandation or comment, but you should have a
> look
> at the paragraph about "Lists" in the bash manpage.
> It's all explained there, much better than I would.
>
> But now a rough answer: the meaning of this line is:
> change directory to ${HOME}/blah. If that succeeds, set the srcdir variable
> to the
> full path to that directory. If either of the preceding commands fails then
> exit with error code.
>
> Regards
> Pierre
Thanks, Pierre.
I suppose that the most practical thing for me to do is "jump into" Ch.
6 and build with the script in the hint as it exists now. I could
"pause" at the end of this command to see what was happening. However,
in a previous life I was an engineer (Oh, no!!) and my OCD has kicked
in. First of all, I want to understand everything the script is doing
and when I looked at it in my text editor (gedit in Ubuntu) I saw a
problem. With that editor the only valid thing in pick is what's
between two quotes in an command. Anything else in pink has
something wrong in front of it--a syntax error. In gedit everything in
the script after <"$(pwd)"> is pink. There's something wrong, and I'd
like to find it before I start.
I read the bash man page about Lists. Thanks for pointing that out.
I'm thinking that the syntax I was thinking of was for running tests.
And the plain language translation that you used is very close to my
own. But let's take translation apart list by list and operator by
operator. I'm going to be very pedantic and put in the bash man page
words using what's above rather than command{1,2}.
is executed if and only if cd "$HOME/blah" returns an
exit status of zero. (The exit status of .)
Now, will be executed if and only if the exit status of
is non-zero. And since the exit status of the list
depends on the status of the last command executed it will always be zero.
Therefore, <|| exit 1> becomes irrelevant because of the existence of
$HOME/blah. I don't know if gedit is "smart enough" to pick up errors
in logic or not, but it tells me that something is not right.
The quotation marks, "", also have my attention. I know that different
script writers do things differently. I use them only when syntax
requires it or when talking about an array. Maybe it's me who's
ranting. :)
I'm also thinking in terms of testing and maybe I should just look at
the commands themselves.
Thanks again,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Possible Syntax Error in Current "Package User" Hint Build Script
Le 12/10/2013 18:27, Dan McGhee a écrit :
> I'm melding my build script to the current one from this hint. I've
> found a possible syntax error and want to see if my thinking is
> correct. Since I've been monitoring this list closely again, i.e.; the
> last three weeks, I've not seen anyone who has had a problem running
> this script. But I think that few people build this way. :)
>
> Here is the line in question:
>
> cd "$HOME/xxxbuild/yyysrc" && srcdir="$(pwd)" || exit 1
>
> This patter occurs a number of times in the script and, therefore, I
> think it's important. For this question the references to what actually
> exist are not relevant. It's only the syntax. In attempting to
> understand what this statement is doing, I've come up with this plain
> language interpretation.
>
> "Change to the package build directory IF AND ONLY IF the package source
> directory is the same as the current directory OR exit with a status of 1."
>
> In typing this I've also generated a question about the "'s, but it's
> the use of the logical operators, which I've capitalized, that has my
> attention. Here's the question:
>
> If <&&> and <||> are logical operators, shouldn't the whole command be
> enclosed in double brackets,
> [[ command1 && command2 || command3 ]]? The other syntax I know would be
> [ command1 -a command2 -o command3 ].
>
> Of course, this is all predicated on the use of <&&> and <||> as logical
> operators. But if they're not, I don't understand the command.
>
> Comments? Answers? Recommendations? Rants?
>
> Thanks,
> Dan
Well, dunno if this is rant, recommandation or comment, but you should have a
look
at the paragraph about "Lists" in the bash manpage.
It's all explained there, much better than I would.
But now a rough answer: the meaning of this line is:
change directory to ${HOME}/blah. If that succeeds, set the srcdir variable to
the
full path to that directory. If either of the preceding commands fails then
exit with error code.
Regards
Pierre
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
[lfs-support] Possible Syntax Error in Current "Package User" Hint Build Script
I'm melding my build script to the current one from this hint. I've found a possible syntax error and want to see if my thinking is correct. Since I've been monitoring this list closely again, i.e.; the last three weeks, I've not seen anyone who has had a problem running this script. But I think that few people build this way. :) Here is the line in question: cd "$HOME/xxxbuild/yyysrc" && srcdir="$(pwd)" || exit 1 This patter occurs a number of times in the script and, therefore, I think it's important. For this question the references to what actually exist are not relevant. It's only the syntax. In attempting to understand what this statement is doing, I've come up with this plain language interpretation. "Change to the package build directory IF AND ONLY IF the package source directory is the same as the current directory OR exit with a status of 1." In typing this I've also generated a question about the "'s, but it's the use of the logical operators, which I've capitalized, that has my attention. Here's the question: If <&&> and <||> are logical operators, shouldn't the whole command be enclosed in double brackets, [[ command1 && command2 || command3 ]]? The other syntax I know would be [ command1 -a command2 -o command3 ]. Of course, this is all predicated on the use of <&&> and <||> as logical operators. But if they're not, I don't understand the command. Comments? Answers? Recommendations? Rants? Thanks, Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
