4 ms·

>UNIX "ls" tool is a case study in excessive command line switches. 'ls' is a bag of weird (bad?) UX. When first starting on the command line, I could never fi

by arfar 11y ago

>UNIX "ls" tool is a case study in excessive command line switches. 'ls' is a bag of weird (bad?) UX. When first starting on the command line, I could never figure out how grepping the output of ls actually worked. Then I think I looked at some of the code, or someone told me, that when ls outputs, it checks to see where the data is going, if it's STDOUT then it pretty prints columns (and probably other things), otherwise it just the more sane 1 line per item.

breadbox 11y ago
Yes, via the isatty() syscall. ls is hardly the only Unix tool that does this; it's just the most well-known example.
steckerbrett 11y ago
Here I am using `ls -1` for years without realizing the redundancy.
- akkartik 11y ago
  You probably got that into your muscle memory before 'ls' got smarter. I'm sure we all have some habits like that.
- nocman 11y ago
  Don't feel too bad. I didn't know until reading this that sending the output from ls somewhere other than stdout would cause the output to be one-item-per-line either, and I've been using Unix and Linux platforms for a very long time. If I wanted that behavior, I would have typed 'ls -1' also.
jff 11y ago
See today's submission https://news.ycombinator.com/item?id=10198353 https://news.ycombinator.com/item?id=10198353, where the PDF discusses precisely that case and why it's bad.
jewel 11y ago
The isatty(3) system call will let you know if STDOUT is a terminal. There are two cases when you should definitely take advantage of isatty: 1) Your tool, by default, outputs in color. 2) Your tool, by default, outputs progress, which you keep on a single line by overwriting by outputting \r. Both of these potentially annoying when your command is used in a script, and especially annoying if they are called from cron. In other cases I agree with you, getting too creative violates the principle of least surprise.
- nitrogen 11y ago
  In the case of 1/color, I respectfully request that all toolmakers leave an option for forcing color even if STDOUT is not a tty, so I can, for example, use less -R on colorized logs and still get element highlighting.
  - jzwinck 11y ago
    If you get stuck with a tool lacking such an option, you can run it under "script" to trick it. I recall other programs to do similar using a pseudo-TTY but I can't recall their names now (and with a name like "script" it was a miracle I got that one).
