From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-users-return-18606-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 23319 invoked by alias); 13 Mar 2014 16:19:51 -0000
Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Users List <zsh-users.zsh.org>
List-Post: <mailto:zsh-users@zsh.org>
List-Help: <mailto:zsh-users-help@zsh.org>
X-Seq: 18606
Received: (qmail 17210 invoked from network); 13 Mar 2014 16:19:45 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
	autolearn=ham version=3.3.2
From: Bart Schaefer <schaefer@brasslantern.com>
Message-id: <140313091942.ZM14393@torch.brasslantern.com>
Date: Thu, 13 Mar 2014 09:19:42 -0700
In-reply-to: <1394702788.77938.YahooMailNeo@web194601.mail.sg3.yahoo.com>
Comments: In reply to Amm <ammdispose-zsh@yahoo.com>
 "zsh detects rm * but not rm ** (multiple stars)" (Mar 13,  5:26pm)
References: <1394702788.77938.YahooMailNeo@web194601.mail.sg3.yahoo.com>
X-Mailer: OpenZMail Classic (0.9.2 24April2005)
To: "zsh-users@zsh.org" <zsh-users@zsh.org>
Subject: Re: zsh detects rm * but not rm ** (multiple stars)
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii

On Mar 13,  5:26pm, Amm wrote:
} Subject: zsh detects rm * but not rm ** (multiple stars)
}
} But I suppose match should not just be on single *
} but on *+ (1 or more *)

Thanks for the suggestion.  The "rm *" behavior is very old (was in
the shell even before the special meaning of "**", something over 20
years ago now) and hasn't changed in all that time, so I can't say
with any confidence it'll change now.  It probably wouldn't have been
included in the first place if the shell then had some of the other
features that have been added since.
 
} Also is there a way to make zsh warn when there is * in
} argument list, regardless of command?

I think most people would just find this annoying :-) and it's hard
to emit a sensible prompt when you don't know what's going to be done
with the result.  However:

zle-line-finish() {
  emulate -R zsh -o extendedglob -o localoptions
  local words stars ask yes
  words=( ${(Z{c})BUFFER} )
  [[ -o interactivecomments ]] && words=( ${words%(#s)\#*} )
  stars=( ${(M)words#((#s)[*]|*/[*]##)(#e)} )
  for ask in $stars
  do
    read -q yes$'?\n'"zsh: sure you want to pass $ask [n/y]?"
    if [[ $yes != y ]]
    then
      zle -I
      zle push-input
      zle send-break
    fi
  done
  (( $#stars )) && zle -I
}
zle -N zle-line-finish

This behaves the way you wanted, aborting the entire command on any
"no" answer (but leaving it in the editor for you to fix, which you
didn't ask for but seemed reasonable).

The placement of "zle -I" here is critical for reasons that are most
likely a bug.

-- 
Barton E. Schaefer