Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.0 Date: Fri, 1 Jan 2016 23:05:57 +0100 From: Vincent Lefevre To: zsh-workers@zsh.org Subject: Re: buggy CSH_NULL_GLOB when a pattern is at the command position Message-ID: <20160101220557.GA15551@zira.vinc17.org> Mail-Followup-To: zsh-workers@zsh.org References: <20160101040052.GA1808@zira.vinc17.org> <160101123940.ZM10365@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <160101123940.ZM10365@torch.brasslantern.com> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/1.5.24-6548-vl-r83103 (2016-01-01) X-Seq: zsh-workers 37479 On 2016-01-01 12:39:40 -0800, Bart Schaefer wrote: > On Jan 1, 5:00am, Vincent Lefevre wrote: > } > } When CSH_NULL_GLOB is set and the command line contains only patterns, > } a "no match" error is not reported. > > Hm. So what's happening here is that the error is suppressed in zglob() > because it should only be reported if all globbing fails; but because > the command position is globbed separately from the rest of the line, > the caller is not expecting to handle this condition and glob failure > is interpreted as an empty command line. > > You can see how this happens better if written this way: > > torch% [] echo foo > foo > > The [] is discarded because of cshnullglob, so "echo" is actually the > command. > > The patch below fixes the case where all command-position globs fail, > although the error message is not the same as when cshnullglob is not set > (which has always been true in other cases, so probably not a big deal). > > } Moreover, I wonder whether when a no-match pattern is at the > } command position, one should always get an error (if possible). > > It's conceivable that somebody might actually *intend* the behavior in > my example above, though I don't know why. Actually, I wonder whether I have ever used a glob at the command position on purpose. And it seems that such a glob often does not make sense because globbing doesn't take $path into account: zira% which emacs /usr/bin/emacs zira% emac* zsh: permission denied: emacs-bug So, this would mean that one would need to use the full path: zira% /usr/bin/emac* which also doesn't make sense if it expands to several words like here: zira% echo /usr/bin/emac* /usr/bin/emacs /usr/bin/emacs24 /usr/bin/emacs24-x /usr/bin/emacsclient /usr/bin/emacsclient.emacs24 So, independently of CSH_NULL_GLOB, perhaps there should be options so that, at the user choice: 1) glob is not allowed at command position. But if really needed, one can still do something like: command /usr/bin/emac*([1]) 2) glob at command position is allowed, but fails if the number of generated words is not exactly 1. In my case, I think that I would be happy with (1). -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)