thrownaway2424 11y ago
ls is bad but I nominate ps as the ultimate basket case.
- bigger_cheese 11y ago
  Yes I'm a 'ps -ef' guy and my coworker uses 'ps aux' forget vim vs emacs this causes the most arguments.
  - UnoriginalGuy 11y ago
    But aux gives you the %CPU and %MEM columns in addition to what -ef gives you. That's a winner for why I would always opt for using aux. Often times when I am running ps that's exactly the information I want to see. I guess you could argue ef's length as an advantage but if you're on a 1080 screen, meh.
    - gknoy 11y ago
      I only recently learned that fax` prints a tree of processes! Not always what I want, but good to find which python processes are the ones I want to kill, and which are not. :)
      - thrownaway2424 11y ago
        Whoa! I always use pstree for that.
    - bigger_cheese 11y ago
      -ef shows you the parent pid which aux doesn't. My usage for ps tends to be to get pid information so I can kill processes with it. When a misbehaving parents spawns a lot of children easier to kill the parent. I use 'w' command if I want CPU info.
billforsternz 11y ago
I know it is heresy, but what I really want is a switch to make ls more like dir from DOS/Windows.
Animats 11y ago
Early UNIX used "ls | mc", where "mc" was a program to put output in multiple columns. This is in keeping with the UNIX philosophy of one program, one job.
hollerith 11y ago
I just wish Unix command-line tools would refrain from including terminal escape sequences in their output when invoked with TERM=dumb. Homebrew, wget and youtube-dl, I'm looking at you. Although some of these tools can be persuaded to stop including escape sequences with the right switch, the right switch varies with the tool, and learning the right switch to use with a particular tool requires reading a large fraction of a very long man page. In contrast, 20 years ago, IIRC all command-line tools I used respected TERM=dumb. Since isatty() was mentioned, let me point out that directing the output of the tools named above to a named pipe instead of a pseudo-TTY is not enough to get them to stop sending terminal escape sequences.

by arfar 11y ago

breadbox 11y ago

Yes, via the isatty() syscall. ls is hardly the only Unix tool that does this; it's just the most well-known example.

steckerbrett 11y ago

Here I am using `ls -1` for years without realizing the redundancy.

akkartik 11y ago
You probably got that into your muscle memory before 'ls' got smarter. I'm sure we all have some habits like that.
nocman 11y ago
Don't feel too bad. I didn't know until reading this that sending the output from ls somewhere other than stdout would cause the output to be one-item-per-line either, and I've been using Unix and Linux platforms for a very long time. If I wanted that behavior, I would have typed 'ls -1' also.

jff 11y ago

See today's submission https://news.ycombinator.com/item?id=10198353 https://news.ycombinator.com/item?id=10198353, where the PDF discusses precisely that case and why it's bad.

jewel 11y ago

The isatty(3) system call will let you know if STDOUT is a terminal. There are two cases when you should definitely take advantage of isatty: 1) Your tool, by default, outputs in color. 2) Your tool, by default, outputs progress, which you keep on a single line by overwriting by outputting \r. Both of these potentially annoying when your command is used in a script, and especially annoying if they are called from cron. In other cases I agree with you, getting too creative violates the principle of least surprise.

nitrogen 11y ago
In the case of 1/color, I respectfully request that all toolmakers leave an option for forcing color even if STDOUT is not a tty, so I can, for example, use less -R on colorized logs and still get element highlighting.
- jzwinck 11y ago
  If you get stuck with a tool lacking such an option, you can run it under "script" to trick it. I recall other programs to do similar using a pseudo-TTY but I can't recall their names now (and with a name like "script" it was a miracle I got that one).

thrownaway2424 11y ago

ls is bad but I nominate ps as the ultimate basket case.

bigger_cheese 11y ago
Yes I'm a 'ps -ef' guy and my coworker uses 'ps aux' forget vim vs emacs this causes the most arguments.
- UnoriginalGuy 11y ago
  But aux gives you the %CPU and %MEM columns in addition to what -ef gives you. That's a winner for why I would always opt for using aux. Often times when I am running ps that's exactly the information I want to see. I guess you could argue ef's length as an advantage but if you're on a 1080 screen, meh.
  - gknoy 11y ago
    I only recently learned that fax` prints a tree of processes! Not always what I want, but good to find which python processes are the ones I want to kill, and which are not. :)
    - thrownaway2424 11y ago
      Whoa! I always use pstree for that.
  - bigger_cheese 11y ago
    -ef shows you the parent pid which aux doesn't. My usage for ps tends to be to get pid information so I can kill processes with it. When a misbehaving parents spawns a lot of children easier to kill the parent. I use 'w' command if I want CPU info.

billforsternz 11y ago

I know it is heresy, but what I really want is a switch to make ls more like dir from DOS/Windows.

Animats 11y ago

Early UNIX used "ls | mc", where "mc" was a program to put output in multiple columns. This is in keeping with the UNIX philosophy of one program, one job.

hollerith 11y ago

I just wish Unix command-line tools would refrain from including terminal escape sequences in their output when invoked with TERM=dumb. Homebrew, wget and youtube-dl, I'm looking at you. Although some of these tools can be persuaded to stop including escape sequences with the right switch, the right switch varies with the tool, and learning the right switch to use with a particular tool requires reading a large fraction of a very long man page. In contrast, 20 years ago, IIRC all command-line tools I used respected TERM=dumb. Since isatty() was mentioned, let me point out that directing the output of the tools named above to a named pipe instead of a pseudo-TTY is not enough to get them to stop sending terminal escape sequences.