81–90 of 99 posts
paste (process1) >(process2) >/dev/null
paste >(process1) > >(process2)
http://zsh.sourceforge.net/Doc/Release/Redirection.html#Redi...
Earlier quoted context omitted.
No, that's not why you were down voted. You were down voted because you were condescending to the people who enjoy working with *nix.
It really is a question that I've been having for a long time. I didn't just say that to piss people off. I guess that's the risk you run of coming across when you try to insert yourself in a conversation where the other participants have already agreed on a set of shared opinions - this is great - and you try to question that common assumption/opinion. I have honestly been questioning my own understanding of pipe ,…
Earlier quoted context omitted.
A bit OT but I don't understand why Google doesn't supply a way to do strict searches where everything you input is interpreted literally.
They have, I have complained loudly about this[1], never hard anything back (this is SOP I understand), but I have seen improvements last year. Double quotes around part of a query means make sure this part is actually matched in the index. (I think they still annoy me be including sites that are linked to using this phrase[2], but that is understandable.) Then there is the "verbatim" setting that you can activate un…
diff (sort a.txt|psub) (sort b.txt|psub)
Nice article. Really easy to follow introduction. I only discovered process substitution a few months ago but it's already become a frequently used tool in my kit. One thing that I find a little annoying about unix commands sometimes is how hard it can be to google for them. ' Unless you know to look for "Process Substitution" it can be hard to find information on these things. And that's once you even know these thi…
A bit OT but I don't understand why Google doesn't supply a way to do strict searches where everything you input is interpreted literally.
So they'd have to create a second index for probably less than 0.01% of their queries, and that second index would be larger and harder to compress.
As much as I'd love to see a strict search, from a business perspective I don't think it makes sense to a provide one.
Earlier quoted context omitted.
It really is a question that I've been having for a long time. I didn't just say that to piss people off. I guess that's the risk you run of coming across when you try to insert yourself in a conversation where the other participants have already agreed on a set of shared opinions - this is great - and you try to question that common assumption/opinion. I have honestly been questioning my own understanding of pipe ,…
Perhaps try questioning shared opinions without using the word worship?
Earlier quoted context omitted.
That's actually one of the things that I really dislike with bash, that it doesn't read the whole script before executing it. I've been bitten by it before, when I write some long-running script, then e.g. write a comment at the top of it as it's running, and then when bash looks for the next command, it's shifted a bit and I get (at best) a syntax error and have to re-run :-(
There are several ways to get Bash to read the whole thing before executing. My preferred method is to write a main() function, and call main "$@" at the very end of the script. Another trick, useful for shorter scripts, is to just wrap the body of the script in {}, which causes the script to be a giant compound command that is parsed before any of it is executed; instead of a list of commands that is executed as rea…
Earlier quoted context omitted.
Ahhhh..haaa...ha....DOH! I've never even thought of looking at the manpage for bash before. Thanks, you've just made my life better.
If you're interested in stock Posix shell rather than bashish, the dash man page is a whole lot shorter and easier to follow, makes a great concise reference.
Once you discover # avoid temporary files when some program needs two inputs: join -e0 -o0,1.1,2.1 -a1 -a2 -j2 -t$'\t' \
> # gawk doesn't care if it's given a regular file or the output fd of some process: Something wonderful I found out the other day: Bash executes scripts as it parses them, so you can do all kinds of awful things. For starters, bash will have bash execute an infinite script that looks like echo hello echo hello echo hello ... without trying to load the whole thing first. After that, you can move onto having a script…
To this day, when the shell launches your program, you can find the shell-script it's executing as file-descriptor 255, just in case you want to play any flow-control shenanigans.
Earlier quoted context omitted.
Well, in any case, the problem can be resolved by adding a kernel-level api function that allows one to wait (block) until results are requested from the other end of the pipe.
Why? The opposite is already true and has the same effect. Each stage of the pipeline is executed when it has data to execute. So ultimately the main blocking event is IO (normally the first stage in a pipeline). Every other process is automatically marked as blocked, until its stdin is populated by the output of the former. Once its task is complete it re-checks stdin, and if nothing is present blocks itself. So the…