ksh Logging

aixkidbee · March 21, 2019, 4:31am

Hi,

I want to run my script and want to ensure it captures all logging.

For e.g I got this from another forum

# Redirect the current stderr into stdout
exec 2>&1
# Redirect the current stdout into the log file
exec 1>timer_log.log

The script will print stderr onto the putty terminal and log all script output into timer_log.log
How can I also print the stdout to the putty terminal too.
I am using a KSH script.

Thanks.

RudiC · March 21, 2019, 4:48am

I was thinking about going through your commands one step after the other, assuming both stdout and stderr point to /dev/tty originally. But then I found this is completely covered in man bash :

Do you see the parallel / analogy?

Don_Cragun · March 21, 2019, 5:12am

I was going to say:
Do the exec 's in the other order:

exec 1>timer_log.log
exec 2>&1

or just use one exec :

exec 1>timer_log.log 2>&1

and since 1 is the default output file descriptor, one can shorten that to:

exec >timer_log.log 2>&1

but RudiC beat me to it. Note, however, that since the question is about ksh (not bash ), one should probably read the ksh man page (instead of the bash man page) where it might say something like:

... ... ... For example:

... 2>&1

means file descriptor 2 is to be opened for writing as a duplicate of
file descriptor 1 and

exec {n}<file

means open file named file for reading and store the file descriptor
number in variable n.

The order in which redirections are specified is significant. The
shell evaluates each redirection in terms of the (file descriptor,
file) association at the time of evaluation. For example:

... 1>fname 2>&1

first associates file descriptor 1 with file fname. It then associates
file descriptor 2 with the file associated with file descriptor 1 (i.e.
fname). If the order of redirections were reversed, file descriptor 2
would be associated with the terminal (assuming file descriptor 1 had
been) and then file descriptor 1 would be associated with file fname.

If a command is followed by & and job control is not active, then the
default standard input for the command is the empty file /dev/null.
Otherwise, the environment for the execution of a command contains the
file descriptors of the invoking shell as modified by input/output
specifications.

But since the basic redirections are the same in ksh and bash , either man page covers this issue. However, if the question were about redirecting output to a co-process or to a specific socket on a server, one should definitely use the man page for the shell that is being used.

bakunin · March 21, 2019, 5:15am

In addition to what RudiC already said: if you want to redirect larger parts of a script i would - simply for better readability - not shift around output streams in a way so that one depends on the other. I would set them separately and independently like this:

exec 2>/some/file
exec 1>/some/file

If you later decide to redirect one or the other to somewhere else it won't affect the other redirecction at all.

I hope this helps.

bakunin

Don_Cragun · March 21, 2019, 5:36am

bakunin:

In addition to what RudiC already said: if you want to redirect larger parts of a script i would - simply for better readability - not shift around output streams in a way so that one depends on the other. I would set them separately and independently like this:
exec 2>/some/file
exec 1>/some/file
If you later decide to redirect one or the other to somewhere else it won't affect the other redirecction at all.

I hope this helps.

bakunin

Hi bakunin,
Sorry, but I must strongly disagree with your suggestion.

Opening these two files this way creates two file descriptors pointing at the same file with both writing data starting at position 1 and destructively overwriting each other's previously written data. For example the script:

#!/bin/ksh
exec 2>/some/file
exec 1>/some/file
echo ab
echo oops >&2
echo cd

ends up with the following stored in the file named /some/file :

oopcd