I'm trying to figure out what the equivalent version of the following bash command(s) is in sh, first, say I have a named pipe called myfifo and I run:
cat <(echo hello) myfifo
I get
hello
then it waits for something to be written to myfifo, if on another terminal I run:
echo world > myfifo
finally I get:
hello
world
then the command terminates and I'm back at the shell ready to write new commands. This is what you'd expect from that command, I want to replicate this exact behavior in sh. Now since sh doesn't have process substitution an alternative command would be:
echo hello | cat - myfifo
if I run that in bash I again get the same behaviour as the first command BUT if I run that in sh the command NEVER ENDS, what I mean by that is that I do get hello and then it waits to print whatever is written to myfifo which it does do but once it does it doesn't terminate, the only things I can do then is Ctrl-C out of it or keep piping stuff into myfifo which it keeps printing. This seems to be something specific to sh since in bash you get the same behaviour as
cat <(echo hello) myfifo
Does anyone know what can I do so it does the same in sh??? by the way I'm running this on mac, haven't tried it on linux yet but I need it to run on mac.
Availability of named pipes is dependent on the OS, not the shell.
You can use them like this, whether on bash or sh:
mkfifo myfifo
echo foo > myfifo
cat myfifo
Or with file descriptors:
mkfifo myfifo
exec 3<> myfifo
echo foo >&3
cat <&3
# close fd
exec 3>&-
The <(cmd) or >(cmd) syntax is process substitution, which is slightly different. It’s used to substitute a file argument with a command’s input or output. It’s implemented in bash and other shells, but not POSIX sh.
process substitution example:
grep pattern <(echo foo)
Or
curl -o >(grep pattern) https://example.com/foo.txt
From man bash
Process substitution is supported on systems that support named pipes (FIFOs) or the /dev/fd method of naming open files.
I know how to redirect stdout to a file:
exec > foo.log
echo test
this will put the 'test' into the foo.log file.
Now I want to redirect the output into the log file AND keep it on stdout
i.e. it can be done trivially from outside the script:
script | tee foo.log
but I want to do declare it within the script itself
I tried
exec | tee foo.log
but it didn't work.
#!/usr/bin/env bash
# Redirect stdout ( > ) into a named pipe ( >() ) running "tee"
exec > >(tee -i logfile.txt)
# Without this, only stdout would be captured - i.e. your
# log file would not contain any error messages.
# SEE (and upvote) the answer by Adam Spiers, which keeps STDERR
# as a separate stream - I did not want to steal from him by simply
# adding his answer to mine.
exec 2>&1
echo "foo"
echo "bar" >&2
Note that this is bash, not sh. If you invoke the script with sh myscript.sh, you will get an error along the lines of syntax error near unexpected token '>'.
If you are working with signal traps, you might want to use the tee -i option to avoid disruption of the output if a signal occurs. (Thanks to JamesThomasMoon1979 for the comment.)
Tools that change their output depending on whether they write to a pipe or a terminal (ls using colors and columnized output, for example) will detect the above construct as meaning that they output to a pipe.
There are options to enforce the colorizing / columnizing (e.g. ls -C --color=always). Note that this will result in the color codes being written to the logfile as well, making it less readable.
The accepted answer does not preserve STDERR as a separate file descriptor. That means
./script.sh >/dev/null
will not output bar to the terminal, only to the logfile, and
./script.sh 2>/dev/null
will output both foo and bar to the terminal. Clearly that's not
the behaviour a normal user is likely to expect. This can be
fixed by using two separate tee processes both appending to the same
log file:
#!/bin/bash
# See (and upvote) the comment by JamesThomasMoon1979
# explaining the use of the -i option to tee.
exec > >(tee -ia foo.log)
exec 2> >(tee -ia foo.log >&2)
echo "foo"
echo "bar" >&2
(Note that the above does not initially truncate the log file - if you want that behaviour you should add
>foo.log
to the top of the script.)
The POSIX.1-2008 specification of tee(1) requires that output is unbuffered, i.e. not even line-buffered, so in this case it is possible that STDOUT and STDERR could end up on the same line of foo.log; however that could also happen on the terminal, so the log file will be a faithful reflection of what could be seen on the terminal, if not an exact mirror of it. If you want the STDOUT lines cleanly separated from the STDERR lines, consider using two log files, possibly with date stamp prefixes on each line to allow chronological reassembly later on.
Solution for busybox, macOS bash, and non-bash shells
The accepted answer is certainly the best choice for bash. I'm working in a Busybox environment without access to bash, and it does not understand the exec > >(tee log.txt) syntax. It also does not do exec >$PIPE properly, trying to create an ordinary file with the same name as the named pipe, which fails and hangs.
Hopefully this would be useful to someone else who doesn't have bash.
Also, for anyone using a named pipe, it is safe to rm $PIPE, because that unlinks the pipe from the VFS, but the processes that use it still maintain a reference count on it until they are finished.
Note the use of $* is not necessarily safe.
#!/bin/sh
if [ "$SELF_LOGGING" != "1" ]
then
# The parent process will enter this branch and set up logging
# Create a named piped for logging the child's output
PIPE=tmp.fifo
mkfifo $PIPE
# Launch the child process with stdout redirected to the named pipe
SELF_LOGGING=1 sh $0 $* >$PIPE &
# Save PID of child process
PID=$!
# Launch tee in a separate process
tee logfile <$PIPE &
# Unlink $PIPE because the parent process no longer needs it
rm $PIPE
# Wait for child process, which is running the rest of this script
wait $PID
# Return the error code from the child process
exit $?
fi
# The rest of the script goes here
Inside your script file, put all of the commands within parentheses, like this:
(
echo start
ls -l
echo end
) | tee foo.log
Easy way to make a bash script log to syslog. The script output is available both through /var/log/syslog and through stderr. syslog will add useful metadata, including timestamps.
Add this line at the top:
exec &> >(logger -t myscript -s)
Alternatively, send the log to a separate file:
exec &> >(ts |tee -a /tmp/myscript.output >&2 )
This requires moreutils (for the ts command, which adds timestamps).
Using the accepted answer my script kept returning exceptionally early (right after 'exec > >(tee ...)') leaving the rest of my script running in the background. As I couldn't get that solution to work my way I found another solution/work around to the problem:
# Logging setup
logfile=mylogfile
mkfifo ${logfile}.pipe
tee < ${logfile}.pipe $logfile &
exec &> ${logfile}.pipe
rm ${logfile}.pipe
# Rest of my script
This makes output from script go from the process, through the pipe into the sub background process of 'tee' that logs everything to disc and to original stdout of the script.
Note that 'exec &>' redirects both stdout and stderr, we could redirect them separately if we like, or change to 'exec >' if we just want stdout.
Even thou the pipe is removed from the file system in the beginning of the script it will continue to function until the processes finishes. We just can't reference it using the file name after the rm-line.
Bash 4 has a coproc command which establishes a named pipe to a command and allows you to communicate through it.
Can't say I'm comfortable with any of the solutions based on exec. I prefer to use tee directly, so I make the script call itself with tee when requested:
# my script:
check_tee_output()
{
# copy (append) stdout and stderr to log file if TEE is unset or true
if [[ -z $TEE || "$TEE" == true ]]; then
echo '-------------------------------------------' >> log.txt
echo '***' $(date) $0 $# >> log.txt
TEE=false $0 $# 2>&1 | tee --append log.txt
exit $?
fi
}
check_tee_output $#
rest of my script
This allows you to do this:
your_script.sh args # tee
TEE=true your_script.sh args # tee
TEE=false your_script.sh args # don't tee
export TEE=false
your_script.sh args # tee
You can customize this, e.g. make tee=false the default instead, make TEE hold the log file instead, etc. I guess this solution is similar to jbarlow's, but simpler, maybe mine has limitations that I have not come across yet.
Neither of these is a perfect solution, but here are a couple things you could try:
exec >foo.log
tail -f foo.log &
# rest of your script
or
PIPE=tmp.fifo
mkfifo $PIPE
exec >$PIPE
tee foo.log <$PIPE &
# rest of your script
rm $PIPE
The second one would leave a pipe file sitting around if something goes wrong with your script, which may or may not be a problem (i.e. maybe you could rm it in the parent shell afterwards).
I know exec is for executing a program in current process as quoted down from here
exec replaces the current program in the current process, without
forking a new process. It is not something you would use in every
script you write, but it comes in handy on occasion.
I'm looking at a bash script a line of which I can't understand exactly.
#!/bin/bash
LOG="log.txt"
exec &> >(tee -a "$LOG")
echo Logging output to "$LOG"
Here, exec doesn't have any program name to run. what does it mean? and it seems to be capturing the execution output to a log file. I would understand if it was exec program |& tee log.txt but here, I cannot understand exec &> >(tee -a log.txt). why another > after &>?
What's the meaning of the line? (I know -a option is for appending and &> is for redirecting including stderr)
EDIT : after I selected the solution, I found the exec &> >(tee -a "$LOG") works when it is bash shell(not sh). So I modified the initial #!/bin/sh to #!/bin/bash. But exec &>> "$LOG" works both for bash and sh.
From man bash:
exec [-cl] [-a name] [command [arguments]]
If command is not specified, any redirections take effect in the
current shell, [...]
And the rest:
&> # redirects stdout and stderr
>(cmd) # redirects to a process
See process substitution.
I'm writing a bash script and using the following trick to redirect standard output into a named pipe which is consumed by tee:
exec > >(tee -a $LOGFILE) 2>&1
However, when the script exits, it does not return the shell until I press enter. Is there a simple way to fix this while still using this approach?
Edit: This is the environment I'm running this in:
Centos 7
Bash version 4.2.45
Contents of simple script called redirect.sh:
#!/bin/bash
exec > >(tee -a /tmp/haha) 2>&1
echo "hi there"
exit 0
Sample session:
[root#linux-ha-1 ~]# ./redirect.sh
[root#linux-ha-1 ~]# hi there
[root#linux-ha-1 ~]#
The prompt is being printed; unfortunately, it is printed before tee's output is printed (which is why it appears before hi there in the sample output).
Since the tee process is running asynchronously, there is no guarantee that it will send its output to the console before the script terminates. What you really want to do is to close the tee process and then wait for it to terminate before exiting from the script. This cannot be done with process substitution, unfortunately, but it can be accomplished either with coprocesses (in bash 4) or using named pipes, as is explained in the answer to bash: How do I ensure termination of process substitution used with exec?
For a simpler (but unreliable) solution, close the pipes feeding the tee process (which will force it to close) and then wait a few milliseconds:
#!/bin/bash
exec 3>&1 > >(tee -a /tmp/haha) 2>&1
echo "hi there"
exec 1>&3 2>&3
sleep 0.1
I'm looking for a solution (similar to the bash code below) to copy both stdout and stderr to a file in addition to the screen within ksh on Solaris.
The following code works great in the bash shell:
#!/usr/bin/bash
# Clear the logfile
>logfile.txt
# Redirect all script output to a logfile as well as their normal locations
exec > >(tee -a logfile.txt)
exec 2> >(tee -a logfile.txt >&2)
date
ls -l /non-existent/path
For some reason this is throwing a syntax error on Solaris. I assume it's because I can't do process substitution, and I've seen some posts suggesting the use of mkfifo, but I've yet to come up with a working solution.
Does anyone know of a way that all output can be redirected to a file in addition to the default locations?
Which version of ksh are you using? The >() is not supported in ksh88, but is supported in ksh93 - the bash code should work unchanged (aside from the #! line) on ksh93.
If you are stuck with ksh88 (poor thing!) then you can emulate the bash/ksh93 behaviour using a named pipe:
#!/bin/ksh
# Clear the logfile
>logfile.txt
pipe1="/tmp/mypipe1.$$"
pipe2="/tmp/mypipe2.$$"
trap 'rm "$pipe1" "$pipe2"' EXIT
mkfifo "$pipe1"
mkfifo "$pipe2"
tee -a logfile.txt < "$pipe1" &
tee -a logfile.txt >&2 < "$pipe2" &
# Redirect all script output to a logfile as well as their normal locations
exec >"$pipe1"
exec 2>"$pipe2"
date
ls -l /non-existent/path
The above is a second version to enable stderr to be redirected to a different file.
How about this:
(some commands ...) 2>&1 | tee logfile.txt
Add -a to the tee command line for subsequent invocations to append rather than overwrite.
In ksh, the following works very well for me
LOG=log_file.$(date +%Y%m%d%H%M%S).txt
{
ls
date
... whatever command
} 2>&1 | tee -a $LOG