3 ms·

I have written hundreds of shell scripts, several which are hundreds of lines long. When I say they havent aged well, Im speaking from experience. When I use so

I have written hundreds of shell scripts, several which are hundreds of lines long. When I say they havent aged well, Im speaking from experience. When I use something like: find -name *.jpg I know what it actually does. But what it actually doesnt isnt what it should do. The current behavior returns matched files... unless no files match. Then it returns the literal string "*.jpg". That behavior is usually going to be desired by no one. Same with: grep $SOMETHING it going to fail if the variable has any spaces. Again something most people arent going to want. These both can be worked around with Shell options and "IFS" respectively, but people shouldnt have to do that. The default behavior should be sane, but in many cases the POSIX standard isnt that. For goodness sake, the "venerable" find tool doesnt even have a "maxdepth" option: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/f...

userbinator 7y ago
You completely ignored my point, which is that none of this behaviour should be surprising or unexpected to anyone who has taken the time to think about how it all works together, and that this flexibility is the inherent way in which the UNIX command line is so powerful. it going to fail if the variable has any spaces Quoting and escaping. I mentioned that already, it's a basic part of the understanding and is not surprising at all. Again something most people arent going to want. You're assuming a lot. The fact that the variable substitution could expand to multiple arguments (because it's really just simple textual substitution) is in fact very powerful and useful (you can pass multiple arguments in one variable, for example), and you can always quote if you really want it to expand to one argument, the same way you would quote strings containing spaces to make them one argument. This is very consistent; observe that if $SOMETHING contains "foo bar" (without the quotes), then grep $SOMETHING is exactly the same as grep foo bar but what you seem to be suggesting is that it becone grep "foo bar" ...what? Where did those quotes come from? More importantly, how do you propose to remove them? My point is, the current behaviour is simple and consistent as well as powerful and flexible, and I suspect people are just going "it doesn't work the way I thought it would" and downvoting my comment when they really haven't thought about the perfectly logical explanation for why things are the way they are. The original developers of the shell language were most certainly not stupid.
- DavidSJ 7y ago
  The current behavior is not simple and consistent. If it were, then *.jpg would “expand” to the empty list of arguments, rather than remain unchanged, in the degenerate case of no match.
- pwdisswordfish2 7y ago
  So, do you prefer people have this misconception instead? https://unix.stackexchange.com/q/544189/348263 https://unix.stackexchange.com/q/544189/348263 Also, for the case of passing multiple arguments to a command, just use an array: SOMETHING=(foo bar) grep "${SOMETHING[@]}" It will handle arguments with spaces correctly, unlike using a string variable and splitting it on spaces. There is no reason to ever use space splitting, unless you're maintaining some legacy interface where you can only pass a string instead of an array.
- olejorgenb 7y ago
  I almost never want the split-on-ifs-on-expansion behavior. That's one of the reasons I use zsh. When I want I can either use an array or $=SOMETHING. The default split behavior basically forces you to always quote expansions which is tiresome. It also is confusing because almost no other programming language works like that. And when you assigned SOMETHING you did wrote SOMETHING="foo bar" (with quotes) so it sorta makes sense visually also.
- UncleMeat 7y ago
  Our tools should be dead simple whenever possible rather than "if you make mistakes then git gud".

userbinator 7y ago

You completely ignored my point, which is that none of this behaviour should be surprising or unexpected to anyone who has taken the time to think about how it all works together, and that this flexibility is the inherent way in which the UNIX command line is so powerful. it going to fail if the variable has any spaces Quoting and escaping. I mentioned that already, it's a basic part of the understanding and is not surprising at all. Again something most people arent going to want. You're assuming a lot. The fact that the variable substitution could expand to multiple arguments (because it's really just simple textual substitution) is in fact very powerful and useful (you can pass multiple arguments in one variable, for example), and you can always quote if you really want it to expand to one argument, the same way you would quote strings containing spaces to make them one argument. This is very consistent; observe that if $SOMETHING contains "foo bar" (without the quotes), then grep $SOMETHING is exactly the same as grep foo bar but what you seem to be suggesting is that it becone grep "foo bar" ...what? Where did those quotes come from? More importantly, how do you propose to remove them? My point is, the current behaviour is simple and consistent as well as powerful and flexible, and I suspect people are just going "it doesn't work the way I thought it would" and downvoting my comment when they really haven't thought about the perfectly logical explanation for why things are the way they are. The original developers of the shell language were most certainly not stupid.

DavidSJ 7y ago
The current behavior is not simple and consistent. If it were, then *.jpg would “expand” to the empty list of arguments, rather than remain unchanged, in the degenerate case of no match.
pwdisswordfish2 7y ago
So, do you prefer people have this misconception instead? https://unix.stackexchange.com/q/544189/348263 https://unix.stackexchange.com/q/544189/348263 Also, for the case of passing multiple arguments to a command, just use an array: SOMETHING=(foo bar) grep "${SOMETHING[@]}" It will handle arguments with spaces correctly, unlike using a string variable and splitting it on spaces. There is no reason to ever use space splitting, unless you're maintaining some legacy interface where you can only pass a string instead of an array.
olejorgenb 7y ago
I almost never want the split-on-ifs-on-expansion behavior. That's one of the reasons I use zsh. When I want I can either use an array or $=SOMETHING. The default split behavior basically forces you to always quote expansions which is tiresome. It also is confusing because almost no other programming language works like that. And when you assigned SOMETHING you did wrote SOMETHING="foo bar" (with quotes) so it sorta makes sense visually also.
UncleMeat 7y ago
Our tools should be dead simple whenever possible rather than "if you make mistakes then git gud".