views:

47

answers:

3

Hypothetical situation. I have a command line program in *nix (linux, BSD, etc.). It was written so that you pass it a text file as an argument

$ program file.txt

Run the program, it looks at the text in file.txt.

Is it possible to "trick" this program into accepting input from a file stream rather than reading a file via disk? I'm pretty comfortable using unix pipes to do stuff, but there's still something a little mysterious about their internals that make it so I can't say (definitively) yes or not to the above question.

+2  A: 

bash lets you do this:

program <(otherprogram)

This uses the output of otherprogram as the contents of a file passed to program.

Ignacio Vazquez-Abrams
wow, that's a really nice trick!!
hasen j
That's pretty neat. What's it called, and is is possible to use if hte program accepts TWO different file paths? (something like diff)
Alan Storm
Process substitution, and yes, you can use... up to 60 or so I think.
Ignacio Vazquez-Abrams
Sweet (more info here for the curious http://tldp.org/LDP/abs/html/process-sub.html)
Alan Storm
Piping a file into a process's stdin is not the same as a process taking a filename and explicitly opening that file.
Ether
@Ether: Try again. This doesn't pipe it into stdin.
Ignacio Vazquez-Abrams
+3  A: 

You may be interested in named pipes:

mkfifo myPipe
program myPipe &
anotherProgram > myPipe

is equivalent to:

anotherProgram | program
mouviciel
A: 

if your program is not coded to accept standard input, it won't work even if you use named pipes or process substitution

I think 1ch1gO is saying that using a named pipe will only work if the program is written to work on a stream. You can pass a named pipe as an argument, but if the program tries to seek it will very likely fail. Often, programmers are sloppy and do not check if a seek failed, so the program may fail in unusual ways.
William Pursell