Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This question already has an answer here:

How can I pipe the output of one program to another, but also have it appear on screen.

For example, to duplicate what winds up on the clipboard in dir | clip, or to see what's happening along the way in longer chains.

share|improve this question

marked as duplicate by Karan, soandos, Oliver Salzburg Jun 7 '13 at 20:43

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

@Karan stderr is a separate stream. I think it silently returns some error code (non-zero) when there's a problem. On Linux you can check it with $?, not sure where it is on Windows. But using 2>&1 just merges it with stdout. I actually want to have stdout show up on the screen after being piped. – Louis Jun 1 '13 at 8:46
I know what stderr is. The other question was about redirecting a stream (stderr) to both a file and the screen. Yours is about piping a stream (stdout) and also redirecting it to the screen. TBH I don't see much difference since in both cases what is required is a 2-way stream split and the solution of course is tee. – Karan Jun 1 '13 at 21:54
@Karan I would agree with you if the other question were asking how to do a "two-way stream split", but I believe you are misinterpreting it. The desired redirection in the other question happens with 2>&1, and tee or "splitting" are actually not even required for a solution. It was more of a question of how to use the redirection operators, and tee is just a convenience in that particular solution. In any case, don't think it would make sense to point every question about two-way stream splitting at that solution. If the question/solution were about that, then yes, but it's not. – Louis Jun 10 '13 at 4:03
up vote 5 down vote accepted

If you have a copy of tee that runs on Windows, such that dir | tee NUL | clip loads the clipboard, but doesn't display anything on the screen (behaving as you would expect dir | clip to), try dir | tee con | clip.  (con is short for “console”; it’s Windows’ equivalent of /dev/ttynul, naturally, is Windows’ equivalent of /dev/null.)

share|improve this answer
Nice, I don't get it, but that works great. I was trying to write a console app that would write to the console and do whatever /dev/tty just did, but couldn't figure out how to write to the screen without it going stdout. – Louis Jun 1 '13 at 1:10
Looks like that works, though if you remove the | clip the results seem to be a bit messy and unexpected. Here is a snip of the messy part with dir | tee (which when it works fine, like for a small directory, produces -correctly- the 2 sets of results that it should). This example was done in c:\users\user in windows 7 i've extracted the messy part. Maybe you can reproduce that issue? Also, another funny thing, cygwin's tee doesn't work for your example, though gnuwin32's one does. i.e. this fails C:\>dir | c:\cygwin\bin\tee.exe con | clip – barlop Jun 1 '13 at 5:46
+1, I don't know if there are any other quirks, but CLS does not work properly when sent to CON - it prints a graphical representation of the form feed character instead of clearing the screen. – dbenham Jun 1 '13 at 15:58
@barlop - The garbled output when using TEE with CON without piping stdout to another program is to be expected. The pipe and TEE are both trying to write to the same device simultaneously without any proper locking in place to serialize the events. – dbenham Jun 1 '13 at 16:03
@Louis yeah though dbeham's right(as always!), + it's not really an issue, as there's no practical reason to do dir | tee con alone i.e. not piping or redirect con somewhere. In fact it makes perfect sense, something along the lines of two threads are running concurrently on the cpu, the second not waiting for the first to finish. Note tee filename would be more efficient than tee con > filename. doing dir | tee con, with nothing after it, and if you want no mixing between the two outputs, then you could do dir & dir. – barlop Jun 2 '13 at 6:00

In Linux you have got tee: Wikipedia - tee. You could install GNU core-utils for Windows:


dir | tee clip

Should work just fine but I don't have Windows to try right now.


Another program - wintee You don't have to install coreutils (which I would advise to install anyway).

share|improve this answer
-1 give an example. And tee is usually used for sending output to both screen and a file. He wants it to go to a screen and a command – barlop May 31 '13 at 21:11
-1 for solution which works? Wow... tee will work just fine if command accepts input fro SDTIN. – Chris May 31 '13 at 21:20
If it works, great, give an example to show it and i'll remove the -1. Note that wikipedia says "displays or pipes the output of a command and copies it into a file or a variable." He doesn't want to copy to a file or variable. He wants to have it in both screen and a command. – barlop May 31 '13 at 21:22
@Chris Thanks for the coreutils tip, I'm sure they'll come in handy. Afraid your example creates a file named "clip" and doesn't send anything to clip. I tried dir | tee NUL | clip which fills the clipboard, but doesn't display anything on the screen. – Louis May 31 '13 at 23:08
Oops, what I tried does what it should. – Louis May 31 '13 at 23:25

Not the answer you're looking for? Browse other questions tagged .