Some sh(1) plans for 10.0

[Jilles Tjoelker]

Here are some changes that may happen to sh(1) in 10.0.

* Report output errors in builtins (error message and exit status 2).
  For example: echo >&-. PR bin/158206.

* Special expansion for assignments in export/readonly/local.
  This expands assignments in a command like export a=~ b=$1 as if the
  "export" were not there (tilde expansion after = and :, no pathname
  generation, no word splitting).
  This feature has been available in ksh/bash/zsh for a long time and
  has been proposed and defined for a new version of POSIX at
  http://austingroupbugs.net/view.php?id=351
  Users sometimes get confused by this not working and if POSIX plans to
  add it, why not add it here?

* 'time' keyword, allowing timing of pipelines and compound commands.
  This works such that if any options are specified, it will fall back
  to /usr/bin/time. The proposed changes to POSIX are fairly extensive
  including changes to the ! keyword which will break some of our
  scripts and a TIMEFORMAT variable. A somewhat stripped version may be
  useful. Note that a shell-based version cannot and will not support
  SIGINFO. This is also the case with the versions in tcsh, bash and
  zsh.
  http://austingroupbugs.net/view.php?id=267

* Conditional command [[ ... ]] much like ksh. This is being discussed
  in the Austin Group at this time. I don't really like the duplication
  with [ ... ] and case, considering that they work well in the POSIX
  spec and our implementation. Some reasons to add it anyway are that it
  is slightly easier to use and cleaner in syntax, that < and > can use
  locale-specific ordering (strcoll) (but when are strings compared for
  greater-than in a shell script?) and that a regex match could be
  added.
  A slightly older proposal is at
  https://docs.google.com/document/d/1Gd9r0f0rmmUIZlBnO4NyhTz2q-_1PHHGVCHAglFbJoY/edit

* vfork support, with an environment variable to opt out.

* Executing commands in subshell environments without forking in more
  situations (saving and restoring state manually instead).

* Here document expansion without a fork. A simple implementation would
  make expansion side effects persistent and errors fatal while a more
  complicated implementation could avoid that. A fork is still needed if
  the here document cannot be written into a pipe without blocking.
  (This could be avoided with ugly SIGIO magic but the case seems too
  rare to bother.)

* If execve() fails even though the file exists and is executable, and
  it should not be run using /bin/sh ([ENOEXEC] and text file), give a
  clearer error message. Example: #! interpreter does not exist.
  Some rework could make all execve() errors detected in the child
  process of this kind.

-- 
Jilles Tjoelker