Re: Enhanced shell

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

This is a bit choppy because I'm trying not to say myself anything that
Oliver already said.

On Jul 22, 11:47pm, Peter Stephenson wrote:
}
} ? ZDOTDIR? (or equivalent)

This is a slightly twitchy one.  It's only really useful if it's imported
from the environment, but it's dangerous for e.g. `su' to read other
people's dotfiles.  Maybe ZDOTDIR should be discarded unless ((EGID==GID)).
(Maybe that would also be a good test for whether to import FPATH, which
was another thread of discussion not long ago.)

} autoload -U

And `setopt NO_ALIASES' or the equivalent.

On Jul 23, 12:13pm, Oliver Kiddle wrote:
}
} > precmd, chpwd, periodic
} preexec
} I'm not too sure about these because of the sort of problems we get
} with, for example the prompt themes overwriting the existing functions.
} I can think of a few more flexible ways of allowing the same.

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.

} > ${+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.

} > ? glob qualifiers (perhaps in some standardised NO_BARE_GLOB_QUAL form)
} yup.
} backreferences (ksh93's possibly being better)

You didn't mention anything about that in workers/15348.  What are the
differences?

} > CPUTYPE/HOSTYPE/OSTYPE, EGID/GID, EUID/UID,  ERRNO, HOST or HOSTNAME (bash)
} VENDOR/MACHTYPE, LOGNAME (USER/USERNAME), PWD, OLDPWD, COLUMNS, LINES,
} pipestatus [PIPESTATUS in bash], ARGC/ARGV(?), RANDOM(?), SECONDS(?),
} SHLVL, TTY

ARGC/ARGV are going to be hard to standardize because of the 1-based v.
0-based array indexing issues.  In fact, I suspect array indexing is
going to be one of the bigger sticking points in the whole discussion.

} > command [bash]
} -, builtin and noglob. I think command is already in the standard.

Yes, `command' is in POSIX, but it works a bit differently than zsh's.

} > ? pushd?
} not too sure about that because it can be done with a couple of scripts
} and because autopushd with the ~ completion is more useful.

Bash has pushd/popd as builtins.  Also:

} directory stack, and access with ~num

You suggest having the directory stack as a special built-in but not the
commands to manipulate it?

} cd -
} two argument form of cd
} cd's handling of symbolic links

That last could stand some clarification even in current zsh.  It's been
on my to-do list for ages and I've never gotten to it.

The two-argument form of cd has stopped us doing some other interesting
things with options to the `cd' command.  It might not be the best form
to standardize.

} C style for loop syntax

You mean `for ((...))'?  I've always been mildly annoyed that it only
works with math expressions and not with more general shell commands.

} ? repeat loop

Yes.

} prompt percent substitutions

Maybe.

} [[ ... ]] conditions

Yes.

} ? global aliases

Not sure.

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

} array subscripts with start and end

More 0-vs-1 problems.

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

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?).

} > > ? 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
than `disable -[afr] ...' maybe we could standardize on an option common
to other commands, e.g. `function -D name' would be `disable -f name',
`alias -D name' would be `disable -a name', etc.  The tricky one is
`builtin -D name' which would have to work on both reserved words and
builtin commands, or something.

} > multios option (and maybe other redirection extensions)
} 
} This is very useful, but it's maybe a bit too much of a hack to
} standardise (e.g. the race condition on output multios in the current
} implementation, although I hope that's fixable).

It's fixable; the shell just needs to keep track of the forked `tee'-job
and wait for it.  That just happens to be a little complicated right now.
 
} > > ? 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?

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