Mail Archives: cygwin/2002/10/23/20:38:47
Scott,
At 17:12 2002-10-23, Scott Prive wrote:
> > -----Original Message-----
> > From: Randall R Schulz [mailto:rrschulz AT cris DOT com]
> > Sent: Wednesday, October 23, 2002 7:30 PM
> > To: cygwin AT cygwin DOT 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/
- Raw text -