4 ms·

Headline reaction: didn’t it used to be simpler to teach loads of things, especially using anything related to technology? “Today in some versions of Linux ls

Headline reaction: didn’t it used to be simpler to teach loads of things, especially using anything related to technology? “Today in some versions of Linux ls puts single quotes around file names...” I recommend a shell that’s intelligent enough to distinguish lines and present them downstream as strings including spaces. I hope not to come across such an odd implementation of ls ...

Spivak 6y ago
This is the default behavior in the GNU coreutils since version 8.25 so it will eventually be every major Linux distro. https://www.gnu.org/software/coreutils/quotes.html https://www.gnu.org/software/coreutils/quotes.html I think the maintainers made a good decision with this change but this page exists because they received a lot of negative feedback. I’m kinda surprised to see people wanting ambiguous output.
- JoelMcCracken 6y ago
  It always surprises me when people are totally unreasonable. I guess I shouldn’t be surprised though.
- saagarjha 6y ago
  Not every major distro ships with coreutils.
- Izkata 6y ago
  > I’m kinda surprised to see people wanting ambiguous output. It's visual noise, and because of column output I never found it ambiguous.
brmgb 6y ago
The quotes are only used outside of pipes. One file per line without quote has always been the comportment of ls when piped (but with shell globbing you rarely if ever have to pipe ls anyway).
- eMSF 6y ago
  Or rather, a newline after each filename. However, as filenames themselves can contain newlines, a single name can span several lines. These new fancy quoting styles actually finally make it possible to parse the output of ls (although I still can't think of a reason to actually do so).
  - l0b0 6y ago
    Except filenames can contain quotes as well as newlines, so it is still not possible to parse the output of ls[1][2]. In fact, filenames can contain any byte except for NUL (the terminator) and forward slash (the directory separator). Dealing with this reliably means using NUL separators everywhere, as in `find -print0`, `grep --null`, or any of a shedload of similar flags. Unfortunately POSIX doesn't seem to support any of these, and it's unlikely that NUL support will be universally available everywhere (let alone implemented using the same flags). [1] https://mywiki.wooledge.org/ParsingLs https://mywiki.wooledge.org/ParsingLs [2] https://unix.stackexchange.com/q/128985/3645 https://unix.stackexchange.com/q/128985/3645
    - eMSF 6y ago
      Quotes are a non-issue. The classic problem is that we can't tell apart newlines that are part of filenames, and newlines that separate filenames; however, recent coreutils ls provides an alternate format where this is not an issue. It's not pretty, and it shouldn't be done but it's doable (in many shells, but none of this is specified in POSIX): ls --quoting-style=shell-escape-always | while read -r escaped; do eval "filename=$escaped" echo "'$filename'" done
      - l0b0 6y ago
        Doesn't work: $ cd "$(mktemp --directory)" $ touch $'foo\'\n\'bar' $ ls --quoting-style=shell-escape-always | while read -r escaped; do > eval "filename=$escaped" > echo "'$filename'" > done 'foo' 'bar' There's no way to tell that that's one file rather than two. Seriously, parsing ls output reliably isn't possible. I've seen exactly one example of a legitimate ls in a script (just this week, for the first time in many years using Bash), and all that did was to check something like whether a directory was empty.

Spivak 6y ago

This is the default behavior in the GNU coreutils since version 8.25 so it will eventually be every major Linux distro. https://www.gnu.org/software/coreutils/quotes.html https://www.gnu.org/software/coreutils/quotes.html I think the maintainers made a good decision with this change but this page exists because they received a lot of negative feedback. I’m kinda surprised to see people wanting ambiguous output.

JoelMcCracken 6y ago
It always surprises me when people are totally unreasonable. I guess I shouldn’t be surprised though.
saagarjha 6y ago
Not every major distro ships with coreutils.
Izkata 6y ago
> I’m kinda surprised to see people wanting ambiguous output. It's visual noise, and because of column output I never found it ambiguous.

brmgb 6y ago

The quotes are only used outside of pipes. One file per line without quote has always been the comportment of ls when piped (but with shell globbing you rarely if ever have to pipe ls anyway).

eMSF 6y ago
Or rather, a newline after each filename. However, as filenames themselves can contain newlines, a single name can span several lines. These new fancy quoting styles actually finally make it possible to parse the output of ls (although I still can't think of a reason to actually do so).
- l0b0 6y ago
  Except filenames can contain quotes as well as newlines, so it is still not possible to parse the output of ls[1][2]. In fact, filenames can contain any byte except for NUL (the terminator) and forward slash (the directory separator). Dealing with this reliably means using NUL separators everywhere, as in `find -print0`, `grep --null`, or any of a shedload of similar flags. Unfortunately POSIX doesn't seem to support any of these, and it's unlikely that NUL support will be universally available everywhere (let alone implemented using the same flags). [1] https://mywiki.wooledge.org/ParsingLs https://mywiki.wooledge.org/ParsingLs [2] https://unix.stackexchange.com/q/128985/3645 https://unix.stackexchange.com/q/128985/3645
  - eMSF 6y ago
    Quotes are a non-issue. The classic problem is that we can't tell apart newlines that are part of filenames, and newlines that separate filenames; however, recent coreutils ls provides an alternate format where this is not an issue. It's not pretty, and it shouldn't be done but it's doable (in many shells, but none of this is specified in POSIX): ls --quoting-style=shell-escape-always | while read -r escaped; do eval "filename=$escaped" echo "'$filename'" done
    - l0b0 6y ago
      Doesn't work: $ cd "$(mktemp --directory)" $ touch $'foo\'\n\'bar' $ ls --quoting-style=shell-escape-always | while read -r escaped; do > eval "filename=$escaped" > echo "'$filename'" > done 'foo' 'bar' There's no way to tell that that's one file rather than two. Seriously, parsing ls output reliably isn't possible. I've seen exactly one example of a legitimate ls in a script (just this week, for the first time in many years using Bash), and all that did was to check something like whether a directory was empty.