When to use named pipes in Windows?

Question

In *nix many command line applications that accept file names as arguments accept pipes also. Example:

anApplication file.txt

Also works with

anApplication | anotherApplication arguments

And the result of the "anotherApplication" is redirected to "anApplication" as it was a file

I learned that the Windows equivalent to this is a "named pipe". I wonder if the command line application must be aware of named pipes to understand it, or if any command line application that accepts a file as argument would work with a named pipe instead.

Answer 1

AFAIK it works the same under Windows as in UNIX. I suppose that some more advanced Win32 Console API functions might bypass this, but you'll have to read the documentation for that.

Answer 2

You've got this quite backwards. Just to be precise:

anApplication file.txt

This runs anApplication with the filename file.txt as the first command line argument.

anApplication | anotherApplication arguments

This runs anApplication with no command line arguments. The standard out is connected to the standard in of anotherApplication which is run with arguments as the command line arguments. This is exactly the same on windows as it is on Unix versions. Named pipes are a completely different OS feature.

A named pipe is a directory entry that looks like a file, but acts like a stream of data that you can attach output and input to.

Answer 3

Note that this is the syntax of cmd.exe.

This sort of pipe redirection should work with any program, so to answer your specific question, the program needs no special code if it is a standard console application.

There is one caveat - if the program is getting input through the special keyboard monitoring forms of runtime API, then redirection won't work.

Answer 4

A named pipe on Windows is a very different thing than what you're talking about. A named pipe is actually a tool for helping to build server applications on Windows, and is roughly equivalent to a "Unix domain socket".

In your situation, whether anApplication works in this situation depends on how the application reacts when executed without a file name on the command line. (I'm talking about the arrangement in your description; the command line is backwards as pointed out by another answer.) If the application reads from stdin when started without a command line, then this sort of shell pipe arrangement will work. If instead, the application prints a help message and exits when started without a file name, then this shell pipe will not work.