Your redirection assumes that what you are interested in capturing comes from STDOUT (file descriptor #1). Well-behaved Unix tools produce output to STDOUT, but write *errors* to STDERR (file descripter #2).
Consider:
# cp 1> /dev/null
...still shows the usage of the command on your terminal; but:
# cp 2> /dev/null
...relagates the text to the bit-bucket.
If you want to capture both STDOUT and STDERR in a file, do:
# mycommand > filename 2>&1
That means redirect STDOUT to 'filename' and then redirect STDERR (file descriptor #2) to the same place as file descriptor #1 (STDOUT). The order is very important.
the script i am using is interactive one and is asking for username and password. probably this could be the reason it is not able to redirect the output to a file. i used $somecommand | tee but it didn't work.
Depending on your application, you may find it difficult or impossible to get usuable output redirected to a file. This is especially true of curses/ncurses-based programs or interactive programs.
The 'script' or 'screen' commands may be of some use, but for certain programs, you will need to take screenshots or scrollback buffer dumps. For example, in PuTTY, right-click on the title bar and choose "Copy All To Clipboard". Or drag your cursor over the area of interest to select and copy. Then paste into vim/EditPlus/notepad.
script /tmp/logfile.txt su shiv login: shiv password: xxx bdf ll exit ( exits out of su session) exit (exits out of script command and saves the file).
The syntax '2>&1' means that file descriptor 2 (STDERR) is duplicated to file descriptor 1 (STDOUT). That is, STDERR is treated as a duplicate of STDOUT. Output which is directed to STDERR (FD #2) is written to the same place as STDOUT (FD #1).
