On Fri, Jun 4, 2010 at 11:41, Diggory Hardy <[email protected]> wrote:
> I also wanted to say I agree with David's view... it's annoying having to
> quote globbing rules in scp etc. There was a time when I didn't really value
> this.. but recently I've been been bumping into this a lot more often with
> things like:
>
> scp server:path/file*
> find . -name somefile*.ext
>
The first example is quite safe, but the second has a real chance of a
matching file in the current dir, which would be expanded by fish and
not do what you wanted at all.
> At which point -- I'm sure you get the idea. So, the options I see:
>
> 1. keep as is
> 2. configuration option -- but as Michael points out: "Configurability is
> the root of all evil" (well... not ideal at least)
> 3. 'noglob' command... not a lot better
Bah. -1 on config/noglob.
I believe the language must be unambiguous, and the problem should be
attacked by other means.
> 4. Only expand globbing patterns when valid (as in bash)
>
> Does anyone have anything to say against option 4? Sure, error messages from
> commands like 'ls file*' are going to change from:
>[...]
> but I don't see why this should be a big deal. Or are there some important
> cases I've missed, where this is a bigger deal?
>
It encourages you to write ambiguous code like the find example you gave.
It by accident the glob matches a real file, it won't do what you want!
It'd be a bad practice in functions/scripts and I'd rather not have a
separate interactive dialect.
Instead, I propose we attack it by interactive means:
(A) fish should highlight unmatching wildcards in red as you type.
If the command is going to fail, there is no reason to make you
press Enter to discover this.
[Issue: this might be too slow to do as you type?]
(B) there should be an easy one-press way to quote the current wildcard.
Maybe pressing TAB on an unmatched wildcard should quote it?
[No performance problem here - TAB on wildcards already works well,
with the exception of ** which it refuses to attempt]
[Another idea that springs to mind from the similarity of fish to LISP
is to add a one-sided quoting syntax affecting one word. Something
like::
find -name `*.foo
which would be equivallent to:
find -name "*.foo"
But no, I'm not seriously proposing this.]
P.S. Are you aware of fish's **/somefile*.ext recursive globbing syntax?
Doesn't change the discussion, just making sure you didn't miss it.
--
Beni Cherniavsky-Paskin <[email protected]>
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
