Live data from Hacker News

Next generation Unix pipe by Alex Larsson

blogs.gnome.org

11–20 of 86 posts

Re: Next generation Unix pipe by Alex Larsson

#12
That is a terrible idea: sometimes the app can take advantage of a constraint to minimize work done.

In your example, if we just wanted to filter for a particular user, dps would have to print out ALL of the information and then you could pick at it. This doesn't seem bad for ps (because there's a hard limit) but in many other examples the output could be much larger than what is needed. That's why having filtering and output flags in many cases is more efficient in generating everything.

As a side note: To demonstrate a dramatic example, I tried timing two things:

    - dumping NASDAQ feed data for an entire day, pretty-printing, and then using fgrep
    - having the dumper do the search explicitly (new flags added to program)
Both outputs were sent to /dev/null. The first ran in 35 minutes, the second in less than 1 minute

Re: Next generation Unix pipe by Alex Larsson

#13
I find the tendency to repeat Microsoft's mistakes deeply disturbing. Even if, in this case, the author acknowledges PoweeShell goes too far, his own idea goes too far.

I'd be all in with flags that make ps or ls spit JSON or XML, but this typed nonsense? What when I want to output a color? Will I need a new type?

Oh... and the sort thing... its not hard to sort numerically.

Re: Next generation Unix pipe by Alex Larsson

#15
post #3

If I can do a slight PG impression, "what problem does this solve?"

Among others, this problem:

http://www.dwheeler.com/essays/fixing-unix-linux-filenames.h...

find -print0 is a lame hack, and even filenames with spaces (not newlines) are somewhat messy to work with on the Unix shell.

Or a little recurring problem I have: How do I grep the output of grep -C (matches showing multiple lines delimited with a "--" line)? I wrote a custom tool to do it, which does the job, but really it would be nice if I could use all the normal line-based Linux tools (sort, uniq, awk, wc, sed) with a match as a "line".

Re: Next generation Unix pipe by Alex Larsson

#17
post #14
post #11

"Even something as basic as numerical sorting on a column gets quite complicated." sort -g -k field_num

Two problems: the header is sorted along with the fields, and you have to look up the field number. Insurmountable? No; but somewhat complicated.

`grep -v` or `tail` seems like a lot easier workaround than desiging a brand new shell piping system. Maybe there are other use cases but sorting numeric fields is definitely not worth the effort. A lot of black magic can be easily conjured up with `col`, `tr`, `cut`, `column`, `head`, `tail`, `grep`, `pr`, and `sort`; and that's without ever even touching `sed` and `awk`.

Re: Next generation Unix pipe by Alex Larsson

#19
I've quickly jotted some thoughts here: http://damnkids.posterous.com/rich-format-unix-pipes

Regarding this version, standardizing on a particular transfer format is a bad idea. If history has shown anything, it's that we like to reinvent this stuff and make it more complicated than necessary (see also XDR, ASN.1, XML, etc. :) pretty much on a 5 year cycle or thereabouts.

Do the bare minimum design necessary and let social convention evolve the rest.

Re: Next generation Unix pipe by Alex Larsson

#20

What about providing a filter that converts to whatever format you can think of? e.g. outputs in JSON or XML

Because what are you converting from? It can't be turtles all the way down, at some point there must be a defined system that everything speaks. Adding output formats after that is relatively simple.
Post reply on HN