Date: Wed, 14 Dec 2011 15:59:07 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= <uqs@spoerlein.net> To: Jilles Tjoelker <jilles@stack.nl> Cc: freebsd-arch@freebsd.org Subject: Re: Some sh(1) plans for 10.0 Message-ID: <20111214145907.GN83814@acme.spoerlein.net> In-Reply-To: <20111213220020.GA42285@stack.nl> References: <20111213220020.GA42285@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111214145907.GN83814>