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

181–190 of 323 posts

Re: For the Love of Pipes

#181

Post by dearrifling »

OskarS wrote: post #168
msla wrote: post #154

Earlier quoted context omitted.

I find something like this: grep '^x' to be very readable, as the flow is still visually apparent based on punctuation.

I don't like this style at all. If you're following the pipeline, it starts in the middle with "input", goes to the left for the grep, then to the right (skipping over the middle part) to sed. cat input | grep '^x' | sed 's/foo/bar/g' Is far more readable, in my opinion. In addition, it makes it trivial to change the input from a file to any kind of process. I'm STRONGLY in favor of using "cat" for input. That "usele…

Note that '<input grep | foo' is also valid.

Re: For the Love of Pipes

#182

Post by fooblat »

wglb wrote: post #180

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…

Well find, cal, and ls don't take input at all. And vi (well vim) in fact does. If you invoke it with a - for the file name argument, it will read standard input into the buffer. I can't comment on emacs as I don't use it much.

Re: For the Love of Pipes

#183

Post by jolmg »

Leace wrote: post #102
majewsky wrote: post #69

Earlier quoted context omitted.

If bots were not discouraged on news.yc, I would have implemented a bot for this long ago. Code-block quotes are so atrocious, esp. on mobile devices.

It seems "white-space: pre-wrap" on code block would solve most of the problem. There is also additional "max-width" on the pre that I think is not needed.

I agree with you on the max-width. I can't see whatever benefit it's supposed to provide outweigh the annoyance of having to scroll horizontally when there is a lot of empty space to the right that could be used to display more text.

I'm not too convinced on the wrapping of code, though.

Re: For the Love of Pipes

#184

Post by maximilianburke »

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…

I can see how it's redundant. But I use cat-pipes because I once mistyped the redirection and nuked my carefully created input file :)

(Similarly, the first thing I used to do on Windows was set my prompt to [$p] because many years ago I also accidentally nuked a part of Visual Studio when I copied and pasted a command line that was prefixed with "C:\...>". Whoops.)

Re: For the Love of Pipes

#185

Post by kakarot »

Leace wrote: post #102
majewsky wrote: post #69

Earlier quoted context omitted.

If bots were not discouraged on news.yc, I would have implemented a bot for this long ago. Code-block quotes are so atrocious, esp. on mobile devices.

It seems "white-space: pre-wrap" on code block would solve most of the problem. There is also additional "max-width" on the pre that I think is not needed.

white-space: pre-wrap on a code block could lead to confusion. Any change should be an optional setting in your user profile.

However you're definitely right about dropping the max-width property.

Re: For the Love of Pipes

#186

Post by wglb »

Asooka wrote: post #156
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)

The section on find after pipes has also not aged well. I can see why GNU and later GNU/Linux replaced most of the old Unices (I mean imagine having a find that doesn't follow symlinks!). If I may, a bit of code golf on the problem of "print all .el files without a matching .elc" find . -name '*.el' | while read el; do [ -f "${el}c" ] || echo $el; done Of course this uses the dreaded pipes and doesn't support the ext…

So the dreaded space-in-filenames is a problem when you pass the '{}' to a script.

The following works very nicely for me:

  * find . -name '*.el' -exec file {}c ';' 2>&1 | grep cannot

Re: For the Love of Pipes

#187

Post by sigjuice »

msla wrote: post #154
arendtio wrote: post #123

Earlier quoted context omitted.

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 find something like this: grep '^x' to be very readable, as the flow is still visually apparent based on punctuation.

You can just remove the <

Re: For the Love of Pipes

#188

Post by msla »

sigjuice wrote: post #187
msla wrote: post #154

Earlier quoted context omitted.

I find something like this: grep '^x' to be very readable, as the flow is still visually apparent based on punctuation.

You can just remove the <

You can if input is a file. It might be a program with no arguments or something else.

Re: For the Love of Pipes

#189

Post by foreigner »

cmsj wrote: post #172

pipe junkies might like to know about the following tools: * vipe (part of https://joeyh.name/code/moreutils/ - lets you edit text part way through a complex series of piped commands) * pv ( http://www.ivarch.com/programs/pv.shtml - lets you visualise the flow of data through a pipe)

Yes! I love pv. Besides that and tee, can anyone else suggest some more general pipe tools?

Re: For the Love of Pipes

#190

Post by michaelfeathers »

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 like 'collection pipeline' code written in this style regardless of language. If we took away the pipe symbols (or the dots) and just used indentation we'd have something that looked like asm but with flow between steps rather than common global state.

I periodically think it would be a good idea to organize a language around.

Post reply on HN