From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by coral.primenet.com.au (8.7.5/8.7.3) with ESMTP id BAA03206 for ; Fri, 9 Aug 1996 01:50:54 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id LAA10284; Thu, 8 Aug 1996 11:43:23 -0400 (EDT) Resent-Date: Thu, 8 Aug 1996 11:43:23 -0400 (EDT) Date: Thu, 8 Aug 1996 19:13:48 +0400 (MOW) From: Andrej Borsenkow X-Sender: bor@itsrm1 Reply-To: borsenkow.msk@sni.de To: Zoltan Hidvegi cc: Zsh workers list Subject: sh compatibility again :-> In-Reply-To: <199607312111.XAA25395@bolyai.cs.elte.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"0qjYn2.0.dW2.QiW2o"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1933 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Wed, 31 Jul 1996, Zoltan Hidvegi wrote: > > Zsh can emulate the POSIX shell and the Korn shell quite well when it is > invoked as sh or ksh respectively. /bin/sh can be safely linked to zsh. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I wouldn't put it in. I dared to link zsh to /bin/sh and reboot the system. It did come up - without /proc, /dev/fd and network ;-< Here are some points, where zsh choked. 1. It doesn't like malformed constructs like A="`cat /some/file" (note missed backtick) zsh tries to parse command substitution behind closing double-quote, and ends up with `missing "' at the end of script. Our /bin/sh stops at closing double-quote. In POSIX the result is undefined - thus, techically neither violate it. 2. Our /bin/sh silently ignores break's in case statement (I mean it; it doesn't break out of case). zsh loudly complaints (well, it is rather cosmetic). 3. The last bit, when I stopped this experiment. Our sh starts complex command with redirections in subshell; that is while read; do .... done < /some/file is evaluated in subshell. The problem is, that some scripts use EXIT!! rather than break to such loop. Well, I could do nothing against it. These are just FYI; in no way would I suggest to mimic every historical (broken?) sh; but it still means, that it is *not* safe to link /bin/sh to zsh on *every* system. Probably, statement about POSIX conformance is enough? But the following things could probably be fixed 4. Traditional /bin/sh interprets `set -' as set +xv. It could be well undocumented (it is not on our system) but still is so. Could anybody test it on more than one systems? zsh silently sets positional parameters to null. At least on our system many startup scripts include set -$DEBUG at the script start (intent is to set DEBUG=x somewhere in /etc/rc2 to see what's going on). Under zsh, script just loses its arguments and ends up with error (it is SVR4 startup scripts are called with /bin/sh /etc/rc2.d/S*something start if `start' is not there, script just exits). 5. Currently zsh sets BSD_ECHO when running as sh. Our sh does support escapes in echo; I recall that SCO sh does it as well. I don't know about others. What about relaxing it? If scripts doesn't rely upon escapes in echo, it would make no harm. Sorry for long mail. Actually (apart from echo) I found *no* problems, caused by zsh; so it is more our /bin/sh to blame ;) greetings ------------------------------------------------------------------------- Andrej Borsenkow Fax: +7 (095) 252 01 05 SNI ITS Moscow Tel: +7 (095) 252 13 88 NERV: borsenkow.msk E-Mail: borsenkow.msk@sni.de -------------------------------------------------------------------------