zsh-workers
 help / color / mirror / code / Atom feed
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: zsh-workers@zsh.org
Subject: [PATCH 1/2] FAQ: Add "Why does my bash script report an error when I run it under zsh?".
Date: Thu, 28 May 2020 20:30:48 +0000	[thread overview]
Message-ID: <20200528203049.13144-1-danielsh@tarpaulin.shahaf.local2> (raw)

---
Uses emdash() from 45791.

 Etc/FAQ.yo | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 54 insertions(+), 3 deletions(-)

diff --git a/Etc/FAQ.yo b/Etc/FAQ.yo
index d1f8b7d83..9b5e2206a 100644
--- a/Etc/FAQ.yo
+++ b/Etc/FAQ.yo
@@ -129,6 +129,7 @@ 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?
@@ -857,6 +858,7 @@ mytt(compctl)
 
 
 sect(Similarities with bash)
+label(25)
 
   The Bourne-Again Shell, bash, is another enhanced Bourne-like shell;
   the most obvious difference from zsh is that it does not attempt to
@@ -959,9 +961,9 @@ label(31)
   Unless you need strict sh/ksh compatibility, you should ask yourself
   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 from
-  other shells.  The natural way to produce word-splitting behaviour
-  in zsh is via arrays.  For example,
+  can cause horrendous quoting problems when invoking scripts written
+  for other shells (see link(3.31)(331)).  The natural way to produce
+  word-splitting behaviour in zsh is via arrays.  For example,
   verb(
     set -A array one two three twenty
   )
@@ -2034,6 +2036,55 @@ 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)
+
+  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.)
+
+  So, 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.
+
+  That's the answer for myem(scripts), i.e., for 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)).  For myem(plugins) emdash() code that is
+  executed within the shell itself, that's loaded via the mytt(.),
+  mytt(source), or mytt(autoload) builtins, added to mytt(.zshrc), or
+  pasted interactively at the shell prompt emdash() the answer is
+  different.
+
+  Since the bash and zsh languages do have a common subset, it is
+  feasible to write non-trivial plugins 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.  It myem(might) be a bug in zsh, but it might also be
+  a bug in bash, or simply a difference that isn't a bug in either shell
+  (see link(3.1)(31) for an example).
+
+  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.)
+
+  If you'd like to run a bash script under zsh, you must port the script
+  properly, reviewing it line by line for differences between the two
+  languages and adjusting the script accordingly, just like you would
+  when translating a book from American English to British English.
+
+
 chapter(The mysteries of completion)
 
 

             reply	other threads:[~2020-05-28 20:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-28 20:30 Daniel Shahaf [this message]
2020-05-28 20:30 ` [PATCH 2/2] FAQ (3.1): Update ksh compatibility answer for reserved word typeset Daniel Shahaf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200528203049.13144-1-danielsh@tarpaulin.shahaf.local2 \
    --to=d.s@daniel.shahaf.name \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).