如何使 echo 与 read in bash 兼容？

Question

我试过这个：

qs@BF:~$ echo aaa | read c
qs@BF:~$ echo $c

它什么也没给出，这意味着 $c 是一个空宏。

但为什么以下一个有效：

qs@BF:~$ cat trim.hs | read cc
qs@BF:~$ echo $cc
import qualified Data.Text as T

它正确地给出了 trim.hs

的第一行

当 echo 与 read 进行管道连接时，接缝会出现异常。我对吗？你能帮我让 echo 与 read 兼容吗？请。

Answer 1

两者都不是"work"

echo aaa | read c
cat trim.hs | read cc

在bash中，管道中的命令都在子shell中执行。因此，read 命令在 subshell 中设置变量 c ，但随后 subshell 退出并且其环境消失

为了演示，让我们使用分组结构在子shell 中查询$c 的值：

unset c echo 123 | { read c; echo in subshell: ">$c<"; } echo in parent: ">$c<"

产出

in subshell: >123< in parent: ><

bash 确实有一个设置允许管道中的 last 命令到 current 中的运行 ] shell:

set +m # job control must be disabled shopt -s lastpipe # enable the option unset d echo 456 | read d echo ">$d<"

>456<

Answer 2

我认为这里的根本问题是 read 在运行中的子外壳。这些不会（总是）将值传播到您的调用。

从 POSIX read standard 它概述了如何在子 shell 中使用 read 对调用者不可见：

If it is called in a subshell or separate utility execution environment, such as one of the following:
(read foo)
nohup read ...
find . -exec read ... \;
it shall not affect the shell variables in the caller's environment.

并在 these shell tips 中注明：

POSIX allows any or all commands in a pipeline to be run in subshells, and which command (if any) runs in the main shell varies greatly between implementations — in particular Bash and ksh differ here. The standard idiom for overcoming this problem is to use a here document:
IFS= read var << EOF
$(foo)
EOF

如何使 echo 与 read in bash 兼容？

How to make echo compatible with read in bash?

linux

bash

command-line

pipe

echo