Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

doc.cat-v.org

Post reply on HN
Print view View original

11–20 of 112 posts

Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

#11

Post by sehugg »

snorkel wrote: post #8

Nope, can't say I've needed to do any 2D pattern matching on the UNIX command line, ever. Sure back in age of dinosaurs when command line was being used for 2D graphics this may have been useful, but ... we have actual GUI interfaces to do that now.

There are plenty of reasons to do graphics on the command line (e.g. batch operations) and anyway that is not at all the main point of the paper, it's just an example.

Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

#13

Post by duncanbojangles »

4ad wrote: post #6
gouranga wrote: post #5

Possibly true, but we have perl, python, ruby to deal with those cases which all embed regex in a structural way. Occasionally you can just convert it to lines first as well and problem solved.

You do realize that this paper is from early 80s and Perl, Python and Ruby did not exist, right? As for your second statement, if you would have read the paper you would have seen why it is not the case.

Perl - Appeared in 1987

A bit late in the 80s, but still.

[Edit] I read your comment too quickly and hadn't noticed that you said "early 80s". My apologies.

Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

#14

Post by Spooky23 »

gouranga wrote: post #5

Possibly true, but we have perl, python, ruby to deal with those cases which all embed regex in a structural way. Occasionally you can just convert it to lines first as well and problem solved.

Keep in mind that Perl4 was the first "big" version of Perl, available in 1991 with the publication of the camel book.

When this was written companies were advertising "Cut and Paste" as a big feature for word processors.

Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

#15

Post by dwc »

snorkel wrote: post #8

Nope, can't say I've needed to do any 2D pattern matching on the UNIX command line, ever. Sure back in age of dinosaurs when command line was being used for 2D graphics this may have been useful, but ... we have actual GUI interfaces to do that now.

Look beyond the immediate, contrived example. Text can have meaningful structure beyond lines, which line-oriented tools handle poorly. So much power is available with UNIX command line tools, but often you must abandon them for python, ruby, or whatever. The proposed modest extension would allow the command line to be comfortably used for a larger problem space.

Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

#17

Post by _delirium »

gouranga wrote: post #5

Possibly true, but we have perl, python, ruby to deal with those cases which all embed regex in a structural way. Occasionally you can just convert it to lines first as well and problem solved.

I don't think they really give you a structural way to use regexes; more of a procedural way, where you can embed regexes within explicit loops that iterate over lines, matching and updating state-variables as you go. Unlike regexes, which are declarative and abstract away the details of the match algorithm and its internal match-progress variables, you are explicitly maintaining the match state there. I find myself writing manual-FSM code like if($scanning_for_new_record) { /.../; }. And even that only really works if you can do a one-pass match, without needing to backtrack across line boundaries.

It's inelegant enough that I sometimes do a two-step process instead: 1) transform the input so that whatever view I want of it maps to a line-oriented format; and then 2) process the result in the standard Unix line-oriented fashion.

Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

#18

Post by sitkack »

His example is poor, but the message is that the body of a record can cross line boundaries. While the UNIX tool chain is predicated on the concept line == record, this doesn't have to be the case. With a generic record level marshalling system the class of problems solved by composing command line tools together would be greatly expanded.

What Pike describes is analogous to the RecordReader in Hadoop.

Post reply on HN