3 ms·

The shell works with spaces, you just need to be careful to quote every file name. The advantage of using file names without spaces is that you can avoid the qu

The shell works with spaces, you just need to be careful to quote every file name. The advantage of using file names without spaces is that you can avoid the quotes.

viraptor 6y ago
Please don't ever assume you can avoid spaces and quotes. It's just a time bomb. It's like people saying you don't need to escape SQL values because they come from constants. Yes, they do... today. It's not just quoting either. It's setting the separator value and reverting it correctly. It's making sure you're still correct when you're in a function in an undefined state. It's a lot of overhead in larger projects.
- CountSessine 6y ago
  Sure, but in a larger project your won’t be coding in shell script, right?
  - viraptor 6y ago
    Larger projects will often include small shell scripts for deployment / maintenance / various tasks.
- coliveira 6y ago
  What I am saying is nothing new. This has always been the policy of UNIX developers. If you use only file names without space, then you can make it easier to use tools that depend on this. Of course, if you're writing applications in shell then you cannot rely just on convention.
thekaleb 6y ago
Some shells handle this quoting better than others.
gorgoiler 6y ago
Indeed, and the shell lives and breathes spaces. Arrays of arguments are created every time one types a command. Without spaces-as-magic we’d be typing things like this all the time: $ exec(‘ls’, ‘-l’, ‘A B C’) Maybe that’s unrealistic? I mean, if the shell was like that, it probably wouldn’t have exec semantics and would be more like this with direct function calls: $ ls(ls::LONG, ‘A B C’) Maybe we would drop the parentheses though — they can be reasonably implied given the first token is an unspaced identifier: $ ls ls::LONG, ‘A B C’ And really, given that unquoted identifiers don’t have spaces, we don’t really need the commas either. Could also use ‘-‘ instead of ‘ls::’ to indicate that an identifier is to be interpreted locally in the specific context of the function we are calling, rather than as a generic argument. $ ls -LONG ‘A B C’ If arguments didn’t have spaces, you could make the quotes optional too. QED
- tsimionescu 6y ago
  I don't think this is the problem people usually complain about. The much bigger problem is that spaces make text-only commands compose badly. $ ls -l `find ./ -name *abc*` Is going to work very nicely if file names have certain properties (no spaces, no special chars), and it's going to break badly if they don't. Quoting is also very simple in simple cases, but explodes in complexity when you add variables and other commands into the mix.
  - hnlmorg 6y ago
    That's still just a shell problem since the shell is expanding `find` and placing the unquoted result into the command line. Some non-POSIX shells don't have this issue. For example with murex you could use either of these two syntaxes: ls -l ${find ./ name *abc*} # return the result as a single string ls -l @{find ./ name *abc*} # return the result as an array (like Bourn shell) So in the first example, the command run would look something like: ls -l "foo abc bar" whereas in the second it would behave more like Bourne shell: ls -l foo abc bar As an aside, the example you provided also wouldn't work in Bourne shell because the asterisks would be expanded by the shell rather than `find`. So you'd need to quote that string: ls -l `find ./ -name "*abc*"` This also isn't a problem in murex because you can specify whether to audo-expand globbing or not. With POSIX shells you end up with quotation mark soup: ls -l "`find ./ -name '*abc*'`" (and we're lucky in this example that we don't need to nest any of the same quotation marks. It often gets uglier than this!) Murex also solves this problem by supporting open and close quote marks via S-Expression-style parentheses: ls -l (${find ./ -name (*abc*)}) Which is massively more convenient when you'd normally end up having to escape double quotes in POSIX shells. --- Now I'm not trying to advocate murex as a Bash-killer, my point is that it's specifically the design of POSIX shells that cause these problems and not the way Unix pipelines work.
tsimionescu 6y ago
The shell (bash, anyway) has a weird mix of support and lack of support for spaces/lists/etc. For example, there is no way to store the `a b "c d"` in a regular variable in a way where you can then call something similar to `ls $VAR` and get the equivalent of `ls a b "c d"`. You can either get the behavior of `ls a b c d` or `ls "a b c d"`, but if you need `ls a b "c d"` you must go for an array variable with new syntax. This isn't necessarily a big hurdle, but it indicates that the concepts are hard to grasp and possibly inconsistent.
- teddyh 6y ago
  That has nothing to do with spaces, but more to do with the rather lackluster support for arrays in most Bourne-style shells.
- account42 6y ago
  Bash has arrays: var=( a b "c d" ) ls "${var[@]}" POSIX shell can get you what you want with eval: var='a b "c d"' eval "ls $var" There is also one array variable in POSIX shells, the argument list: set -- a b "c d" ls "$@"

