Re: Enhanced shell

[Oliver Kiddle <opk@u.genie.co.uk>]

Bart Schaefer wrote:

| On Jul 23, 12:13pm, Oliver Kiddle wrote:
| }
| } > precmd, chpwd, periodic
| 
| I think these should always have been arrays of function names to be
| called, rather than magic function names in their own right.  Of course,
| we could do both.

Still, I think we should mention them with the point about the
problems. It could possibly also apply with the ERR trap.

| } > ${+foo}
| } yes and some other parameter expansion extensions
| 
| I think where we'll run into problems here, aside from the fact that the
| flags syntax used by zsh is a bit baroque, is with field splitting and
| whether various extensions apply before or after it happens (I have the
| impression that under traditional splitting rules, certain extensions
| can't possibly be made to apply after splitting).  I see you've suggested
| leaving out expansion flags, though.

That is roughly why I suggested leaving out expansion flags. I was
thinking of some of the simpler things like ${name/pattern/repl} and
${name:#pattern}.

| } backreferences (ksh93's possibly being better)
| 
| You didn't mention anything about that in workers/15348.  What are the
| differences?

Well, they are very different really. Basically instead of accessing
matched parts of the pattern later with variables, you can refer back
to earler parts of a pattern so, for example, [[ abba = @(?)bb\1 ]]
would return true because \1 will match whatever the first thing in
brackets matched.

workers/15348 was never going to be complete. I've found other things
since like [=c=] in a pattern matches "all characters with the same
primary collation weight as the character c".

| } directory stack, and access with ~num
| 
| You suggest having the directory stack as a special built-in but not the
| commands to manipulate it?

Well not really though with autopushd, that is how I use the directory
stack. The directory stack as a whole should probably be left out.

| } prompt percent substitutions
| Maybe.

I hadn't realised that bash used backslashes for this as Peter pointed
out so that'll probably be a problem

| } the common -L option to many builtins [similar to typeset -p in ksh]
| 
| Option letter clashes are another place where we may have trouble.  I
| think `-L' was a better choice than `-p', but ...

It doesn't help that -L is already used by typeset for left alignment.

| } array subscripts with start and end
| 
| More 0-vs-1 problems.

Yes, that's going to be a fairly big problem. We probably have to put
up with the standard following ksh and zsh using the ksharrays option.

| What about subscript flags and pattern subscripts?  array[(r)pat]
| "Reverse indexing"?

possibly.

| On Jul 23, 12:38pm, Peter Stephenson wrote:
| }
| } > typeset builtin (yes, it isn't in POSIX). Also, note that bash has
| } > obsoleted `typeset' in favour of `declare' which I think is better.
| }
| } It strikes me as a bit late for that now.
| 
| But it could be added as another alias for typeset; ksh93 doesn't have
| `local' either (does it?).

It is already there as another alias for typeset!

ksh93 doesn't have `local'.

| } > > ? disable/enable? [bash]
| } > not so useful. they are also common as commands to enable/disable
| } > printers (on AIX and Solaris at least).
| }
| } Yes, I can see it would be silly defining a standard which is known to have
| } this clash in it.
| 
| As has been pointed out, though, the functionality is useful.  Rather

Another possibility would be if the functionality was achieved by
modifying special arrays like those in the zsh/parameter module or
ksh93's .sh namespace. Anyway, I suggest we mention the functionality
in our list for David Korn and point out the issues when it comes up in
discussion with him.

| } > > ? typeset etc. -g?
| } > zsh/bash dynamically scoped local variables.
| } Hmm.  I don't know how this will pan out if ksh is going the way of
| } statically scoped parameters.
| Another typeset option?

Yes, as I think I mentioned in workers/15348, it is going to have to be
either no local variables or support both types (which is what Perl
does).

Oliver

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp