Hacker News Reader

Comment by l0b0 | Hacker News Reader

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.

View on HN

Are you sure it didn't work? How does the output look if you change the single quotes in "'$filename'" to some other character? (I mean, the point of this snippet is to parse the output of ls, i.e. assign each path to $filename, once, and then use it in some way. Of course the newline will still be there if you just echo the name.)

As per my original comment, literally any separator other than NUL (or slash if you're only ever dealing with filenames, not paths, even though that would be hella confusing) breaks with some filenames. Just use NUL.

With the given options, ls is no longer trying to separate "raw" filenames with any character. Rather, it encodes them unambiguously, and hence we can parse the newline-separated output just fine. You can see the same "trick" used in one of the links of your first comment (the one that warns against parsing ls output).

The example produces ambiguous output. But you can count the number of times echo was called to see that it worked.

    $ touch $'foo\'\n\'bar'
    $ ls --quoting-style=shell-escape-always | while read -r escaped; do
    >   eval "filename=$escaped"
    >   echo "[$filename]"
    > done
    [foo'
    'bar]

Reply on news.ycombinator.com