Fish - The friendly interactive shell [LWN.net]

Fish - The friendly interactive shell

Posted May 26, 2005 15:25 UTC (Thu) by mikachu (guest, #5333)
In reply to: Fish - The friendly interactive shell by liljencrantz
Parent article: Fish - The friendly interactive shell

In zsh, you can select between two behaviours, either you get an error when * doesn't match anything, or it expands to nothing as in fish. (and when in the first mode, you can write *(N) to make it expand to nothing if it doesn't match). In bash i think * is left as a literal * if it doesn't match, so the file not found message is actually from ls, not the shell. Not 100% sure about that one though.

(Log in to post comments)

Fish - The friendly interactive shell

Posted May 27, 2005 12:07 UTC (Fri) by liljencrantz (subscriber, #28458) [Link]

The reason fish does what it does right now is that I regularly do things like:

for i in *.c; [...]; end

Inside of shellscripts. I expect this to work even when *.c does not match anything. If *.c is not expanded in this case, this will result in stupid behaviour, unless I add an explicit check, which is clearly dumb.

Maybe the perfect compromise is to have *.c expand to nothing inside of scripts, but emit a syntax error in interactive mode?

Fish - The friendly interactive shell

Posted May 30, 2005 17:10 UTC (Mon) by Jyhem (guest, #29388) [Link]

Are you saying that if you write

for i in *.bak; rm $i; end

then if there is no backup file present, I will have all the files in the directory deleted ?

I hope you intend to implement "undo" :-D

Fish - The friendly interactive shell

Posted May 30, 2005 21:15 UTC (Mon) by liljencrantz (subscriber, #28458) [Link]

Look at your example again... If *.bak does not match anything, the for loop body will execute exactly zero times. So the rm command will _never_ be run. And even if it had, running rm without any parameters doas not remove anything. So you are doubly safe.

Fish - The friendly interactive shell

Posted Jun 1, 2005 19:29 UTC (Wed) by kjetilho (guest, #30261) [Link]

It would be bad to make the behaviour in scripts different from that in interactive use, often I just paste my recent command history and make it a script for later use. The obviously correct ;-) solution is to make globbing work differently in list context, ie. when used as an iterator in for loops.

Doing this correctly in bash is quite painful -- you need to handle case where the glob matches literally:


  for i in *.c; do
    [ "$i" = "*.c" -a ! -e "$i" ] && break
    do_stuff "$i"
  done

fish sure is neater:

  for i in *.c; do_stuff $i; end

Fish - The friendly interactive shell

Posted Jun 9, 2005 12:11 UTC (Thu) by liljencrantz (subscriber, #28458) [Link]

So many solutions to a single problem. What is really needed is a 'Do what i mean' command...

Fish - The friendly interactive shell

Posted May 27, 2005 14:02 UTC (Fri) by liljencrantz (subscriber, #28458) [Link]

This is very typical for zsh. Whenever there is a difficult design tradeof, zsh implements multiple solutions and lets the user choose. This may sound like a good way of doing things, but I think it is a cop out and a bad idea. Here is why:

Multiple implementations means that more time has to be spent on maintaining the code, it becomes more difficult to add new features and the number of possible configuration combinations means that it becomes impossible to test all configuration combinations, which leads to an increase in rare, hard to nail down bugs. And if you eventually figure out the _right_ way of doing something, it is difficult to change the code, because that means removing configuration options.