Apparently Tom Oehser <[EMAIL PROTECTED]> wrote:
>> i wanted to replace ash with bash, why wouldn't it work?
> Um, bash is too stupid to handle:
> if [ ~`hostname` = ~6M ];then;NM=tomsrtbt;else;NM=`hostname`-tomsrtbt;fi
if [ ~`hostname` = ~6M ];then NM=tomsrtbt;else NM=`hostname`-tomsrtbt;fi
^^^ ^^^
... works just fine (under bash 2.x, I didn't test on bash 1.1x)
Both bash and pdksh seem to require the space after the then and
else tokens. In some ways that make sense since then, else, and
fi are not commands, they are are delimiter tokens.
As you say, sh (the whole Bourne family of shells) have many
quirks in their parsers. It sounds like ash is using a very old
parser (probably more closely emulating the original Bourne,
possibly derived from the same code) while bash, Korn and the
pdksh are using a newer parser (which I think conforms more closely
to the POSIX specs and is probably somewhat more efficient and
maintainable).
Oddly enough the Debian ash (0.3.5-11) seems to also complain
about your sample in exactly the same was as bash and pdksh.
That version of ash accepts my version without complaint.
Maybe you should try the spaces with your version.
> It is only supported and tested with ash. There are more quirks than you
> would think between bourne shells, it turns out that usually ash is fairly
> good at running bash scripts, which is one of the reasons I chose it, it
> is kind of funny to have bash fail on an ash script. Um, it looks like
> bash doesn't allow you do do if/then/else all on the same line... how
> lame. Just keep ash? Split that line and it will work until the next
> broken thing... It should work, you know. Submit a bug to GNU. It works
> if I replace all the semicolons with newlines, which means bash should
> work. Duh.
I don't think this is GNUs bug. I suspect that it is a bug in
ash. then, else, fi, do, done, in and esac are not commands; they
are delimiters. It probably is illegal to follow them with a
command separator (; && ||) which is exactly what the error
message I get is saying.
(One of the quirks in bash2 vs. bash1 was this failure:
{ echo foo; echo bar }
... no longer works. It echos a "}" character and keeps the
command group open. That's because the close brace is a delimiter
and NOT a command separator. So this is required:
{ echo foo; echo bar; }
... (or a newline after bar, of course).
NOTE: I'm NOT a qualified language lawyer. I don't write parsers,
I've never written a yacc grammar nor a lex scanner. I'm just
saying what I've found through too many years of sh usage and
trying to describe it as I understand it. (Thus the destinction
I make between "separators" and "delimiters" may be completely
inaccurate --- though it does help me and my students get shell
code written without too many surprises.
Here's an ugly bug I came across:
( case $OSTYPE in linux*) echo yay;; esac; )
... in an ealier version of bash it would trip over that
")" in the case pattern. That would close the sub process
and give an error. They seem to have fixed that by bash 2.04
(it also works in ash and pdksh).
> -Tom
--
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
