5 Mar
2020
5 Mar
'20
3:50 a.m.
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.