Hacker News Reader

Comment by krat0sprakhar | Hacker News Reader

Wow, the comments in this thread are quite harsh. Even though I might not use it, this looks like an awesome project - kudos to the author for finding (& implementing) ways to improve something as mundane as ls.

I've long been stuck on finding a suitable (perfect?) project idea to play with Rust but exa is making me think through again!

Thanks for sharing this and also for your screencasts. I'd definitely spend a lazy evening watching you program exa.

View on HN

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.

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.

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.

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.

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

Writing `ls` is the first thing I do when learning a new language.

Hah, interesting! Mine is writing a simple web server (sockets, IO, string handling) and an ultra-simple command line browser (args handling, 3rd party libs for URLs, HTML parsing, etc.)

And all along I thought I was creative for skipping "Hello, World" and going straight to "Hello, World" 10 times

mine is doing everything in hackerrank in the new language

I like to write chip-8 and other VMs to get a handle Of a new lang

Mine in similar, I implement an authoritative domain name server. I've done it in something like 20-25 languages now. The only language I've learned in the last decade I didn't write one in is ARM Assembly. I am not that "dedicated" (more like masochistic) enough to try to do one in assembly.

I tend to reimplement the Linux kernel from scratch a few times in every language and go from there onto the X server, desktop environment, networking stack, etc.

Github link? ;)

A friend of mine used to learn new languages by implementing Tetris in them.

Sad to say I'm here years later and I still haven't even implemented Tetris once in anything.

Thanks for the kind words, everybody.

exa was my first Rust project and it just grew and grew.

It looks neat. You should include a link to the documentation on the homepage. After I saw the screenshot I went looking to see how easy it would be to change some of the colors before I installed it. I read down below that the colors are baked in:(

It would also be nice to see files owned by different users and some of the git functionality.

Would you consider reflecting and writing about your experiences using Rust?

Don't be worried about the hate.

ls is a gold standard but that doesn't mean alternatives aren't interesting. Especially as a FOSS project in rust I find it fascinating.

Nice! I just downloaded it here ... My suggestion is to include an option to list the hidden files (dot files) as well as some file sorting options in the next version of Exa. ;-)

You must have had an easy time with Ruby, then.

  #!/usr/bin/env ruby
  `ls`

You haven't written ls in Ruby, you've called ls with Ruby. Big difference!

Is it useful to learn how to do system calls and formatted output for the kind of programming work that you do?

It would be nice if it implemented the exact same set of command line flags as ls plus whatever else it does. That way I'd be able to use it as a replacement when I type 'ls', much as 'vi' fires up 'vim'.

Typing commands like 'ls -ltra' are already muscle memory to me and that takes effort to change.

oh great, but shouldn't it then also behave exactly like ls does, i.e. deliver the same output whenever a script of yours or somebody else calls ls and expects a certain output?

oh wait, I know what behaves exactly the same way: ls

Reply on news.ycombinator.com