命令执行顺序有问题

发布于 2025-02-01 15:43:27 字数 189 浏览 1 评论 0原文

cat <<lim | sleep 5 | ls >file2 | cat <<lim | grep wow | cat <<lim 

在此示例中,我不明白为什么睡眠执行在执行结束时开始。如果你们中的任何一个有来源或解释此处的文档的工作以及他如何从输入中保存数据,请分享。

cat <<lim | sleep 5 | ls >file2 | cat <<lim | grep wow | cat <<lim 

In this example, I don't understand why sleep execution begins at the conclusion of the execution. If any of you have a source or explanation of how this here document works and how he saves the data he gets from input, please share.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

嗼ふ静 2025-02-08 15:43:27

不要这样做。

a pipe 字符基本上将其左操作数的Stdout连接到其右操作数的stdin上。那是

您为什么要 这样做?

ls >file2 | cat <<lim # 2 redirections out, 2 in!

&gt; file2放在ls将其输出重定向到file2
管道上没有什么。
cat上放置一个doc,将其输入从 shere 的部分重定向,因此,它再次忽略了管道。你为什么在这里有管道?

如果您只希望这些事情同时发生,但是

ls >file2 & cat <<lim

我承认我真的不知道您做了什么。
您是否期望改变管道行为的本地文件名称WOW和LIM?我不能说。

尝试查看 this> thisce 。希望他们会帮助。

详细说明 -
任何过程的输入默认为FD0。
通常是控制台,例如,您的键盘。
从文件(cat&lt; file)重定向将FD0连接到该文件。
管道数据是另一种重定向的形式,替换了FD0-
例如,echo foo | GREP -O OO应该输出oo

这里是输入重定向的另一种形式。
给定流的命令行重定向均按顺序实现。因此,给定Echo 2&gt; 2

$: cat # read keyboard; end with CTRL_D, gives it right back.
hi!<CTRL_D>
hi!
$: cat <<< bar # reads from the here-string
bar
$: echo 1 | cat # reads from the pipe
1

但是如果您开始混合它们,则上次发生的任何重定向将有效。

$: echo 1 | cat <<< bar <<END # reads from the here-DOC as last
3
END

3

$: echo 1 | cat <<END <<< bar # reads from the here-STRING as last
3
END

bar

$: echo 1 | cat <<END <<< bar <2 # reads from the file 2 as last
3
END

2

$: echo 1 | cat <<END <<< bar <2 < <(echo 4) # reads the echo 4
3
END

4

这些相同的原则适用于输出重定向。

这是允许调整文件描述符的原理...

ls bogus 2 2>&1 >log | tee err >&2

这试图列出我们上面使用的文件2和一个不存在的文件,名为bogus。它将将fd2(错误流)重定向到当前fd1的任何地方,默认为“ stdout”;然后,它将FD1重定向到名为log的文件,仅留下错误流到Stdout。然后, pipe 字符将stdout连接到tee程序的stdin,该程序将其复制到名为err的文件以及其自己的stdout,它被重定向回到stderr流。

结果是2个报告到log,但是bogus的错误都向屏幕(在stderr)和err文件报告。 。

但是,除非您知道为什么并且 您在做什么,否则不要这样做。

DON'T DO THIS.

A pipe character basically attaches the stdout of its left operand to the stdin of its right operand. That's what it is for.

Why would you ever do this?

ls >file2 | cat <<lim # 2 redirections out, 2 in!

Putting >file2 on the ls redirects its output to file2.
There is nothing for the pipe.
putting a here-doc on cat redirects its input from the HERE portion, so again, it ignores the pipe. Why do you have pipes here at all?

If you just want these things to happen simultaneously, then

ls >file2 & cat <<lim

but I confess I really have no idea what you did want.
Were there local files names wow and lim that you expected to change the behavior of the pipelines? I can't tell.

Try looking over these. Hope they help.

To elaborate -
input to any process is by default on fd0.
That is usually the console, e.g., your keyboard.
Redirecting from a file (cat < file) attaches fd0 to that file.
Piping data in is another form of redirection, replacing fd0 -
e.g., echo foo | grep -o oo which should output oo.

here-docs are another form of input redirection.
Command-line redirections for a given stream are all implemented in order, as given. Thus, given echo 2>2,

$: cat # read keyboard; end with CTRL_D, gives it right back.
hi!<CTRL_D>
hi!
$: cat <<< bar # reads from the here-string
bar
$: echo 1 | cat # reads from the pipe
1

But if you start mixing them, whichever redirection happened last will be in effect.

$: echo 1 | cat <<< bar <<END # reads from the here-DOC as last
3
END

3

$: echo 1 | cat <<END <<< bar # reads from the here-STRING as last
3
END

bar

$: echo 1 | cat <<END <<< bar <2 # reads from the file 2 as last
3
END

2

$: echo 1 | cat <<END <<< bar <2 < <(echo 4) # reads the echo 4
3
END

4

These same principles apply for output redirections.

This is the principle that allows shuffling file descriptors...

ls bogus 2 2>&1 >log | tee err >&2

This tries to list the file 2 we used above and a non-existent file named bogus. It will redirect fd2, the error stream, to wherever fd1 is currently going, which defaults to "stdout"; Then it redirects fd1 to the file named log leaving only the error stream going to stdout. Then the pipe character connects stdout to the stdin of the tee program, which duplicates it to the file named err as well as its own stdout, which is redirected back to the stderr stream.

The result is that the 2 reports to log, but the error for bogus reports both to the screen (on stderr) and to the err file.

But don't do this unless you KNOW WHY and exactly what you are doing.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文