zsh/bash incompatibilities

zsh/bash incompatibilities

[Matthias B.]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

I've encountered several things where zsh's behaviour (in sh-mode) differs
from that of bash (in sh-mode). 

The attached script demonstrates the differences. When /bin/sh is bash,
the output is

ab
\y
$


When /bin/sh is zsh, the output is

a
b
y
\44


I'm undecided about which \ treatment inside of $'..' I prefer, so I guess
looking to what POSIX says is best. Regarding zsh's refusal to interpret
octal escapes that don't start with 0, I find that very annoying and it's
certainly not what most people expect. There are scripts out there that
will fail with sh=zsh because of this. I think this should be changed
(regardless of what POSIX says).

MSB

-- 
Indecision is the key to flexibility.


[-- Attachment #2: bash_zsh_differences --]
[-- Type: text/plain, Size: 50 bytes --]

#!/bin/sh
echo $'a\
b'

echo $'\y'

echo -e '\44'

Re: zsh/bash incompatibilities

[DervishD]

    Hi Matthias :)

 * Matthias B. <msbREMOVE-THIS@winterdrache.de> dixit:
> I'm undecided about which \ treatment inside of $'..'

    Mmm, AFAIK, POSIX doesn't specify $'...' quoting (at least SUSv3
doesn't do it? Moreover, $'...' quoting in bash is different (per
manual) from zsh $'...' quoting.

    In bash, escape sequences within $'...' are replaced as if they
were inside ANSI C code. Zsh processes anything inside $'...' as if
the builtin 'print' was interpreting that. These two behaviours are
different and are documented as such (see the info manual for bash
and for zsh). I'm not sure about which behaviour should work when
doing 'sh' emulation, since 'sh' shouldn't have such quoting.

    I don't have a position about the octal sequences, anyway, so I
won't give an opinion about it.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.dervishd.net & http://www.pleyades.net/

Re: zsh/bash incompatibilities

[Peter Stephenson]

"Matthias B." wrote:
> Regarding zsh's refusal to interpret
> octal escapes that don't start with 0, I find that very annoying and it's
> certainly not what most people expect.

You get that behaviour with "print".  It deliberately doesn't do that
with echo for compatibility; there are lots of variants of echo around.

You're turning on zsh in standards-compliant mode (such as it is :-/)
and demanding that it doesn't respect the standard.  If you want to be
able to run things the same way on multiple shells, you *have* to be
able to accept standard behaviour, you don't have a choice.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: zsh/bash incompatibilities

[Peter Stephenson]

"Matthias B." wrote:
> I'm undecided about which \ treatment inside of $'..' I prefer, so I guess
> looking to what POSIX says is best.

I've been looking for some standardized definition of this and can't
find one, offhand.   It doesn't seem to be in The Open Group Base
Specifications, issue 6, which is the latest standard I know of.  Does
anyone have a pointer?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************