From owner-freebsd-arch@FreeBSD.ORG Wed Dec 14 14:59:09 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56630106564A for ; Wed, 14 Dec 2011 14:59:09 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id D5DBC8FC16 for ; Wed, 14 Dec 2011 14:59:08 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id pBEEx7xA019669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 14 Dec 2011 15:59:07 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1323874747; bh=xdU2/p3QZmAjVZwr2cAvYki4glch9glZXtyzKkglOGU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=gmiT8Uo+fB5rNVkU+9k2U30QMph/2eOj48ztDAXG2sPZhpvjyZs+BakptUE+xTT3f xyDHX4jMSFB4sOXb2dQYDDc6Xa/BRnzzKQ5Qv/sV+RgX6Qobu0dqdV45zHC6YUs3uj dHXpD58tLVF4/9TQWAPkOIpe/VitJAKizvNoQm9w= Date: Wed, 14 Dec 2011 15:59:07 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Jilles Tjoelker Message-ID: <20111214145907.GN83814@acme.spoerlein.net> Mail-Followup-To: Jilles Tjoelker , freebsd-arch@freebsd.org References: <20111213220020.GA42285@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111213220020.GA42285@stack.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org Subject: Re: Some sh(1) plans for 10.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 14:59:09 -0000 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