Re: An incompatible behavior from bash?

[Lawrence Velázquez <larryv@xxxxxxx>]

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