* An incompatible behavior from bash? @ 2022-08-19 22:32 Liu Xin 2022-08-20 0:39 ` Lawrence Velázquez 0 siblings, 1 reply; 5+ messages in thread From: Liu Xin @ 2022-08-19 22:32 UTC (permalink / raw) To: zsh-workers [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: An incompatible behavior from bash? 2022-08-19 22:32 An incompatible behavior from bash? Liu Xin @ 2022-08-20 0:39 ` Lawrence Velázquez 2022-08-22 7:54 ` Liu Xin 0 siblings, 1 reply; 5+ messages in thread From: Lawrence Velázquez @ 2022-08-20 0:39 UTC (permalink / raw) To: Liu Xin; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: An incompatible behavior from bash? 2022-08-20 0:39 ` Lawrence Velázquez @ 2022-08-22 7:54 ` Liu Xin 2022-08-22 21:44 ` Bart Schaefer 0 siblings, 1 reply; 5+ messages in thread From: Liu Xin @ 2022-08-22 7:54 UTC (permalink / raw) To: Lawrence Velázquez; +Cc: zsh-workers [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: An incompatible behavior from bash? 2022-08-22 7:54 ` Liu Xin @ 2022-08-22 21:44 ` Bart Schaefer 2022-08-23 5:42 ` Liu Xin 0 siblings, 1 reply; 5+ messages in thread From: Bart Schaefer @ 2022-08-22 21:44 UTC (permalink / raw) To: Liu Xin; +Cc: zsh-workers 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: An incompatible behavior from bash? 2022-08-22 21:44 ` Bart Schaefer @ 2022-08-23 5:42 ` Liu Xin 0 siblings, 0 replies; 5+ messages in thread From: Liu Xin @ 2022-08-23 5:42 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-08-23 5:47 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-08-19 22:32 An incompatible behavior from bash? Liu Xin 2022-08-20 0:39 ` Lawrence Velázquez 2022-08-22 7:54 ` Liu Xin 2022-08-22 21:44 ` Bart Schaefer 2022-08-23 5:42 ` Liu Xin
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).