Re: Enhanced shell

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jul 29, 10:53am, Zefram wrote:
} Subject: Re: Enhanced shell
}
} >coproc keyword (|& as per csh is already semi-standard and useful)
} 
} 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.

I think the syntax `coproc { LIST }' would be preferable to what we have
now.  Ksh has introduced `namespace NAME { LIST }' already.  If the LIST
associated with `coproc' were brace-delimited, we could use the regular
redirection operators to specify inputs and outputs, rather than using
options to the coproc pseudo-command.  Heck, you could even have coprocs
with multios!

} >? ZDOTDIR? (or equivalent)
} 
} I'm very dubious about this kind of thing.  We should mostly ignore the
} environment when deciding which dotfiles to execute.

That's why I suggested not importing ZDOTDIR unless geteuid() == getuid().
Seems to be the right balance.  (How does ksh deal with ENV ?)

} >CPUTYPE/HOSTYPE/OSTYPE, EGID/GID, EUID/UID,  ERRNO, HOST or HOSTNAME (bash)
} 
} 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".

Ksh namespaces are ${.namespace.parameter}, not ${parameter.namespace}.
I think we're probably going to be stuck with that.  However, I agree
that most of the "magic" variables should be in a namespace, and futher
I that the magic should be implemented with something like discipline
functions.  E.g., there should be a builtin command to change effective
UID, and assigning to .sh.euid should invoke that command.

} 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.

Hmm, perhaps that's true, but should we at least standardize a reserved
name (e.g., a .sh.options parameter) for changing the option settings?

Should we try to do anything at all about the plethora of single-letter
shell-startup command-line options?

} 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.

The syntax isn't all that clean, really, once you get involved with using
more than one modifier per expansion ... and the semantics of :s/p/r and
:& etc. are rather baroque.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net