The shell works with spaces, you just need to be careful to quote every file name. The advantage of using file names without spaces is that you can avoid the quotes.

viraptor 6y ago

Please don't ever assume you can avoid spaces and quotes. It's just a time bomb. It's like people saying you don't need to escape SQL values because they come from constants. Yes, they do... today. It's not just quoting either. It's setting the separator value and reverting it correctly. It's making sure you're still correct when you're in a function in an undefined state. It's a lot of overhead in larger projects.

CountSessine 6y ago
Sure, but in a larger project your won’t be coding in shell script, right?
- viraptor 6y ago
  Larger projects will often include small shell scripts for deployment / maintenance / various tasks.
coliveira 6y ago
What I am saying is nothing new. This has always been the policy of UNIX developers. If you use only file names without space, then you can make it easier to use tools that depend on this. Of course, if you're writing applications in shell then you cannot rely just on convention.

thekaleb 6y ago

Some shells handle this quoting better than others.

gorgoiler 6y ago

Indeed, and the shell lives and breathes spaces. Arrays of arguments are created every time one types a command. Without spaces-as-magic we’d be typing things like this all the time: $ exec(‘ls’, ‘-l’, ‘A B C’) Maybe that’s unrealistic? I mean, if the shell was like that, it probably wouldn’t have exec semantics and would be more like this with direct function calls: $ ls(ls::LONG, ‘A B C’) Maybe we would drop the parentheses though — they can be reasonably implied given the first token is an unspaced identifier: $ ls ls::LONG, ‘A B C’ And really, given that unquoted identifiers don’t have spaces, we don’t really need the commas either. Could also use ‘-‘ instead of ‘ls::’ to indicate that an identifier is to be interpreted locally in the specific context of the function we are calling, rather than as a generic argument. $ ls -LONG ‘A B C’ If arguments didn’t have spaces, you could make the quotes optional too. QED

tsimionescu 6y ago
I don't think this is the problem people usually complain about. The much bigger problem is that spaces make text-only commands compose badly. $ ls -l `find ./ -name *abc*` Is going to work very nicely if file names have certain properties (no spaces, no special chars), and it's going to break badly if they don't. Quoting is also very simple in simple cases, but explodes in complexity when you add variables and other commands into the mix.
- hnlmorg 6y ago
  That's still just a shell problem since the shell is expanding `find` and placing the unquoted result into the command line. Some non-POSIX shells don't have this issue. For example with murex you could use either of these two syntaxes: ls -l ${find ./ name *abc*} # return the result as a single string ls -l @{find ./ name *abc*} # return the result as an array (like Bourn shell) So in the first example, the command run would look something like: ls -l "foo abc bar" whereas in the second it would behave more like Bourne shell: ls -l foo abc bar As an aside, the example you provided also wouldn't work in Bourne shell because the asterisks would be expanded by the shell rather than `find`. So you'd need to quote that string: ls -l `find ./ -name "*abc*"` This also isn't a problem in murex because you can specify whether to audo-expand globbing or not. With POSIX shells you end up with quotation mark soup: ls -l "`find ./ -name '*abc*'`" (and we're lucky in this example that we don't need to nest any of the same quotation marks. It often gets uglier than this!) Murex also solves this problem by supporting open and close quote marks via S-Expression-style parentheses: ls -l (${find ./ -name (*abc*)}) Which is massively more convenient when you'd normally end up having to escape double quotes in POSIX shells. --- Now I'm not trying to advocate murex as a Bash-killer, my point is that it's specifically the design of POSIX shells that cause these problems and not the way Unix pipelines work.

tsimionescu 6y ago

The shell (bash, anyway) has a weird mix of support and lack of support for spaces/lists/etc. For example, there is no way to store the `a b "c d"` in a regular variable in a way where you can then call something similar to `ls $VAR` and get the equivalent of `ls a b "c d"`. You can either get the behavior of `ls a b c d` or `ls "a b c d"`, but if you need `ls a b "c d"` you must go for an array variable with new syntax. This isn't necessarily a big hurdle, but it indicates that the concepts are hard to grasp and possibly inconsistent.

teddyh 6y ago
That has nothing to do with spaces, but more to do with the rather lackluster support for arrays in most Bourne-style shells.
account42 6y ago
Bash has arrays: var=( a b "c d" ) ls "${var[@]}" POSIX shell can get you what you want with eval: var='a b "c d"' eval "ls $var" There is also one array variable in POSIX shells, the argument list: set -- a b "c d" ls "$@"