Stupid shell I/O redirection question...

Stupid shell I/O redirection question...

Post by d.. » Fri, 02 Feb 1990 01:12:00



        Forgive me for being lazy and not finding the (one true) answer myself,
but I've always wanted to know how to do the following:

        I have a shell script which issues commands that generate output on
both the stdout and stderr (1 and 2). I want to redirect both stdout and stderr
of the script through a pipe (without hacking the script (the same question
would apply to a single program that wrote on 1 and 2, anyways). Like this:

cmd:
        time date
        time who

        The time command writes its answer to stderr while date and who write
to stdout. I then wish to redirect both outputs to a pipe, say tee to both see
and capture the results (I know I could use script, etc.) The best solution I
could find is:

        (cmd 2>&1) | tee log

        I believe this wastes a shell, but just removing the () doesn't work
since the 2>&1 (dup syscall) happens before the pipe is created. Perhaps

        (exec cmd 2>&1) | tee log

        Well is there some other syntax or funny combination of >|12& to use ?

 
 
 

Stupid shell I/O redirection question...

Post by d.. » Sat, 03 Feb 1990 00:10:00


Quote:>    I have a shell script which issues commands that generate output on
> both the stdout and stderr (1 and 2). I want to redirect both stdout and stderr

        To partially answer my own question, upon further experimentation, it
does appear that

        cmd 2>&1 | tee log

does do what I wanted. I was trying,

        time date 2>&1 | tee log

which doesn't work. But I think that is because "time" is built into the Korn
shell that I am using. Only

        (time date 2>&1) | tee log

works, although

        /bin/time date 2>&1 | tee log

also works.

        Which brings up the even more stupid question of how do you control
when the dup() occurs. Suppose you DID want the stderr to be the OLD stdout
and the NEW stdout to be the pipe. (why, well...)

 
 
 

Stupid shell I/O redirection question...

Post by d.. » Sat, 03 Feb 1990 00:47:00


File descriptors can be handled very clearly and simply by using
the fact that 'exec' with no command can be used to redirect
file descriptors in the current shell.

Let's say that you want to redirect standard error to a file and
standard out to the old standard error. This can be done by

        exec 9>&1                # fd 9 is now a duplicate of stdout
        exec 1>&2                # stdout is now a duplicate of stderr
        2>file command...    # stderr goes to 'file'
        exec 1>&9                # stdout restored to original

The idea is that you can save any file descriptor in one that isn't
being used (9 is a good candidate since it stands out), and restore
it at a later time.

The Bourne shell has some very useful features hidden in it (I still
am amazed at the prompt changing on the fly that is implemented using
traps and an infinite loop sending signals).
--
                        David Elliott

UUCP:   {decvax,ucbvax,ihnp4}!decwrl!mips!dce, DDD:     408-720-1700

 
 
 

1. --stupid question but then there are no stupid questions--

        I'm a beginner here so, so far everything i read has gone
    way over my head. My problem is I got a script sent to me
    decoded or something like that. You are supposed to enter the
    data into a uudecode or something but I'm not sure how that's
    done. There's a program on the university's main menu that
    called UUDECODE but everytime I run it through it, it says it
    can't open the file. Comments ??????? Help ?

        eric

2. has anyone know adaptec ana-62044 driver for linux

3. Stupid, stupid, stupid...

4. Can Ping network But can't get to the Internet

5. Stupid, stupid, stupid! FAT access rights...

6. New: Debug: sleeping function called from illegal context at include/linux/rwsem.h:43

7. stupid stupid stupid

8. NetWare printing?

9. Stupid or not so stupid questions

10. A/UX C Shell Programming Stupid Question

11. Shell scripts......stupid newbie question

12. Stupid, stupid question

13. Stupid question about remote shell cammands.