Live data from Hacker News

Exa, a modern replacement for ls

the.exa.website

411–420 of 420 posts

Re: Exa, a modern replacement for ls

#411
post #248

Earlier quoted context omitted.

Ignore what they all said. It's proven that adding 3 dimensions of color means the information entropy is at least trippled. If you think about the terminal as a computer interface, then it's pretty obvious that we're bandwidth limited by how much information you can fit onto the page. Any amount of improvement in that bandwidth are certainly welcome changes. Niceties like having color-coded file sizes and filetypes…

ow my eye sockets hurt! I always love when I get punished for something of a genetic and physical nature that I had absolutely no control over whatsoever! but in all fairness, other than what you had to say about colorblind people, I more or less agree with your other words and claims. but seriously: i didn't choose to be colorblind and I honestly do hate it sometimes.

I am mildly colorblind but fortunately this does not impact my life too much. There are exceptions though :

- when I was maybe 12 the ophtalmologist told my father in from of me that I should forget about engineering and science in general. Take it dumbass, I am an engineer and PhD in physics (I had to let this out one day :))

- I was shopping for school supplies this morning and had to ask someone to help me choose the copy books so that they are of various colors and not pink. She was surprised at first but then we ended up with a nice talk.

- I reflashed a router 5 times as the flashing was failing, the LED was red. My brother was walking by and told me it is actually green, ending my agony. The router survived.

- a support guy flew cross country once to support my switches which were failing. As you can imagine they were not, I thought that the LEDs were red but they were green (maybe the ophthalmologist was right after all. Still a dumbass for saying this in front of a pre-teen geek who could have listened and go for liberal arts)

- my boss (a lady) told me that I wear interesting color combinations. I thought I was always wearing a combinaison of beige and pale blue. I was not.

Re: Exa, a modern replacement for ls

#412

Earlier quoted context omitted.

It's not overriding anything, so you're ranting against a faulty premise. The command is called "exa", not "ls", and it isn't even a drop-in replacement -- it doesn't have the same flags. You can't alias "ls" to it.

I don't see it that way. The focus over the qualifier of whether it's "drop-in" misses the point. How else are people going to interpret and use "a modern replacement for ls", in practice? Not to replace the file /bin/ls itself. Users will symlink/PATH/alias exa in as "ls" in front of /bin/ls in their shell for convenience.

AFAIK bash aliases never bleed into the scripts you run. So an alias should be relatively harmless.

Re: Exa, a modern replacement for ls

#413
post #178

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 laz…

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

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

Re: Exa, a modern replacement for ls

#414

If you're interested in learning Rust by watching someone work, the author did several long screencasts of himself working on exa: https://www.youtube.com/channel/UCoBjY7TeCXzOULdiE40Ig1w

Is this a trend? Learning by seeing someone write a program? Because I find it neat.

Re: Exa, a modern replacement for ls

#415
post #377

Earlier quoted context omitted.

I do not like this attitude one bit. exa isn't here to make money, it's here to list files; if somebody can't use the software, then that's one less member of the community and one less person who can offer suggestions, rather than a resource who wouldn't give me a return on my investment. If you're colourblind and two different parts of the interface look too similar to you, then please, raise a bug.

I see where you are coming from (you want your software to be used by as many people as possible), but this really isn't the pragmatic approach to this type of software. For certain products, this approach makes sense. Generally, this approach works for "any software where more adoption means a better experience for an individual user". Examples: a messaging app, anything with its own format (like a word processor),…

Ah, I'm with you now. And yeah, I do agree that a line has to be drawn somewhere. exa would probably fail if used with a screen reader, or heck, it doesn't even work properly under Windows right now. That's a huge market I'm ignoring!

What I've seen people doing is saying that there's no line at all: every feature needs to have its cost justified, every type of user scrutinised to make sure they're not dragging the product down. This is expected behaivour for startups (launch to a limited market first) and big companies (where you need to justify every cost) so I'm not surprised to have encountered it here.

For colourblindness in particular, though, I still think there has to be a way for the default colour scheme to be colourblind-friendly without the experience for everyone else suffering as a result.

Re: Exa, a modern replacement for ls

#416

Earlier quoted context omitted.

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 so…

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.

Re: Exa, a modern replacement for ls

#417

Earlier quoted context omitted.

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 so…

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—i…

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.

Re: Exa, a modern replacement for ls

#418

Earlier quoted context omitted.

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—i…

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…

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.

Re: Exa, a modern replacement for ls

#419

Earlier quoted context omitted.

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…

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

Re: Exa, a modern replacement for ls

#420

Earlier quoted context omitted.

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"
Post reply on HN