Re:Next generation Unix pipe by Alex Larsson
by vidarh on Saturday August 11, 2012 @09:44AM
(#4370072)
Your example would be about the same length with awk and sort, with the only caveat that you need to figure out the field numbers, and the upside that I can trust the tools are available pretty much everywhere.
Re:Next generation Unix pipe by Alex Larsson
by alexlarsson on Saturday August 11, 2012 @03:22PM
(#4370757)
Its doable yeah, but its a lot more work.
First you have to handle the header specially (want it in the result but not in the comparisons).
In order to compare by uid you need numeric uids (-n), but that means you can't also get the readable username, so you need a custom output format.
Then you need to ensure the output format is such that nothing with possible spaces or control chars can end up in a column before the data you're looking at, as then finding the right column is hard.
Even then, extracting the first command line arg like in the example will fail in the case of a binary name that has a space in it (as there is no way to know which spaces in the commandline corresponds to actual spaces in the arguments or just delimiters).
Well, what's the awk/sort version?
As you admit your system is not simple to implement but you are correct the onus is on you to create pipes 2.0. But it also means that every other developer is going to have to implement pipes 2.0 compliant output for their program. Unless pipes 2.0 is going to auto-identify everything in addition to nulls?
Re:Next generation Unix pipe by Alex Larsson
by alexlarsson on Saturday August 11, 2012 @04:55AM
(#4369764)
Yes, the weak link here is obviously getting all kinds of output into the pipes 2.0 format. Triggering such output via format negotiation is possible, but you still would have to add support for actually outputting it.
And once this is done any user can avoid having to painstakingly construct pipelines that try to cut out the right columns to treat as numbers, or avoid all the problems parsing strings that may contain spaces or other control characters. You can do an operation like:
filter out all processes with %cpu > 20 with uid > 1000 and sort by second cmdline arg as:
dps | dfilter pcpu ">" 20 uid ">" 1000 | dsort "cmdvect[1]"
Obviously a made up example, but something like this is easy to read and write, whereas something working on tabular ascii data would be quite long and complicated.
As per black magic, I have about the same interpretation as you. I didn't really misunderstand it to be about how complicated it was. However, "black magic" certainly has a feel of "you should not do this", and arguing that you can then use that in order to do something which could instead be simple and obvious in a typed system seems kind of weird.