6 ms·

>Separately, what `ls` displays with or without switches would be independent of how the extension is stored. Say the extension were a distinct field, `ls` coul

>Separately, what `ls` displays with or without switches would be independent of how the extension is stored. Say the extension were a distinct field, `ls` could still display that as `{filename}.{extension}` by default. But that would break piping the output of `ls` to other tools that expect a filename.

porridgeraisin 3y ago
You can have tty output be different from pipe output
- deleted 3y ago
  [deleted]
js2 3y ago
You shouldn't parse the output of `ls`: https://mywiki.wooledge.org/ParsingLs https://mywiki.wooledge.org/ParsingLs https://www.shellcheck.net/wiki/SC2010 https://www.shellcheck.net/wiki/SC2010 It's brittle and the output is designed for humans, not machine parsing. Use a glob or find. In a world where extensions were their own distinct metadata, whether or not to show them would be a switch to `ls` (whose output you shouldn't be parsing) and how to retrieve that metadata from a filename w/o parsing `ls` output would be something like: ext=$(stat --format="%E" -- "$filename") You'd also have a switch to `find` to select files by extension instead of having to pattern match their names.
- eurleif 3y ago
  This is a reasonable argument against parsing the output of `ls` within a shell script that you're going to save and reuse in arbitrary directories. It's not a reasonable argument against ever parsing the output of `ls`. If it were, it would also be an argument against humans reading the output of `ls`. The example in your first link makes its point by showing output from `ls` that the human reader can't parse. That doesn't demonstrate that the output of `ls` is "designed for humans, not machine parsing"; it demonstrates that in the general case, its output cannot be parsed by either humans or machines. My rule is that it's ok to use `ls` only in a directory where you know the filenames aren't weird. That rule is the same regardless of whether a human or a computer will be parsing its output. In general, reusable shell scripts shouldn't make assumptions about their environment, so they shouldn't use `ls`; but piping `ls` to another command in a one-off manner at an interactive shell is fine if you know the filenames in the directory aren't weird, just like it would be fine to use `ls` at the same interactive shell and simply read its output yourself.

porridgeraisin 3y ago

You can have tty output be different from pipe output

deleted 3y ago
[deleted]

js2 3y ago

You shouldn't parse the output of `ls`: https://mywiki.wooledge.org/ParsingLs https://mywiki.wooledge.org/ParsingLs https://www.shellcheck.net/wiki/SC2010 https://www.shellcheck.net/wiki/SC2010 It's brittle and the output is designed for humans, not machine parsing. Use a glob or find. In a world where extensions were their own distinct metadata, whether or not to show them would be a switch to `ls` (whose output you shouldn't be parsing) and how to retrieve that metadata from a filename w/o parsing `ls` output would be something like: ext=$(stat --format="%E" -- "$filename") You'd also have a switch to `find` to select files by extension instead of having to pattern match their names.

eurleif 3y ago
This is a reasonable argument against parsing the output of `ls` within a shell script that you're going to save and reuse in arbitrary directories. It's not a reasonable argument against ever parsing the output of `ls`. If it were, it would also be an argument against humans reading the output of `ls`. The example in your first link makes its point by showing output from `ls` that the human reader can't parse. That doesn't demonstrate that the output of `ls` is "designed for humans, not machine parsing"; it demonstrates that in the general case, its output cannot be parsed by either humans or machines. My rule is that it's ok to use `ls` only in a directory where you know the filenames aren't weird. That rule is the same regardless of whether a human or a computer will be parsing its output. In general, reusable shell scripts shouldn't make assumptions about their environment, so they shouldn't use `ls`; but piping `ls` to another command in a one-off manner at an interactive shell is fine if you know the filenames in the directory aren't weird, just like it would be fine to use `ls` at the same interactive shell and simply read its output yourself.