RE: "==" operand not found

[Randall R Schulz <rrschulz at cris dot com>]

Scott,

At 17:12 2002-10-23, Scott Prive wrote:
> > -----Original Message-----
> > From: Randall R Schulz [mailto:rrschulz@cris.com]
> > Sent: Wednesday, October 23, 2002 7:30 PM
> > To: cygwin@cygwin.com
> > Subject: Re: "==" operand not found
> >
> >
> > Nitin,
>
> > You're most likely accustomed on your Linux system to "/bin/sh" being 
> > BASH.  On Cygwinm /bin/sh is ASH, and it is far more minimal in 
> > its  implementation of the POSIX shell standard,
> This makes me ask a few questions..
>
> 1) Why is ash the default? At least on UNIX systems that use "true" sh -- 
> usually just /bin/bash in /bin/sh compatibility mode -- I can understand 
> THAT because plain sh is, well... "traditional". :-
Ours is not to question why, ours is but to contribute or make do with 
what's given.

But I believe the reason "/bin/sh" under Cygwin is ASH is due to its light 
weight, low overhead and, most of all, I believe, rapid start-up. That 
makes it well-suited to running scripts and especially appropriate for 
sub-shells launched by "make" and other tools that use the "system (3)" 
library call to invoke sub-processes.


> )  Bash2 seems closer to most expectations; ash doesn't seem to add any 
> value.
Expectations are made to be broken, eh?


> 2) How would a user know they are defaulting to ash?
>         a) The first place I would look is /etc/password for my default, 
> which "clearly" states /bin/bash (at least for me it does).
And if /etc/password had anything to do with running a script or even with 
launching local interactive Cygwin sessions, that observation might be 
relevant, but it is not involved and hence irrelevant.

Since I don't use this aspect of Cygwin, I don't know for sure, but I think 
/etc/passwd is used to select a shell for remote access via SSH.


>         b) Next I would ls -l on /bin/whatever to see if it is a symbolic 
> link to something else. Even on NTFS, /bin/sh or /usr/bin/sh do not 
> appear to be links.
And?

Unix and POSIX programming environments don't promise the kind of 
"write-once-run-anywhere" property that Java does (or did). Look around and 
you'll see lots of scripts that use "uname" to condition details of their 
operation, when necessary. In the case of "features" like non-standard 
operator synonyms, I think it's best simply to avoid them. Personally, I 
have a pretty fast system, and I often just use "/bin/bash" explicitly in 
the #! lines, but even that is risky, since that executable isn't 
guaranteed to exist (the whole #! thing, lacking PATH searching, is a 
portability problem).


The bottom line is that your script isn't portable. It's written to rely on 
a BASH feature that is not a stipulated part of the standard for shells. 
The bug was always there, but remained latent in systems where /bin/sh was 
BASH and became manifest when it was brought to a system where /bin/sh was 
a more mininal shell.


> -Scott

Randall Schulz
Mountain View, CA USA


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/