An incompatible behavior from bash?

An incompatible behavior from bash?

[Liu Xin]

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

Hi, Zsh developers,

I think zsh is compatible with bash, but I found one different behavior in
parameter expansion.  In the following example, I guess zsh interprets
"$1:l" as a whole. Is it intentional?  I read the doc but I haven't found
anything about it.
https://zsh.sourceforge.io/Doc/Release/Expansion.html#Parameter-Expansion

Here is an example, I tried zsh 5.8.1 on both linux and macos. The results
are the same.

% cat t.sh
param_expansion() {
  var=$1:l
  echo $var
}

param_expansion hello
% zsh t.sh
hello
% bash t.sh
hello:l

[-- Attachment #2: Type: text/html, Size: 794 bytes --]

Re: An incompatible behavior from bash?

[Lawrence Velázquez]

On Fri, Aug 19, 2022, at 6:32 PM, Liu Xin wrote:
> I think zsh is compatible with bash

It is only partially compatible, and compatibility is not a development
priority.  The notion that zsh is a fancy superset of bash is false;
zsh will only run simple bash scripts correctly.  (Whether it errs
loudly or quietly depends on the feature used.  Using sh emulation
may also help.)

You are better off assuming that an arbitrary bash feature *does
not* work with zsh unless proven otherwise, rather than assuming
that it *does* work.

> but I found one different behavior 
> in parameter expansion.  In the following example, I guess zsh 
> interprets "$1:l" as a whole. Is it intentional?

Yes.  From the documentation you linked:

	In addition to the following operations, the colon modifiers
	described in "Modifiers" in "History Expansion" can be
	applied: for example, ${i:s/foo/bar/} performs string
	substitution on the expansion of parameter $i.

	[...]

	${name}
		The value, if any, of the parameter _name_ is
		substituted.  [...]  In addition, more complicated
		forms of substitution usually require the braces
		to be present; exceptions, which only apply if the
		option KSH_ARRAYS is not set, are a single subscript
		or any colon modifiers appearing after the name
		[...].

Your example applies the "l" history modifier, which converts the
expansion to lowercase.  This is more obvious with a different
choice of value:

	% export VAR=HELLO
	% zsh -c 'echo "$VAR:l"'
	hello

Braces are required if KSH_ARRAYS is set (either explicitly or via
sh/ksh emulation).

	% zsh --emulate sh -c 'echo "$VAR:l"'
	HELLO:l
	% zsh --emulate sh -c 'echo "${VAR:l}"'
	hello

-- 
vq

Re: An incompatible behavior from bash?

[Liu Xin]

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

Hi, Lawrence,

I hold the wrong impression that zsh is compatible with bash. I just assume
it because I see both Ubuntu and MacOS have replaced bash with it.
Thank you for your explanation. Indeed, it uses letter l as a word modifier
(14.1.4 Modifiers). I will read the zsh manual!

thanks,
--lx




On Fri, Aug 19, 2022 at 5:40 PM Lawrence Velázquez <larryv@zsh.org> wrote:

> On Fri, Aug 19, 2022, at 6:32 PM, Liu Xin wrote:
> > I think zsh is compatible with bash
>
> It is only partially compatible, and compatibility is not a development
> priority.  The notion that zsh is a fancy superset of bash is false;
> zsh will only run simple bash scripts correctly.  (Whether it errs
> loudly or quietly depends on the feature used.  Using sh emulation
> may also help.)
>
> You are better off assuming that an arbitrary bash feature *does
> not* work with zsh unless proven otherwise, rather than assuming
> that it *does* work.
>
> > but I found one different behavior
> > in parameter expansion.  In the following example, I guess zsh
> > interprets "$1:l" as a whole. Is it intentional?
>
> Yes.  From the documentation you linked:
>
>         In addition to the following operations, the colon modifiers
>         described in "Modifiers" in "History Expansion" can be
>         applied: for example, ${i:s/foo/bar/} performs string
>         substitution on the expansion of parameter $i.
>
>         [...]
>
>         ${name}
>                 The value, if any, of the parameter _name_ is
>                 substituted.  [...]  In addition, more complicated
>                 forms of substitution usually require the braces
>                 to be present; exceptions, which only apply if the
>                 option KSH_ARRAYS is not set, are a single subscript
>                 or any colon modifiers appearing after the name
>                 [...].
>
> Your example applies the "l" history modifier, which converts the
> expansion to lowercase.  This is more obvious with a different
> choice of value:
>
>         % export VAR=HELLO
>         % zsh -c 'echo "$VAR:l"'
>         hello
>
> Braces are required if KSH_ARRAYS is set (either explicitly or via
> sh/ksh emulation).
>
>         % zsh --emulate sh -c 'echo "$VAR:l"'
>         HELLO:l
>         % zsh --emulate sh -c 'echo "${VAR:l}"'
>         hello
>
> --
> vq
>

[-- Attachment #2: Type: text/html, Size: 3191 bytes --]

Re: An incompatible behavior from bash?

[Bart Schaefer]

On Mon, Aug 22, 2022 at 1:00 AM Liu Xin <navy.xliu@gmail.com> wrote:
>
> I hold the wrong impression that zsh is compatible with bash. I just assume it because I see both Ubuntu and MacOS have replaced bash with it.

Zsh is mostly compatible with POSIX shell provided that it is invoked
via the name "sh" (e.g., when linked to /bin/sh).  Bash is similarly
compatible with POSIX when run this way.  When run under their own
names, zsh and bash differ from POSIX in different ways.

Apple and Ubuntu appear to have concluded that zsh's POSIX
compatibility is sufficient to use it as "sh".  I won't speculate on
other motivations.

Re: An incompatible behavior from bash?

[Liu Xin]

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

Ok, thanks for the clarification.

On Mon, Aug 22, 2022 at 2:44 PM Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Mon, Aug 22, 2022 at 1:00 AM Liu Xin <navy.xliu@gmail.com> wrote:
> >
> > I hold the wrong impression that zsh is compatible with bash. I just
> assume it because I see both Ubuntu and MacOS have replaced bash with it.
>
> Zsh is mostly compatible with POSIX shell provided that it is invoked
> via the name "sh" (e.g., when linked to /bin/sh).  Bash is similarly
> compatible with POSIX when run this way.  When run under their own
> names, zsh and bash differ from POSIX in different ways.
>
> Apple and Ubuntu appear to have concluded that zsh's POSIX
> compatibility is sufficient to use it as "sh".  I won't speculate on
> other motivations.
>

[-- Attachment #2: Type: text/html, Size: 1195 bytes --]