Some sh(1) plans for 10.0

[Ulrich Spörlein]

On Tue, 2011-12-13 at 23:00:20 +0100, Jilles Tjoelker wrote:
> 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?

Woa, looks like thats a fucked up situation overall ...

> * '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).

Is this really worth the effort and the added complexity? I hope there
will be benchmarks showing that this is actually saving us non-negligible
time.

> * 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.

Good stuff overall, keep up the good work!

Uli