From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23479 invoked from network); 9 Dec 1998 09:19:01 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 9 Dec 1998 09:19:01 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id EAA15747; Wed, 9 Dec 1998 04:17:57 -0500 (EST) Resent-Date: Wed, 9 Dec 1998 04:17:57 -0500 (EST) Message-Id: <9812090901.AA23162@ibmth.df.unipi.it> To: zsh-workers@math.gatech.edu Subject: Re: Notes on bash(1) In-Reply-To: "Phil Pennock"'s message of "Wed, 09 Dec 1998 03:25:32 NFT." <19981209032532.54741@athenaeum.demon.co.uk> Date: Wed, 09 Dec 1998 10:01:29 +0100 From: Peter Stephenson Resent-Message-ID: <"FAHgi2.0.-r3.51aRs"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4730 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Phil Pennock wrote: > * bash has arrays. 'declare', 'local' & 'readonly' each accept '-a' to > declare an array. Is it reasonable to add '-a' to 'typeset'? This > would automatically duplicate the bash-ism. It's not exactly essential, since bash and zsh have rather different extensions to sh in any case. They're only similar in as much as they both include sh. It's hard enough keeping ksh emulation working. > Further, would it be an idea to then deprecate 'set -A' which > overloads parameter setting onto 'set'? That's needed for ksh. > * ${parameter/pattern/string} and ${parameter//pattern/string} > pattern is expanded as per pathname expansion. Longest match of > pattern against parameter is replaced with string. Once for / and for > all instances with //. #pattern anchors to beginning, %pattern > anchors to end. string may be null. Applied to an array, this works > on each element. > zsh has a some of this with the colon-modifier 's'. This would be quite useful, since :s only does simple string replacement, and it doesn't clash with anything, yet, though if you wait long enough... Maybe it can be done quite simply by upgrading the extra flags Sven added for # and % to match internal bits of a parameter's value. > The anchors in particular are nice. They would make it easy to fully > replicate basename(1) without forking. We can't currently (AFAIK) > accurately duplicate $(basename file .ext) (think - filename: .ext.ex) > % base=${var:t:s/%.ext//} If you mean `remove the extension if and only if it's .ext', then you can do ${${var:t}%.ext}. > * ${parameter:offset} and ${parameter:offset:length} provide substring > and array extraction. Both length and offset are arithmetic > expressions. length>=0. offset may be negative to measure from end. > zsh notably has ${parameter[start,stop]} already. How desirable is > this alternate syntax, given that zsh allows history modifiers in the > same place? It doesn't look like there would be a conflict, provided > zsh requires $[...] for variables there. Testing, bash allows: > $ foo=abcde; t=2; echo ${foo:t} I think it's too close to the history modifiers and we'd better stick with the subscript notation, unless we're aiming at a bash compatibility mode which is really going a bit far. It worries me slightly that there are people out there who don't know the difference between bash and sh --- which is their problem, but one day they may start inflicting it on other people. -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy