Date: Tue, 13 Dec 2011 23:00:20 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: freebsd-arch@freebsd.org Subject: Some sh(1) plans for 10.0 Message-ID: <20111213220020.GA42285@stack.nl>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111213220020.GA42285>