mirror/ zsh
1
0
Fork 0
mirror of git://git.code.sf.net/p/zsh/code synced 2024-04-24 10:55:09 +02:00
Code

unposted: FAQ: Move section 3.31 to 2.8 

See 48613
This commit is contained in:
dana 2021-05-03 18:32:02 -05:00
parent 093ba11970
commit c1f932d668
2 changed files with 65 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
ChangeLog
View File

@ -1,5 +1,7 @@
2021-05-03 dana <dana@dana.is>
* unposted (see 48613): Etc/FAQ.yo: Move section 3.31 to 2.8
* unposted (see 48613): Doc/Zsh/metafaq.yo, Doc/Zsh/roadmap.yo:
Update http:// FAQ links to https://

126
Etc/FAQ.yo
View File

@ -103,6 +103,7 @@ Chapter 2: How does zsh differ from...?
2.5. bash?
2.6. Shouldn't zsh be more/less like ksh/(t)csh?
2.7. What is zsh's support for Unicode/UTF-8?
2.8. Why does my bash script report an error when I run it under zsh?
Chapter 3: How to get various things to work
3.1. Why does `$var' where `var="foo bar"' not do what I expect?
@ -135,7 +136,6 @@ Chapter 3: How to get various things to work
3.28. How do I edit the input buffer in $EDITOR?
3.29. Why does `which' output for missing commands go to stdout?
3.30. Why doesn't the expansion mytt(*.{tex,aux,pdf}) do what I expect?
3.31. Why does my bash script report an error when I run it under zsh?
Chapter 4: The mysteries of completion
4.1. What is completion?
@ -936,6 +936,67 @@ sect(What is zsh's support for Unicode/UTF-8?)
fully below, see `Multibyte input and output'.
sect(Why does my bash script report an error when I run it under zsh?)
label(28)
em(tl;dr:) bash is not the reference implementation of zsh, and zsh is not
a bug-for-bug compatible reimplementation of bash.
bash and zsh are different programming languages. They are not
interchangeable; programs written for either of these languages will,
in general, not run under the other. (The situation is similar with
many other pairs of closely-related languages, such as Python 2 and
Python 3; C and C++; and even C89 and C11.)
When bash and zsh behave differently on the same input, whether zsh's
behaviour is a bug does not depend on what bash does on the same
input; rather, it depends on what zsh's user manual specifies.
(By way of comparison, it's not a bug in Emacs that mytt(:q!) doesn't
cause it to exit.)
That being said, the bash and zsh languages do have a common subset, and it is
feasible to write non-trivial pieces of code that would run under either of
them, if one is sufficiently familiar with both of them. However,
a difference between bash's behaviour and zsh's does not imply that
zsh has a bug. The difference might be a bug in zsh, a bug in bash, or
a bug in neither shell
(see link(3.1)(31) for an example).
The recommended way to deal with these differences depends on what kind
of piece of code is in question: a myem(script) or a myem(plugin).
For em(scripts) emdash() external commands that
are located in tt($PATH), or located elsewhere and are executed by
giving their path explicitly (as in mytt(ls), mytt(/etc/rc.d/sshd),
and mytt(./configure)) emdash() the answer is simple:
Don't run bash scripts under zsh. If the scripts were written for
bash, run them in bash. There's absolutely no problem with having
mytt(#!/usr/bin/env bash) scripts even if mytt(zsh) is your shell for
interactive sessions.
In fact, if you've recently changed to zsh, we myem(recommend) that
you keep your scripts as mytt(#!/usr/bin/env bash), at least for
a while: this would make the change more gradual and flatten your
learning curve. Once you're used to zsh, you can decide for each
script whether to port it to zsh or keep it as-is.
For myem(plugins) emdash() pieces of code
executed within the shell itself, loaded via the mytt(.),
mytt(source), or mytt(autoload) builtins, added to mytt(.zshrc), or
pasted interactively at the shell prompt emdash() one may consider it
worthwhile to invest the effort to make them runnable under either shell.
However, as mentioned above, doing so requires one to be familiar with both
shells, and either steer clear of their differences or handle them explicitly
with conditional code (such as mytt(if test -n "$ZSH_VERSION")).
In summary,
if you'd like to run a bash script or plugin under zsh, you must port the script or plugin
properly, reviewing it line by line for differences between the two
languages and adjusting it accordingly, just like you would
when translating a book from American English to British English.
chapter(How to get various things to work)
sect(Why does mytt($var) where mytt(var="foo bar") not do what I expect?)
@ -969,7 +1030,7 @@ label(31)
whether you really want this behaviour, as it can produce unexpected
effects for variables with entirely innocuous embedded spaces. This
can cause horrendous quoting problems when invoking scripts written
for other shells (see link(3.31)(331)). The natural way to produce
for other shells (see link(2.8)(28)). The natural way to produce
word-splitting behaviour in zsh is via arrays. For example,
verb(
set -A array one two three twenty
@ -2053,67 +2114,6 @@ sect(Why doesn't the expansion mytt(*.{tex,aux,pdf}) do what I expect?)
parse!
sect(Why does my bash script report an error when I run it under zsh?)
label(331)
em(tl;dr:) bash is not the reference implementation of zsh, and zsh is not
a bug-for-bug compatible reimplementation of bash.
bash and zsh are different programming languages. They are not
interchangeable; programs written for either of these languages will,
in general, not run under the other. (The situation is similar with
many other pairs of closely-related languages, such as Python 2 and
Python 3; C and C++; and even C89 and C11.)
When bash and zsh behave differently on the same input, whether zsh's
behaviour is a bug does not depend on what bash does on the same
input; rather, it depends on what zsh's user manual specifies.
(By way of comparison, it's not a bug in Emacs that mytt(:q!) doesn't
cause it to exit.)
That being said, the bash and zsh languages do have a common subset, and it is
feasible to write non-trivial pieces of code that would run under either of
them, if one is sufficiently familiar with both of them. However,
a difference between bash's behaviour and zsh's does not imply that
zsh has a bug. The difference might be a bug in zsh, a bug in bash, or
a bug in neither shell
(see link(3.1)(31) for an example).
The recommended way to deal with these differences depends on what kind
of piece of code is in question: a myem(script) or a myem(plugin).
For em(scripts) emdash() external commands that
are located in tt($PATH), or located elsewhere and are executed by
giving their path explicitly (as in mytt(ls), mytt(/etc/rc.d/sshd),
and mytt(./configure)) emdash() the answer is simple:
Don't run bash scripts under zsh. If the scripts were written for
bash, run them in bash. There's absolutely no problem with having
mytt(#!/usr/bin/env bash) scripts even if mytt(zsh) is your shell for
interactive sessions.
In fact, if you've recently changed to zsh, we myem(recommend) that
you keep your scripts as mytt(#!/usr/bin/env bash), at least for
a while: this would make the change more gradual and flatten your
learning curve. Once you're used to zsh, you can decide for each
script whether to port it to zsh or keep it as-is.
For myem(plugins) emdash() pieces of code
executed within the shell itself, loaded via the mytt(.),
mytt(source), or mytt(autoload) builtins, added to mytt(.zshrc), or
pasted interactively at the shell prompt emdash() one may consider it
worthwhile to invest the effort to make them runnable under either shell.
However, as mentioned above, doing so requires one to be familiar with both
shells, and either steer clear of their differences or handle them explicitly
with conditional code (such as mytt(if test -n "$ZSH_VERSION")).
In summary,
if you'd like to run a bash script or plugin under zsh, you must port the script or plugin
properly, reviewing it line by line for differences between the two
languages and adjusting it accordingly, just like you would
when translating a book from American English to British English.
chapter(The mysteries of completion)