By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Piping and redirection: CON:

Can anyone explain why this works:
while this doesn't:

(Just to get a better understanding of the inner workings)
An analogy (?):

Think of the tap on your kitchen sink. "Open tap" produces water and the normal destination for that water is "down the drain". If you want to "filter" the water before it goes to the normal destination, you "pipe" it to the filter. Technically, the output of "open tap" becomes the input of "filter" and the output of "filter" goes to the normal destination (down the drain). That would be

"open tap" | "filter"

Maybe you want to filter it in many ways:

"open tap" | "filter1" | "filter2"

If, you'd rather have the water go into a pitcher (than down the drain), you "redirect" the output.

"open tap" | "filter" > "pitcher"

At this point it's over; the water has reached it's destination. If you want do to more (filter further, or change the location of the water) you must start over with an action that produces water, perhaps

"pour water out of pitcher" | "filter3" > "glass"

A bit more technically, the "stdin" and "stdout" streams (programming terms) start with a process that produces data (stdout) which normally is written to the console. You can make things happen to that data (before it reaches its destination) with pipes. Pipes send the stdout of one process to the stdin of another process (not changing the ultimate destination). If you want to change the destination, redirect. Redirection is to a device (file, display, clipboard, ..., not to a process) and after redirection, the input/output chain is finished..

So, your second example is odd in two ways.

1. "DIR > CON:" is, at best, redundant. That's where DIR's output goes by default.

2. After "DIR > CON:" the output has been disposed of. There is no output to send to VIEW.

I may be wrong, but I don't think it makes sense to follow a redirection with a pipe.

I hope all that makes some sense.

Although I knew most of it, I couldn't "pipe" the info together :-)
The thing that did wonder me was that DIR sends it's output to con and so would DIR>CON:
I didn't see the difference, but now I'm enlightened! :-)
P.S., Read about the TEE command for doing two things with output. A little example:
v:\> echo foo^r^nbar | tee clip: | findstr bar

v:\> type clip:
An analogy (?):
I may be wrong, but I don't think it makes sense to follow a redirection with a pipe.

I used it for this, for example:
ATTRIB /D /S c:\* 1>nul |& ssed.exe -e /^TCC.*denied.$/{;N;d} -e /^TCC:.*files.$/d -e s/\\\*//

Redirect standard output of ATTRIB to nul: and whatever remains (i.e standard error ) goes in a pipe (std output + std error) to be processed by SED
Yes, of course it makes sense if you're talking about two different streams.

Similar threads