[TUHS] Command line options and complexity

[Random832]

On Tue, Mar 3, 2020, at 13:44, Adam Thornton wrote:
> I've heard people say that there isn't really any alternative to this 
> kind of complexity for command line tools, but people who say that have 
> never really tried the alternative, something like PowerShell. I have 
> plenty of complaints about PowerShell, but passing structured data 
> around and easily being able to operate on structured data without 
> having to hold metadata information in my head so that I can pass the 
> appropriate metadata to the right command line tools at that right 
> places the pipeline isn't among my complaints3 
> <https://danluu.com/cli-complexity/#fn:W>.
> 
> Somewhat disingenuous. I mean, yes, that's true, but on the other hand 
> it means that you have to keep the "what Powershell commands operate on 
> what structure" in your head instead, since you can no longer assume 
> the pipelines to be a universal interface.

Sure, but "stdin is a sequence of any type, and the argument is an expression that operates on that type or the name of a property that that type has" is universal enough.

The part that has to operate on a specific structure isn't the command, it's the arguments.

For example, a powershell pipeline to produce a list of files sorted by modified date is:

gci . | sort lastwritetime | select name

all three *commands* are universal - not all objects have a "lastwritetime" and "name" property, but sort and select can operate on any property that the sequence of objects passed into it has.

(gci is an alias for get-childitem... it also has aliases ls and dir, but I'm emphasizing that it's not exclusive to directories)

*assuming that ls -t didn't exist*, to do this with unix tools that operate on text you would need:

ls -l | [somehow convert the date to a sortable format, probably in awk] | sort | [somehow pick the filename alone out of the output - possibly with cut or sed or awk again]

and it's very difficult to get tools like awk, sort, and cut to work on formats that contain more than one field that may contain embedded spaces (you can just about get away with it for ls output because the date is always three "words").

A significant portion of ls's options are related to sorting, because you can sort based on fields that are either not present in the output, or are not in a format that can be sorted textually.

Maybe it would be enough to have the universal interface be "tables" (i.e. text streams in some format that supports adequate escaping of embedded row and column delimiters)... or maybe even just table rows, and let the user deal with memorizing column numbers (or let each originating command support a fully general way to specify what columns are requested, as ps alone does on modern systems) Of course, this isn't *really* different from allowing any data structure - after all, the value for any field could itself be a fully escaped table in text format.

The benefit of having actual data structures with types is that when you *don't* end the pipeline with select, each object knows how to print itself [files print mode, mtime, size, and name in a human-readable format, more or less equivalent to ls -l] rather than just dumping out every single field that you might want sort or select to operate on.