4 ms·

The elephant in the room for me is that > implemented as functions that return first-class values, as opposed to relying on executables that return text stream

The elephant in the room for me is that > implemented as functions that return first-class values, as opposed to relying on executables that return text streams. This makes working with the results simpler Is explicitly disregarding several Unix philosophies, but not really discussing why the author believes those philosophies are wrong. It proceeds to produce code without the (at least in my view) nice properties of Unix shell style pipelines, namely the ability to compose them in novel ways due to a high compatibility between formats. I would welcome a discussion of how the Unix philosophies break down, or what they prevent. But I didn’t find that here.

tomhrr 4y ago
> Is explicitly disregarding several Unix philosophies, but not really discussing why the author believes those philosophies are wrong. I'm not sure I'd characterise these parts of the Unix philosophy as 'wrong'. For example, if you are writing a shell program for use by somebody else, then having that program work with text streams makes sense. The focus here is interactive use and short functions/programs for local use, though, which means that the text stream part of the philosophy becomes a less pressing consideration. > I would welcome a discussion of how the Unix philosophies break down, or what they prevent. But I didn’t find that here. At least as far as text streams go, the readme talks about awkward considerations like '-0' and '-print0', but more generally, when the command doesn't output a known format like XML or JSON, parsing the output can be fun (e.g. per https://stackoverflow.com/a/15643939 https://stackoverflow.com/a/15643939). Oftentimes the response is "the command has flags for getting the data that you want", but it's simpler (IMHO) not to build this sort of functionality into every command, and instead just have the shell support it more nicely, whether by providing a function that produces a first-class value (e.g. 'ls', 'ps' here) or by providing more generic parsing functions (e.g. 'split', 'splitr' here).
- Fnoord 4y ago
  The problem is IMO a lack of a coherent flag to output such. If each CLI program would've a coherent flag, it would make the command line and scripting a tad easier. But with a decent command line history (or tool to parse such, such as history | fzf) its reasonably easy and quick to figure out the past.

tomhrr 4y ago

> Is explicitly disregarding several Unix philosophies, but not really discussing why the author believes those philosophies are wrong. I'm not sure I'd characterise these parts of the Unix philosophy as 'wrong'. For example, if you are writing a shell program for use by somebody else, then having that program work with text streams makes sense. The focus here is interactive use and short functions/programs for local use, though, which means that the text stream part of the philosophy becomes a less pressing consideration. > I would welcome a discussion of how the Unix philosophies break down, or what they prevent. But I didn’t find that here. At least as far as text streams go, the readme talks about awkward considerations like '-0' and '-print0', but more generally, when the command doesn't output a known format like XML or JSON, parsing the output can be fun (e.g. per https://stackoverflow.com/a/15643939 https://stackoverflow.com/a/15643939). Oftentimes the response is "the command has flags for getting the data that you want", but it's simpler (IMHO) not to build this sort of functionality into every command, and instead just have the shell support it more nicely, whether by providing a function that produces a first-class value (e.g. 'ls', 'ps' here) or by providing more generic parsing functions (e.g. 'split', 'splitr' here).

Fnoord 4y ago
The problem is IMO a lack of a coherent flag to output such. If each CLI program would've a coherent flag, it would make the command line and scripting a tad easier. But with a decent command line history (or tool to parse such, such as history | fzf) its reasonably easy and quick to figure out the past.