| |||||||||||||
Fish - The friendly interactive shellFish - The friendly interactive shellPosted May 21, 2005 1:06 UTC (Sat) by liljencrantz (subscriber, #28458)In reply to: Fish - The friendly interactive shell by diehl Parent article: Fish - The friendly interactive shell
1) I don't like the bash way of doing this, since it is inconsistent and for me at least it is very rarely what I want. As another poster said, csh refuses to execute commands with wildcards that match nothing. This seems better at least, but from a language viewpoint, neither is very logical. But I'll consider changing the way fish handles this.
2) I will look into how the mimedb command searches for the .desktop hierarchy. It has been a few months since I touched that code, so my memory is a bit hazy. I'll get back to you.
(Log in to post comments)
Fish - The friendly interactive shell Posted May 26, 2005 15:25 UTC (Thu) by mikachu (guest, #5333) [Link] 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.
Fish - The friendly interactive shell Posted May 26, 2005 15:51 UTC (Thu) by diehl (guest, #6413) [Link] Well, in my opinion I perfer to have ls have the behavior of of saying "no filefound" if a file does not exist, rather than giving an entire directory listing if the file does not exist, which I find confusing. So I vote for implementing that behavior, at least as an option.
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:
fish sure is neater:
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.
|
|||||||||||||