Apparently Tomi Ollila <[EMAIL PROTECTED]> wrote:
> Monday Jun 19 09:13:15 +0200 2000 Robert Seidner <[EMAIL PROTECTED]>
>wrote:
>> At 04:20 19.06.00 +0000, you wrote:
>>> if [ ~`hostname` = ~6M ];then;NM=tomsrtbt;else;NM=`hostname`-tomsrtbt;fi
>>>
>> It works, if you remove 2 semicolons:
>>
>> if [ ~`hostname` = ~6M ];then NM=tomsrtbt;else NM=`hostname`-tomsrtbt;fi
> That was a good observation...
> another possibility:
> [ ~`hostname` = ~6M ] && NM=tomsrtbt || NM=`hostname`-tomsrtbt
> This maybe looks a bit cleaner (if anybody cares anyway).
>> Robert
> Tomi
I vastly prefer this latter syntax. However, it isn't exactly
the same. If the hostname is not equal OR if he
NM=.... expression (the variable assignment) failed, then the
last command is issued. I don't know of a way for a variable
assignment to fail in this case (unless the NM variable was
marked read-only; hmmm.... see below).
I just want to warn that:
if somecommand then yaycommmand; else naycommand; fi
... is NOT actually equivalent to
somecommand && yaycommand || naycommand
... for all cases. If "somecommand" returns no error and
"yaycommand" fails, then we get different behavior from these
two examples.
Read-only variables.
Starting shells and setting NM to read-only (with the readonly
command in ash, the declare command in bash and the typeset
command in pdksh!) issuing the following:
NM=foo && echo yay || echo boo
... gives these results:
bash 2.04 gives the error about it being read only, and then
echo's "yay", ash and pdksh give error messages but don't
echo either "yay" nor "nay" (that's weird and probaby they
are all bugs).
(Yes, I sometimes teach shell scripting. No, I never wanted to
become an expert on its quirks. No, I don't have anything against
sh, ash, bash, ksh, pdksh, zsh, etc. --- I do agree with T
Christainson on csh programming; it is harmful and no one should
do that).
While we're on the topic of weird shell quirks, try the following
under your favorite Bourne family shell:
unset foo
echo yay | read foo
echo $foo
... Under new Korn shell (ksh '93) and under zsh this works
as one would like. The variable foo is set to "yay."
Under pdksh, bash (1 and 2), and ash, foo is unset.
It should be obvious that we create a subshell whenever
we encounter a | operator in sh (any sh). That is to say
that there is a fork()/exec() --- or at least a fork()
going on. The question becomes, which side of the pipe
operator does the shell create it's subshell on.
Clearly, from this experiment, there are a couple of newer
shells that create the subshell on the left of the pipe
(where I think it should be) while most shells do it on
the right.
In this example, and in any case where we're just
setting a single value the point is moot. We can just
use an assignment and "substitution" operators
(backticks or $(....)).
However if we're trying to use IFS and/or set multiple
shell values then we have to do alot more scripting
(under the bash, ash, pdksh shells) to get the
simple parsing and multiple assignments done in
our current shell context. That's a case where
we're better off either using an eval (and
having our subshell spit out a bunch of VAR=VAL
assignments), or doing all the work in the
subshell (and not saving/returning the values at
all).
--
Jim Dennis Technical Research Analyst Linuxcare, Inc.
[EMAIL PROTECTED], http://www.linuxcare.com/
415 740-4521 415 701-7457 fax
Linuxcare: Support for the Revolution
