From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21300 invoked from network); 29 Jul 2001 09:53:57 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Jul 2001 09:53:57 -0000 Received: (qmail 23071 invoked by alias); 29 Jul 2001 09:53:43 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15513 Received: (qmail 23060 invoked from network); 29 Jul 2001 09:53:41 -0000 Subject: Re: Enhanced shell In-Reply-To: <20010722224707.BD7621428E@pwstephenson.fsnet.co.uk> from Peter Stephenson at "Jul 22, 2001 11:47:02 pm" To: Peter Stephenson Date: Sun, 29 Jul 2001 10:53:39 +0100 (BST) CC: Zsh hackers list X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Zefram Peter Stephenson wrote: >emulate builtin We should only standardise "emulate posix_v2" as a way of specifying "this is written for the enhanced shell standard". Then future revisions of the standard get to add new permitted arguments to emulate. Without an emulate command in a script, the shell has to behave in a manner compatible with the original POSIX. The introduction of explicit specification of the language in which a script is written makes it possible for us to make incompatible changes to shell syntax (it's automatically compatibe because of the "emulate"). There's a noticeable problem otherwise, that the POSIX standard doesn't leave many punctuation characters available for semantically interesting uses (especially most of our extended glob characters). Speaking of which, some kind of extended glob pattern syntax should probably be part of the new standard (with emulate as described above, the new syntax can be on by default in enhanced mode). >coproc keyword (|& as per csh is already semi-standard and useful) I was thinking about this. The existing coproc semantics are rather limiting ("<&p" only working with the one coprocess) and baroque (magic fd closures on redirecting). Having a coproc reserved word gives us a place to put options on the coprocess -- we could have "coproc -i6 -o7" to connect the coprocess's input to shell fd 6, etc., leaving the "p" file descriptors alone. We don't really need to standardise the "p" file descriptors at all. It's just a pity we can't make coproc a normal command -- it has to be part of the shell grammar to pick up an entire pipeline, which seems to be what we want. >? ZDOTDIR? (or equivalent) I'm very dubious about this kind of thing. We should mostly ignore the environment when deciding which dotfiles to execute. Should we be standardising a larger set of dotfiles? E.g., ".posix_env", ".posix_rc". >? =cmd? With cleaned-up semantics, yes. It shouldn't be doing alias expansion. >? glob qualifiers (perhaps in some standardised NO_BARE_GLOB_QUAL form) The NO_BARE_GLOB_QUAL form should probably simply be an explicit way of introducing the qualifier syntax we already have. That was the idea behind the option -- BARE_GLOB_QUAL makes glob qualifier syntax clash with glob grouping syntax. >CPUTYPE/HOSTYPE/OSTYPE, EGID/GID, EUID/UID, ERRNO, HOST or HOSTNAME (bash) Careful here. My understanding of POSIX is that it has no special variables (as we understand the term). An assignable EGID, for example, would add extra semantics to a name that looks like it's in the user's namespace. Adding special variables with the names we've traditionally used would be a step backwards. Instead, we should put all magic variables -- ones that affect the shell or that the shell fiddles with, other than by explicit command -- into a sub-namespace. Things like PATH would have to remain where they are, because they're needed in the environment. But EGID should be "egid.sh". We can allow arbitrary special semantics of variables in the ".sh" namespace while leaving all names without "." as completely dumb variables for the user to manage as he sees fit. >`ESS_VERSION' (version no. of extended shell standard) Perhaps this should be a magic array, "emulations.sh", listing the values understood for "emulate". Either way, it's not very useful in scripts. Other stuff: How about multios? Pretty simple semantics, not difficult to implement, though we ought to decide properly when an implicit tee gets waited for. With the emulate command as described above, we can have multios be on by default in "posix_v2" mode and (of course) off by default in POSIX v1 mode. We don't need to standardise "setopt multios", or most other user-visible options. <> redirection: is it already in the standard? &> (and &>>): we should leave >& alone, not standardise the overloading it gets in zsh. prompt expansion: not sure if our % sequences should be standard. However, we could quite nicely have the standard specify that prompts get $-expanded (and no other special treatment), and then zsh users can still do PS1='${(%)${:-%n@%m}}'. modifiers on parameter expansion: the history modifiers could be standardised for use in parameter expansion a la "${FOO:t}". These seem useful, and a clean syntax. Process substitution, at least in the ">>(...)" and "<<(...)" form (where the effect is merely to create pipes). I'm dubious about standardising the general >(...). Brace expansion is already semi-standard. -zefram