Crontab 三重重定向

Rip*_*eeb 1 shell ksh io-redirection

我对重定向有一个非常基本的了解,但是我遇到了一个带有我不理解的重定向的 cronjob。

00 19 * * 1-5 /apps/app/scripts/doit.sh a np cron > /apps/app/scripts/doit.log > /dev/null 2>&1
Run Code Online (Sandbox Code Playgroud)

我看到三个重定向。我打算在这里写下我的最佳猜测,但我无法形成全貌。如果有人帮助我理解 STDOUT 和 STDERR 术语,我将不胜感激。

我的外壳是 ksh:

:> ps -p $$
  PID TTY          TIME CMD
23947 pts/0    00:00:00 ksh
Run Code Online (Sandbox Code Playgroud)

slm*_*slm 5

那里有 2 个重定向。最后一点,2>&1实际上是将 STDERR 与 STDOUT 合并。在我看来,这就像有人将其设置为将输出记录到doit.log文件中,但随后又想禁用它。

以这种方式链接重定向,基本上否定了之前的重定向,因此只有输出(如果有)才会被定向到最后一个重定向的文件。

例子

$ echo "string" > 1.txt > 2.txt 2>&1
Run Code Online (Sandbox Code Playgroud)

导致这些文件:

$ ls -l 1.txt 2.txt
-rw-rw-r--. 1 saml saml 0 Dec 26 15:12 1.txt
-rw-rw-r--. 1 saml saml 7 Dec 26 15:12 2.txt

$ more 1.txt 2.txt 
::::::::::::::
1.txt
::::::::::::::
::::::::::::::
2.txt
::::::::::::::
string
Run Code Online (Sandbox Code Playgroud)

所以你可以看到文件1.txt是空的,所有的输出都被定向到最后一个文件2.txt.

那么为什么要这样做呢?

正如我所提到的,我的猜测是 syadmin 或任何维护它的人,开始收集doit.log最初的输出,但是一旦事情稳定下来,或者doit.log他们不再需要额外的开销;他们添加了 a> /dev/null来使 cron 的输出安静。

  • 它合并来自 STDERR 的所有输出并将其重定向到 STDOUT。这发生在将任何内容写入文件之前。 (2认同)