From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16377 invoked from network); 24 Jul 2001 13:43:18 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 24 Jul 2001 13:43:17 -0000 Received: (qmail 1356 invoked by alias); 24 Jul 2001 13:43:10 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15474 Received: (qmail 1341 invoked from network); 24 Jul 2001 13:43:10 -0000 X-VirusChecked: Checked Sender: kiddleo@pag.logica.co.uk Message-ID: <3B5D7B51.35772566@u.genie.co.uk> Date: Tue, 24 Jul 2001 14:42:41 +0100 From: Oliver Kiddle X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Zsh hackers list Subject: Re: Enhanced shell References: <20010722224707.BD7621428E@pwstephenson.fsnet.co.uk> <3B5C06E6.FFFCCFCC@u.genie.co.uk> <1010723180327.ZM14158@candle.brasslantern.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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