Zsh Mailing List Archive
Messages sorted by:
Re: sh compatibility again :->
- X-seq: zsh-workers 1938
- From: Zoltan Hidvegi <hzoli@xxxxxxxxxx>
- To: borsenkow.msk@xxxxxx
- Subject: Re: sh compatibility again :->
- Date: Mon, 12 Aug 1996 04:18:57 +0200 (MET DST)
- Cc: zsh-workers@xxxxxxxxxxxxxxx
- In-reply-to: <Pine.SV188.8.131.520808183228.608E-100000@itsrm1> from Andrej Borsenkow at "Aug 8, 96 07:13:48 pm"
Andrej Borsenkow wrote:
> 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.
I copied the behaviour of bash here. pdksh also behaves this way.
> 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).
OK. I've changed that. set - will be the same as set +xv and
set - args will be the same as set +xv -- args. This will not be
documented since it is just an obsolecent compatibility feature and
noone should use that.
> 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.
I'll try to write a configure check for the echo style of /bin/sh and use
Messages sorted by: