Re: Enhanced shell

[Zefram <zefram@xxxxxxxx>]

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