5 ms·

"ls" is oriented for human viewing, not composition with other tools. It's admittedly bad at that. But there's "find", and there's the convention of separating

by ploxiln 10y ago

"ls" is oriented for human viewing, not composition with other tools. It's admittedly bad at that. But there's "find", and there's the convention of separating filepaths with a null character. Because null cannot occur in a filename, this is an unambiguous list. Programs do "take arguments" (another unambiguous list of null-terminated strings, if you quote them). Like when you specify a command to find with "-exec", for it to run for each file. That's another fine way to do composition. Another example of composition by arguments is "sudo". It switches to root, then runs the arguments as a new process. Another example is ssh, it runs the arguments as on the remote server, and stdin and stdout still work. Check it out: tar -c testdir | ssh devbox sudo tar -C /opt -xv That created an archive from a local directory and wrote it to stdout, into ssh which ran sudo on the remote system, which ran tar, which changed to /opt and extracted an archive from stdin. None of those tools have special handling for each other, but they all work together. "Interesting" filenames in the archive are no problem here either.

boomlinde 10y ago
> "ls" is oriented for human viewing, not composition with other tools. Is there any basis for this claim? My understanding is that many of the GNU ls options are just shorthand for things that you'd traditionally do compositionally. It even reverts to a plain, more pipe-friendly style of output if its stdout is not a TTY. It still sucks at the job if you assume a system where the convention of not using newlines in filenames is ignored. Unix-likes are typically filled with these conventions that will qualify or disqualify any particular approach to a problem, which imposes a certain load on the users, administrators and developers that I assume isn't as severe in Powershell. An inexperienced user will constantly have to second-guess their solutions and may not experience any issues until much later, e.g. when it turns out that their script will have to accept spaces in filenames, or when their `rm -rf "/$INSTALLDIR"` needs to handle unset variables. I'm all cool with this since it offers brevity and a profound flexibility. If you want, you can implement typed, object-passing IPC like Powershell on top of Unix. If you don't, you may be content stream-editing and grepping in file listings to get what you want in the format you need. Besides that, the most compelling case against Powershell that I can thing of is that Windows programs typically aren't very composable. It's conventional for even the most mundane and simple tools to be operated using full-fledged GUIs, if only to offer a file selector and a run button.
- emmelaich 10y ago
  >> "ls" is oriented for human viewing, not composition with other tools. > Is there any basis for this claim? Of course. For starters, there's the fact that the date modified column format depends on how long in the past it was modified! This makes it impossible for `sort` to work with. So suggesting that the `-t` option of `ls` could be removed in favour of using `sort` is entirely wrong. I could go on and on. There are excellent criticisms of UNIX/Linux. This is not one.
  - anon1385 10y ago
    >there's the fact that the date modified column format depends on how long in the past it was modified! Not if you do the sane thing and use the -T option. Of course that requires the user to read another huge man page to find out that such an option exists. I think you have failed to understand the kind of alternative people are proposing. Nobody is saying that the current ls sorting flags should be removed and replaced by passing the output of the current ls command to sort. That would be broken and difficult to use for all the usual reasons that passing around unstructured text is broken and difficult. The idea is passing more structured data between processes so that the problem you describe could never even happen. What you describe is actually the type of issue people want to solve (but in the general case, not just for ls). Formatting data for humans to read and formatting data for machines to read are different problems. Current unix cli tools have to attempt to do both, which often means doing neither well. If you are lucky there are at least some flags you can use to make the output more structured. If you are unlucky the command magically reformats the output based on the type of device it's printing to.
  - boomlinde 10y ago
    I think that you are confusing my argument with another one. I'm not in the "ls should only list files" camp. I'm merely questioning the idea that it isn't oriented towards composability on the basis that even the more featureful implementations revert to a simple filename-newline format that's perfect for stream editing or grepping when their output isn't a TTY. If history is anything to go by this is not an unintended side effect, which would suggest that ls is oriented towards composition, even if poorly and unexclusively so.

by ploxiln 10y ago

boomlinde 10y ago

> "ls" is oriented for human viewing, not composition with other tools. Is there any basis for this claim? My understanding is that many of the GNU ls options are just shorthand for things that you'd traditionally do compositionally. It even reverts to a plain, more pipe-friendly style of output if its stdout is not a TTY. It still sucks at the job if you assume a system where the convention of not using newlines in filenames is ignored. Unix-likes are typically filled with these conventions that will qualify or disqualify any particular approach to a problem, which imposes a certain load on the users, administrators and developers that I assume isn't as severe in Powershell. An inexperienced user will constantly have to second-guess their solutions and may not experience any issues until much later, e.g. when it turns out that their script will have to accept spaces in filenames, or when their `rm -rf "/$INSTALLDIR"` needs to handle unset variables. I'm all cool with this since it offers brevity and a profound flexibility. If you want, you can implement typed, object-passing IPC like Powershell on top of Unix. If you don't, you may be content stream-editing and grepping in file listings to get what you want in the format you need. Besides that, the most compelling case against Powershell that I can thing of is that Windows programs typically aren't very composable. It's conventional for even the most mundane and simple tools to be operated using full-fledged GUIs, if only to offer a file selector and a run button.

emmelaich 10y ago
>> "ls" is oriented for human viewing, not composition with other tools. > Is there any basis for this claim? Of course. For starters, there's the fact that the date modified column format depends on how long in the past it was modified! This makes it impossible for `sort` to work with. So suggesting that the `-t` option of `ls` could be removed in favour of using `sort` is entirely wrong. I could go on and on. There are excellent criticisms of UNIX/Linux. This is not one.
- anon1385 10y ago
  >there's the fact that the date modified column format depends on how long in the past it was modified! Not if you do the sane thing and use the -T option. Of course that requires the user to read another huge man page to find out that such an option exists. I think you have failed to understand the kind of alternative people are proposing. Nobody is saying that the current ls sorting flags should be removed and replaced by passing the output of the current ls command to sort. That would be broken and difficult to use for all the usual reasons that passing around unstructured text is broken and difficult. The idea is passing more structured data between processes so that the problem you describe could never even happen. What you describe is actually the type of issue people want to solve (but in the general case, not just for ls). Formatting data for humans to read and formatting data for machines to read are different problems. Current unix cli tools have to attempt to do both, which often means doing neither well. If you are lucky there are at least some flags you can use to make the output more structured. If you are unlucky the command magically reformats the output based on the type of device it's printing to.
- boomlinde 10y ago
  I think that you are confusing my argument with another one. I'm not in the "ls should only list files" camp. I'm merely questioning the idea that it isn't oriented towards composability on the basis that even the more featureful implementations revert to a simple filename-newline format that's perfect for stream editing or grepping when their output isn't a TTY. If history is anything to go by this is not an unintended side effect, which would suggest that ls is oriented towards composition, even if poorly and unexclusively so.