sh emulation POSIX non-conformances (Was: [PATCH] Document imperfections in POSIX/sh compatibility)

[Stephane Chazelas <stephane@chazelas.org>]

Some non-POSIX conformances I can think of ATM:

* "echo -" does not output -\n

  last (or one of the last) time it was brought up, I pointed
  out that anyway few shells were POSIX compliant in that regard
  in that for instance POSIX requires "echo -e" to output
  "-e\n".

  I've since asked POSIX allow echo -e, echo -E (and
  combinations of those and -n), and zsh's echo -. They've
  rejected the latter part. See
  https://www.austingroupbugs.net/view.php?id=1222

  So I think it would make sense now to stop accepting "-" as
  option delimiter in sh emulation.

* a few of zsh's reserved words are still available in POSIX
  mode.

  $ zsh --emulate sh -c 'foreach() { true; }'
  zsh:1: parse error near `()'
  $ zsh --emulate sh -c 'end() { true; }'
  zsh:1: parse error near `end'

* IFS treated as separator and not delimiter:

  $ a='a:b:' zsh --emulate sh -c 'IFS=:; printf "<%s>\n" $a'
  <a>
  <b>
  <>

  (POSIX requires <a> and <b> only). Many shells used to behave
  like zsh, but switched for POSIX compliance even though the
  zsh behaviour is more useful for instance to break down
  variables like $PATH (like /bin:/usr/bin: which should be
  split into "/bin", "/usr/bin" and "").

* whitespace characters other than SPC/TAB/NL not treated as IFS
  whitespace.

  $ a=$'\ra\r\rb' zsh --emulate sh -c $'IFS=\r; printf "<%s>\n" $a'
  <>
  <a>
  <>
  <b>

  POSIX requires only <a> and <b> above as isspace('\r') is
  true so \r should receive the same treatment as space, \t, \n.
  Few shells do it. bash has only started recently doing it and
  only for single byte characters (so is not POSIX either).

-- 
Stephane