From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from math.gatech.edu (euclid.skiles.gatech.edu [130.207.146.50]) by werple.net.au (8.7/8.7.1) with SMTP id LAA05768 for ; Sat, 11 Nov 1995 11:01:08 +1100 (EST) Received: by math.gatech.edu (5.x/SMI-SVR4) id AA17263; Fri, 10 Nov 1995 18:48:12 -0500 Resent-Date: Fri, 10 Nov 1995 18:45:03 -0500 Old-Return-Path: Message-Id: <199511102345.SAA00693@redwood.skiles.gatech.edu> X-Mailer: exmh version 1.6.4 10/10/95 To: zsh-workers@math.gatech.edu Subject: Re: rmstar option nit in 2.6-beta11 In-Reply-To: Your message of "Fri, 10 Nov 1995 16:05:20 MST." <9511102305.AA06309@suomi.cdc.noaa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Nov 1995 18:45:03 -0500 From: Richard Coleman Resent-Message-Id: <"tpHKF2.0.cD4.xI-em"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/592 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu > I'm one of the fools who aliases rm to 'rm -i' and who has zsh prompt > on *. (I know the argument that I'll be burned when I do an rm * on > another system and expect to be protected. But until then I'll just > attend `rm -i anonymous meetings' ;-) REAL men alias `rm' to `rm -f' :-) > Anyway, should zsh behave this way under these circumstances: > > $ rm * > zsh: sure you want to delete all the files in /foo/bar? n > rm: too few arguments > Try `rm --help' for more information. > > (this is gnu rm, obviously) > > I'd thought the command itself would be aborted, but instead it > appears to just clean out the arg list for the command. Is this the > intended behaviour? Interesting. Looking at the code, I see that if you do $ rm * and then type `n' when it queries you, it will abort the command with a return value of 1. If you type $ rm file1 * and then type `n' when it queries you, it will delete `*' from the argument list and continue. Therefore file1 gets deleted and it returns with a return value of 0. Not very consistent. I agree that in this case it's probably better to just abort the command. I'll need to check this more carefully, but it appears you can just replace the lines uremnode(args, node)' in that particular piece of code (it's hard for me to give you line numbers since I've made changes to exec.c) with the lines lastval = 1; return; and then remove the lines if (!nextnode(firstnode(args))) errflag = 1; I'll look at this some more and try to fix it for beta12. rc