Enhanced shell standard. summary

Enhanced shell standard. summary

[Peter Stephenson]

Before I make a firm suggestion about what we want from zsh in an
enhanced shell, here's a summary of proposals made by me, Oliver, Bart
and Zefram, with a little editorial pruning --- I didn't want to go over
the top, but have included a few things mentioned by other people that
they seemed to be particularly keen on, even if I have doubts they're
suitable for standardisation.

The first section means I haven't yet done my homework about what's
already in Posix or single UNIX, but will do when this finally settles
down.

Reasonably rapid responses --- must-have additions, must-not-have
subtractions --- would be appreciated, I don't want this preliminary
round to drag on much longer since until the people from the other shell
have commented it's a bit of a moot discussion.

check posix
-----------
disown, builtin, suspend
pushd
typeset, declare
[[ ... ]]
parameters LOGNAME or USER or USERNAME
  LINENO
  COLUMNS/LINES
process substitution, at least <<(...)

basic, already present in more than 1
--------------------------------------
whence
${name/pattern/repl}
{a,b}
** math power operator
parameters:
  ERRNO
  HOST or HOSTNAME
  SHLVL, RANDOM, SECONDS
  HOSTTYPE, OSTYPE, MACHTYPE
cd takes care of symlinks, optionally resolves linkso
-l option to shell for login
some form of enhanced pattern matching, e.g. like ksh88.
$-expanion in prompts to be standard

additions
---------
emulate
autoload -U, NO_ALIASES
<<<'word'
functionality of precmd, chpwd, periodic
${+foo} to check whether set
coproc
{0..10}
glob qualifiers, also history-like modifiers on glob patterns.
** recursive search
parameters: CPUTYPE, VENDOR, ERRNO
version of enhanced shell spec, maybe via namespace
functionality associated with disable/enable for builtin --- but name clash
repeat loop (repeat 10; do print hello; done)
standardisation of basic key bindings [need list]
-L options to may builtins to list in form for input to shell
  [or make this defined behaviour --- will need option in zsh for
  compatibility]
if namespaces, possible magic settable variables, corresponding
  to zsh's EGID/GID, EUID/UID (note suitable for standardising as they
  are, because the magic behaviour would clash with Posix).

maybe optional
--------------
=cmdname

Hmmm [meaning I don't now much we can really do here...]
----
history commands and parameters

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: Enhanced shell standard. summary

[Bart Schaefer]

On Jul 29, 11:11pm, Peter Stephenson wrote:
} Subject: Enhanced shell standard. summary
}
} ... here's a summary of proposals ... --- I didn't want to go over
} the top, but have included a few things mentioned by other people that
} they seemed to be particularly keen on, even if I have doubts they're
} suitable for standardisation.

Part of the point about a number of the things that were mentioned was
not that they're suitable for standardization, but that they should be
kept in mind so that the standard at least doesn't conflict with them.

I don't see any significant omissions or mis-inclusions on your list as
strictly a list of the things that might be standardi[sz]able.

} I don't want this preliminary round to drag on much longer since until
} the people from the other shell have commented it's a bit of a moot
} discussion.     ^^^^^^^^^^^^^^^
                      Plural?

I don't want it to drag on either, but because I think we need to send
off our list to DK et al. as soon as possible.  Either the ball is not
rolling, or it's rolling where we can't see it.

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

RE: Enhanced shell standard. summary

[Borsenkow Andrej]

> parameters: CPUTYPE, VENDOR, ERRNO

CPUTYPE is uname -p IIRC, it hardly warrants extra parameter.

VENODR is very unlikely. System vendors change rapidly (what is now
ReliantUNIX was (is being) owned by Nixdorf, Siemens Nixdorf, Siemens,
Fujitsu Siemens), but VENDOR is still `sni'. Changing VENDOR every time
ownership changes clearly defeats its purpose, but companies hardly agree on
declaring obsolete names.

ERRNO is way too Unix specific; other systems may not have concept of errno
or even system calls.

-andrej

Re: Enhanced shell standard. summary

[Peter Stephenson]

Bart Schaefer wrote:
> } I don't want this preliminary round to drag on much longer since until
> } the people from the other shell have commented it's a bit of a moot
> } discussion.     ^^^^^^^^^^^^^^^
>                       Plural?
> 
> I don't want it to drag on either, but because I think we need to send
> off our list to DK et al. as soon as possible.  Either the ball is not
> rolling, or it's rolling where we can't see it.

That was pretty much what I was saying.  Here's the list I sent.  I've
simply removed stuff we can't really agree on ourselves.  It turned out
$LOGNAME is already mentioned in the single UNIX spec, so I deleted the
line about USER/USERNAME/LOGNAME.

basic
-----
builtins: disown, builtin, suspend, pushd, whence, typeset, declare
[[ ... ]]
COLUMNS/LINES
process substitution, at least <<(...)
${name/pattern/repl}
{a,b}
** math power operator
parameters:
  HOST or HOSTNAME
  SHLVL, RANDOM, SECONDS
  HOSTTYPE, OSTYPE, MACHTYPE
cd takes care of symlinks, optionally resolves linkso
-l option to shell for login
some form of enhanced pattern matching, e.g. like ksh88.
Use of $-expansion in prompts to be standard

additions
---------
emulate <name-indicating-enhanced-shell-standard>
autoload -U, NO_ALIASES option
<<<'word'
functionality of precmd, chpwd, periodic, but with cleaner interface
${+foo} to check whether set
coproc keyword (as |& is quite useful as a csh-like abbreviation)
{0..10} => 0 1 2 3 4 5 6 7 8 9 10
glob qualifiers e.g. *(.) => all regular files
** recursive search
version of enhanced shell spec available maybe via namespace
  (${.sh.ess_version})
functionality associated with disable/enable for builtins --- but name clash
repeat loop (repeat 10; do print hello; done)
standardisation of basic key bindings [need list of these]
-L options to may builtins to list in form for input to shell
  [or make this defined behaviour for builtins --- will need option in zsh
  for compatibility]
`=cmdname' expands to full path to command cmdname.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Enhanced shell standard. summary

[Clint Adams]

> basic
> -----
> builtins: disown, builtin, suspend, pushd, whence, typeset, declare
> [[ ... ]]
> COLUMNS/LINES
> process substitution, at least <<(...)

If these aren't implied by anything already in the list, I'd
like to add

ability to declare a variable as local
arrays
associative arrays

Re: Enhanced shell standard. summary

[Peter Stephenson]

Clint Adams wrote:
> If these aren't implied by anything already in the list, I'd
> like to add
> 
> ability to declare a variable as local

Some form of typeset-relative (probably typeset itself) will be there.

> arrays
> associative arrays

There's likely to be some negotiation as to what parameter types will be 
allowed/mandated.  I've already suggested these.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************