5 ms·

> because no-one will be removing /bin/ls with exa installed. Why not? I would.

bipson 9y ago
Yeah, that's the thing: built in gnu tools might be used by other tools/scripts/etc. - if you're ls isn't there or delivers unexpected output, they will fail miserably or cause havoc
- SSLy 9y ago
  s/you're/your/
- xyproto 9y ago
  No script should parse ls output, though. There are always better ways than parsing ls output.
  - inopinatus 9y ago
    The POSIX specification for ls's output is sufficiently precise[1] that it is quite reasonable to rely upon it. As a result, many scripts from a diverse array of vendors do so. A cursory glance at my home Ubuntu server has 'ls' invoked in many of the base package installation scripts and more besides. One could sometimes use find(1) of course, but it has different semantics and output to ls unless you jump through some very silly command-line hoops that will make you say "should've just used ls". As for the stat(1) program, which might be an alternative for individual files, it is not standardised, is not portable, and is in fact totally incompatible between GNU coreutils and BSD userland (including Mac OS). [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html#tag_20_73_10 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls...
    - LambdaComplex 9y ago
      Let me quote that thing you linked to: "As with many of the utilities that deal with filenames, the output of ls for multiple files or in one of the long listing formats must be used carefully on systems where filenames can contain embedded white space." POSIX is such a system. If you try to parse the filenames output by ls, it will break when you encounter a filename with whitespace in it. Use a shell glob instead—it will actually work right.
      - inopinatus 9y ago
        A shell glob cannot tell you the size, owner, permissions, timestamps of a file. For that .. oh look! There's ls(1). Which, by the way, spits out whitespace it sees just fine, unless you specified -q or implied it with output to a tty. If some code can't handle the result, it's that code that is broken. Tip: the only really problematic character is a newline; if you think you could be seeing those, you can still deal with it programatically, but I use find(1). In the meantime, I recommend you try deleting /bin/ls from your system and then filing bugs against everything that breaks.
        LambdaComplex 9y ago
        Alright, here's an example: touch 'file with spaces' for file in $(ls); do rm -- "$file" done This will not work, because $(ls) will get expanded to three items, not one. rm will be called on the files "file", "with", and "spaces"...which is not what was intended. Now do this: touch 'file with spaces' for file in *; do rm -- "$file" done This works correctly.
        aabbcc1241 9y ago
        ls -Q this will quote the file name for pipe operation
        LambdaComplex 9y ago
        Still doesn't work. touch 'file with spaces' for file in $(ls -Q); do echo "$file"; done This prints: "file with spaces"
  - unkown-unknowns 9y ago
    xyproto, exactly my opinion too.

Yeah, that's the thing: built in gnu tools might be used by other tools/scripts/etc. - if you're ls isn't there or delivers unexpected output, they will fail miserably or cause havoc

SSLy 9y ago
s/you're/your/
xyproto 9y ago
No script should parse ls output, though. There are always better ways than parsing ls output.
- inopinatus 9y ago
  The POSIX specification for ls's output is sufficiently precise[1] that it is quite reasonable to rely upon it. As a result, many scripts from a diverse array of vendors do so. A cursory glance at my home Ubuntu server has 'ls' invoked in many of the base package installation scripts and more besides. One could sometimes use find(1) of course, but it has different semantics and output to ls unless you jump through some very silly command-line hoops that will make you say "should've just used ls". As for the stat(1) program, which might be an alternative for individual files, it is not standardised, is not portable, and is in fact totally incompatible between GNU coreutils and BSD userland (including Mac OS). [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html#tag_20_73_10 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls...
  - LambdaComplex 9y ago
    Let me quote that thing you linked to: "As with many of the utilities that deal with filenames, the output of ls for multiple files or in one of the long listing formats must be used carefully on systems where filenames can contain embedded white space." POSIX is such a system. If you try to parse the filenames output by ls, it will break when you encounter a filename with whitespace in it. Use a shell glob instead—it will actually work right.
    - inopinatus 9y ago
      A shell glob cannot tell you the size, owner, permissions, timestamps of a file. For that .. oh look! There's ls(1). Which, by the way, spits out whitespace it sees just fine, unless you specified -q or implied it with output to a tty. If some code can't handle the result, it's that code that is broken. Tip: the only really problematic character is a newline; if you think you could be seeing those, you can still deal with it programatically, but I use find(1). In the meantime, I recommend you try deleting /bin/ls from your system and then filing bugs against everything that breaks.
      - LambdaComplex 9y ago
        Alright, here's an example: touch 'file with spaces' for file in $(ls); do rm -- "$file" done This will not work, because $(ls) will get expanded to three items, not one. rm will be called on the files "file", "with", and "spaces"...which is not what was intended. Now do this: touch 'file with spaces' for file in *; do rm -- "$file" done This works correctly.
        aabbcc1241 9y ago
        ls -Q this will quote the file name for pipe operation
        LambdaComplex 9y ago
        Still doesn't work. touch 'file with spaces' for file in $(ls -Q); do echo "$file"; done This prints: "file with spaces"
- unkown-unknowns 9y ago
  xyproto, exactly my opinion too.