Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-Id: <5.1.0.14.2.20021023172357.01fdfaf0@pop3.cris.com> X-Sender: rrschulz AT pop3 DOT cris DOT com Date: Wed, 23 Oct 2002 17:39:42 -0700 To: cygwin AT cygwin DOT com From: Randall R Schulz Subject: RE: "==" operand not found In-Reply-To: <7BFCE5F1EF28D64198522688F5449D5AD63A6D@xchangeserver2.stor igen.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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/