Hacker News Reader

Comment by userbinator | Hacker News Reader

Wow, the comments in this thread are quite harsh.

I wonder if a lot of that has to do with how it's being "marketed" --- it might just be me, but whenever I see "modern" being used to describe something, it evokes the negative connotations of being trendy, fashionable, boring, vapid, fleeting, style-over-substance that's all too common with software today (Windows' "modern UI/Metro" being one of the first examples to come to mind); not exactly the right sentiment for promoting a tool that's supposed to be long-lasting, foundational, and practical.

Perhaps if the title didn't contain "modern", the discussion here would go in a different direction.

View on HN

Maybe. Whether the term "modern" was used or not, my hunch is that the response would be the same, for it is forbidden for one to deign to make these kinds of changes to fundamental Unix commands, and is tantamount to a kind of heresy (never mind that GNU implementations did this all the time wrt. original Unix implementations).

Religion... never cared for it. Re-invent the whole crappy (though still less crappy than alternatives) Unix command line, I say.

Of course you hear the same complaints about GNU Coreutils. In general complaining about GNU-isms and GNU bloat is a time-honored tradition

Amen! (:giggles:)

I doubly agree for reinventing fundamentals or attempting to. To be fair, given how resilient unix tools have been, this following and to some extent the harshness is to be expected, I think

A lot of stuff depends on the basic Unix commmands though. It might be better to invent a new command name if the output differs in ways that would break both human and machine expectations. The difference between BSD and GNU versions of some commands is already enough to trip me up even after all these years. You expect `ls` to be `ls` on anything remotely POSIX/Unix-y.

I like the ideas in this tool, but it's very end-user oriented and by being written in Rust with stuff like minor Git functionality built in, definitely not as general purpose as a command like plain old `ls`.

I'd suggest describing it as a "colourful alternative" rather than a "modern replacement", because no-one will be removing /bin/ls with exa installed. "Replacement" strongly implies removal of the thing being replaced, as with "replacement hip", "replacement CEO" etc.

As for why anyone might feel aggrieved about replacement of core Unix services, my mind immediately drew a (possibly unfair, but emotionally comparable) parallel with systemd.

> because no-one will be removing /bin/ls with exa installed.

Why not? I would.

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

s/you're/your/

No script should parse ls output, though. There are always better ways than parsing ls output.

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...

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.

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.

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.

  ls -Q

this will quote the file name for pipe operation

Still doesn't work.

  touch 'file with spaces'
  for file in $(ls -Q); do echo "$file"; done

This prints:

  "file
  with
  spaces"

xyproto, exactly my opinion too.

Given how half the comments are complaining about the colors and there's a whole thread on whether 3MB is "small" or not... I doubt it.

>I wonder if a lot of that has to do with how it's being "marketed" --- it might just be me, but whenever I see "modern" being used to describe something, it evokes the negative connotations of being trendy, fashionable, boring, vapid, fleeting, style-over-substance that's all too common with software today

For me, when I see people waxing poetically about the unix way and the old, crufty, POSIX userland, it's all about cargo cult, "that's how things have always been", minimum viable progress while keeping compatibility, and heritage-over-substance.

I did some nodejs work the other month, pinch-hitting in a product crunch, we're using grunt.

`grunt test`.. ooh, so pretty and creative! `grunt test > test.out`, wtf, why is my file full of control character bullshit?

To be fair, they could avoid that by checking if stdout is a TTY or not.

That's an amateur hour mistake on their part, frankly. I hope they have a 'switch color off' flag.

Welcome to the JavaScript ecosystem.

Reply on news.ycombinator.com