From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6682 invoked from network); 23 Jul 2001 18:06:19 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 23 Jul 2001 18:06:19 -0000 Received: (qmail 4408 invoked by alias); 23 Jul 2001 18:06:12 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15463 Received: (qmail 4396 invoked from network); 23 Jul 2001 18:06:11 -0000 From: "Bart Schaefer" Message-Id: <1010723180327.ZM14158@candle.brasslantern.com> Date: Mon, 23 Jul 2001 18:03:27 +0000 References: <20010722224707.BD7621428E@pwstephenson.fsnet.co.uk> <3B5C06E6.FFFCCFCC@u.genie.co.uk> X-Mailer: Z-Mail (5.0.0 30July97) To: Zsh hackers list Subject: Re: Enhanced shell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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