4 ms·

First example suggests that `ls` should not be used but `ls -l` - the same program author advises against in the title, but with a parameter - works as expected

First example suggests that `ls` should not be used but `ls -l` - the same program author advises against in the title, but with a parameter - works as expected and in this case would not result in "you can't tell". > The problem is that from the output of ls, neither you or the computer can tell what parts of it constitute a filename. Computer does not use console output of ls(1) to determine the list of files. It's for the user. The computer can tell what is a file here. The title could also be stricter with s/ls/"GNU coreutils ls"/g, too. I could not reproduce all the issues with FreeBSD's ls(1) under zsh.

Tepix 5y ago
"ls -l" has other issues, now it will show you user and group names which can contain unexpected characters, too.
- deleted 5y ago
  [deleted]
vidarh 5y ago
> First example suggests that `ls` should not be used but `ls -l` - the same program author advises against in the title, but with a parameter - works as expected and in this case would not result in "you can't tell". The first example is used to demonstrate the issue and to demonstrate that "-l" introduces other issues (inconsistent escaping). > Computer does not use console output of ls(1) to determine the list of files. It's for the user. The computer can tell what is a file here. But if you try to use the output of ls in a script to find filenames, the computer will be using ls to determine the list of files. Hence the advice not to do so. > The title could also be stricter with s/ls/"GNU coreutils ls"/g, too. I could not reproduce all the issues with FreeBSD's ls(1) under zsh. I think that just emphasises why you shouldn't, as it demonstrates you can't trust the output of ls to be consistent between systems either. If you are sure you'll never need to run your scripts on another system, you might not care, but when it's so easy to prevent this by e.g. using find with "-print0" or equivalent, it seems silly to not just unlearn the bad habit of using ls for this.

Tepix 5y ago

"ls -l" has other issues, now it will show you user and group names which can contain unexpected characters, too.

deleted 5y ago
[deleted]

vidarh 5y ago

> First example suggests that `ls` should not be used but `ls -l` - the same program author advises against in the title, but with a parameter - works as expected and in this case would not result in "you can't tell". The first example is used to demonstrate the issue and to demonstrate that "-l" introduces other issues (inconsistent escaping). > Computer does not use console output of ls(1) to determine the list of files. It's for the user. The computer can tell what is a file here. But if you try to use the output of ls in a script to find filenames, the computer will be using ls to determine the list of files. Hence the advice not to do so. > The title could also be stricter with s/ls/"GNU coreutils ls"/g, too. I could not reproduce all the issues with FreeBSD's ls(1) under zsh. I think that just emphasises why you shouldn't, as it demonstrates you can't trust the output of ls to be consistent between systems either. If you are sure you'll never need to run your scripts on another system, you might not care, but when it's so easy to prevent this by e.g. using find with "-print0" or equivalent, it seems silly to not just unlearn the bad habit of using ls for this.