Re: sh compatibility again :->

[Zoltan Hidvegi <hzoli@xxxxxxxxxx>]

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
that.

Zoltan