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

For the Love of Pipes

blog.jessfraz.com

Post reply on HN
Print view View original

171–180 of 323 posts

Re: For the Love of Pipes

#171

Post by icedchai »

arendtio wrote: post #123
yaakushi wrote: post #85

I'm probably nitpicking, but if you're using cat to pipe a single file into the sdtin of another program, you most likely don't need the cat in the first place, you can just redirect the file to the process' stdin. Unless, of course, you're actually concatenating multiple files or maybe a file and stdin together. Disclaimer: I do cat-piping myself quite a bit out of habit, so I'm not trying to look down at the author…

In fact, I don't like people optimizing shell scripts for performance. I mean, shell scripts are slow by design and if you need something fast, you choose the wrong technology in the first place. Instead, shell script should be optimized for readability and portability and I think it is much easier to understand something like 'read | change >write' than 'change write'. So I like to write pipelines like this: cat foo…

If the order is your concern, you can also put the <read at the beginning of the line. <file grep x works the same as: cat file | grep x

Re: For the Love of Pipes

#173

Post by masklinn »

agumonkey wrote: post #165
masklinn wrote: post #42

Earlier quoted context omitted.

Smalltalk's "method cascading" (the `;` operator) did roughly that. I don't think you're forking an entire sequence of methods though, it just allows performing operations on the same root object e.g. a foo ; bar ; baz would sequentially send "foo", "bar" then "baz" to "a", then would return the result of the last call. The ability to fork iterators (which may be the semantics you're actually interested in) also exis…

I see.. but I wonder if st syntax allows for more than methods: a (foo duh meh)

I don't think the first line is even valid, it translates to

    a.(foo.duh.meh)
in e.g. ruby.

Re: For the Love of Pipes

#176

Post by jcelerier »

If you want to see what the endgame of this is when taking the reasoning to the maximum, look at visual dataflow languages such as Max/MSP, PureData, Reaktor, LabVIEW...

Like always, simple stuff will be simple (http://write.flossmanuals.net/pure-data/wireless-connections...) and complicated stuff will be complicated (https://ni.i.lithium.com/t5/image/serverpage/image-id/96294i...).

No silver bullet guys, sorry. If you take out the complexity of the actual blocks to have multiple small blocks then you just put that complexity at another layer in the system. Same for microservices, same for actor programming, same for JS callback hell...

Re: For the Love of Pipes

#177

Post by tejtm »

arendtio wrote: post #123
yaakushi wrote: post #85

I'm probably nitpicking, but if you're using cat to pipe a single file into the sdtin of another program, you most likely don't need the cat in the first place, you can just redirect the file to the process' stdin. Unless, of course, you're actually concatenating multiple files or maybe a file and stdin together. Disclaimer: I do cat-piping myself quite a bit out of habit, so I'm not trying to look down at the author…

In fact, I don't like people optimizing shell scripts for performance. I mean, shell scripts are slow by design and if you need something fast, you choose the wrong technology in the first place. Instead, shell script should be optimized for readability and portability and I think it is much easier to understand something like 'read | change >write' than 'change write'. So I like to write pipelines like this: cat foo…

I dunno, You are bringing 5 cores to bear and there is no global interpreter lock which is not a bad start

Re: For the Love of Pipes

#178

Post by jcelerier »

bagrow wrote: post #33
icebraining wrote: post #8

For an alternative view, don't forget to read the section on Pipes of The Unix-Haters Handbook : http://web.mit.edu/~simsong/www/ugh.pdf (page 198)

> When was the last time your Unix workstation was as useful as a Macintosh? Some of that discussion has not aged well :)

... has it ? most people using macs never ever open a terminal.

Re: For the Love of Pipes

#179

Post by jenscow »

testvox wrote: post #150
jenscow wrote: post #116

Earlier quoted context omitted.

I hear what you're saying. However, how can you ensure the output type of one program matches the input type of another?

Allow programs to specify the type of data they can consume and the type of the data they emit. This is how powershell does it (using the dotnet type system).

And the problem is how can you ensure the output type of one program matches the input type of another.

A program emits one type, and the other program accepts another.

Something will be needed to transform one type into another. Imagine doing that on the command line.

Re: For the Love of Pipes

#180

Post by wglb »

This is cool and useful, but not all unix programs follow this convention:

  * find
  * cal
  * vi
  * emacs
  * ls
These don't use one of standard input/standard output. (edited) and are not fully pipeable.

I don't recall seeing a list of programs--tools, in the original description--that distinguish between pipeable and not-pipeable programs.

Also, none of the corrective cat/grep code in these threads point out that grep in fact takes file names, so "cat foo | grep stuff" is just a silly no-op.

Post reply on HN