#!/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

请注意，这是bash，而不是sh。如果您使用sh myscript.sh调用脚本，您将得到一个语法错误，接近意外令牌'>'。

如果使用信号陷阱，可能需要使用tee -i选项来避免出现信号时输出中断。(感谢JamesThomasMoon1979的评论。)

根据写入管道还是终端而改变输出的工具(例如，ls使用颜色和柱状输出)将检测上述结构是否意味着它们输出到管道。

有一些选项可以强制着色/柱状化(例如ls -C——color=always)。注意，这也会导致将颜色代码写入日志文件，使其可读性降低。

接受的答案不保留STDERR作为单独的文件描述符。这意味着

./script.sh >/dev/null

会不会输出条到终端，只到日志文件，和

./script.sh 2>/dev/null

将输出foo和bar到终端。显然不是这样的 一个正常用户可能会期待的行为。这可以是 通过使用两个独立的三通过程都附加到相同的固定 日志文件:

#!/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

(请注意，上面的内容最初并不会截断日志文件——如果你想要这种行为，你应该添加

>foo.log

到脚本的顶部。)

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.

busybox、macOS bash和非bash shell的解决方案

公认的答案当然是bash的最佳选择。我在Busybox环境中工作，没有访问bash，它不理解exec > >(tee log.txt)语法。它也没有正确地执行exec >$PIPE，试图创建一个与命名管道同名的普通文件，该文件失败并挂起。

希望这对那些没有bash的人有用。

同样，对于任何使用命名管道的人来说，rm $ pipe是安全的，因为这将断开管道与VFS的链接，但是使用它的进程仍然在它上维护引用计数，直到它们完成。

注意，使用$*并不一定安全。

#!/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

使用已接受的答案，我的脚本总是异常早地返回(就在'exec > >(tee…)'之后)，让我的脚本的其余部分在后台运行。由于我无法以我的方式得到解决方案，我找到了另一个解决方案/解决问题:

# Logging setup
logfile=mylogfile
mkfifo ${logfile}.pipe
tee < ${logfile}.pipe $logfile &
exec &> ${logfile}.pipe
rm ${logfile}.pipe

# Rest of my script

这使得脚本的输出从进程出发，通过管道进入'tee'的子后台进程，该进程将所有内容记录到磁盘和脚本的原始标准输出。

注意'exec &>'同时重定向stdout和stderr，如果我们愿意，我们可以分别重定向它们，或者如果我们只想要stdout，则更改为'exec >'。

即使管道在脚本开始时从文件系统中删除，它仍将继续工作，直到进程完成。我们只是不能在rm行之后使用文件名引用它。

#!/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

请注意，这是bash，而不是sh。如果您使用sh myscript.sh调用脚本，您将得到一个语法错误，接近意外令牌'>'。

如果使用信号陷阱，可能需要使用tee -i选项来避免出现信号时输出中断。(感谢JamesThomasMoon1979的评论。)

根据写入管道还是终端而改变输出的工具(例如，ls使用颜色和柱状输出)将检测上述结构是否意味着它们输出到管道。

有一些选项可以强制着色/柱状化(例如ls -C——color=always)。注意，这也会导致将颜色代码写入日志文件，使其可读性降低。

Bash 4有一个coproc命令，它建立了一个到命令的命名管道，并允许您通过它进行通信。