ImH*_*ere 20 shell bash ksh syntax
写一个长管道时，将它分成两行通常会更清楚。
这个长命令行：
ruby -run -e httpd -- -p 5000 . 2>&1 | tee >(grep -Fq 'WEBrick::HTTPServer#start' && open localhost:5000)
可以分为：
ruby -run -e httpd -- -p 5000 . 2>&1 \
| tee >(grep -Fq 'WEBrick::HTTPServer#start' && open localhost:5000)
或者：
ruby -run -e httpd -- -p 5000 . 2>&1 |
tee >(grep -Fq 'WEBrick::HTTPServer#start' && open localhost:5000)
简而言之：
command1 \
| command2
或者：
command1 |
command2
我意识到这可能是一个风格（意见）问题，但是：有没有更喜欢的方式，如果有，为什么？
ctr*_*lor 41
问问你自己这会做什么？
command1 \
| command2
看不出区别。我也不能，但外壳可以。仔细一看，后面有一个空格\。这会阻止换行符被转义。
因此使用另一种形式，因为它更安全。此处显示相同的错误（|在这种情况下，在之后有一个空格）。但它不会导致错误。
command1 |
command2
gid*_*dds 15
我将不同意这里的大多数人；我总是喜欢在连接运算符（例如管道）之前换行：
command1 \
| command 2
（你不需要缩进第二行；管道本身很明显地将它链接到第一行。）
这有几个原因：
更容易看到木匠；它不会迷失在线条的细节中。（如果一行很长，这一点尤其重要，并且连接器可能会被滚动到视线之外，或者在换行中丢失。）当您快速扫描代码时，您会向下看左侧，因为那是整体结构的位置是：在缩进、大括号或特定语言使用的任何内容中。管道和其他细木工对结构很重要，因此它们也应该在左侧。
如果你跨越 3 行或更多行，它会排队。同样，这使得管道的结构一目了然。
它更接近我们的思维方式。（这是最微妙和最有争议的一点……）如果你正在慢慢地读一个清单，以便有人可以把它写下来，你会说“[项目 1]…… （停顿） ……和 [项目 2]…… （停顿） ) … 和 [第 3 项]。”; 说“[项目 1] 和…… （停顿） ……[项目 2] 和…… （停顿） ……[项目 3]”会让人觉得不自然。那是因为我们认为木匠比前一个更附加到下一个项目。（你可以用类似的术语来考虑算术中的减号；它的作用类似于加法，但通过否定它与后面的数字更紧密地联系在一起。）当代码反映我们的想法时，它更容易理解。
多年来，我在多种语言中都尝试过这两种方式，并且发现在大多数情况下将细木工放在下一行确实有帮助。
JoL*_*JoL 10
好吧，只是为了避免它看起来没有人愿意：
command1 \
| command2
我会说我愿意。
我认为 ctrl-alt-delor 提出的尾随空间问题不是问题。编辑可以警告它；git 对此发出警告。最重要的是，shell 会在 上引发语法错误| command2，为用户提供错误的文件和行号并停止解释文件的其余部分：
$ cat f.sh
#!/bin/bash
echo foo \
| command2
echo bar
$ ./f.sh
foo
./f.sh: line 4: syntax error near unexpected token `|'
./f.sh: line 4: `| command2'
还有一个事实是，换行符有更多用途。例如，要中断具有许多参数的简单命令：
ffmpeg \
-f x11grab \
-video_size "$size" \
-framerate "${framerate:-10}" \
-i "${DISPLAY}${offset}" \
-c:v ffvhuff \
-f matroska \
-
我们是否也应该避免这种用法，因为我们不能相信自己不在转义后放置空格？
我的偏好纯粹是一个可读性和主观性的问题。这是我的 shell 历史中的一个真实示例（详细信息替换为 foobar）：
command1 \
| command2
相比于：
org-table-to-csv foobar.org |
cq +H -q "
select foo
from t
where bar = 'baz'
and foo != ''" |
sed -r 's/^|$/'\''/g' |
sed -r ':b;$!{N;bb};s/\n/, /g'
这是另一个：
sed 's/ .*//' <<< "$blame_out"
| sort \
| uniq \
| tee >(sed "s/^/from pipe before grep filtering: /" > /dev/tty) \
| grep -vF "$(git show -s --format=%h "$from_commit")" \
| tee >(sed "s/^/from pipe before git show: /" > /dev/tty) \
| xargs git show -s --format='%cI %h' \
| tee >(sed "s/^/from pipe after git show: /" > /dev/tty) \
| sort -k1 \
| tail -1 \
| cut -d' ' -f2
相比于：
sed 's/ .*//' <<< "$blame_out"
sort |
uniq |
tee >(sed "s/^/from pipe before grep filtering: /" > /dev/tty) |
grep -vF "$(git show -s --format=%h "$from_commit")" |
tee >(sed "s/^/from pipe before git show: /" > /dev/tty) |
xargs git show -s --format='%cI %h' |
tee >(sed "s/^/from pipe after git show: /" > /dev/tty) |
sort -k1 |
tail -1 |
cut -d' ' -f2
我认为这个问题的答案很简单，但我可以看到 @JoL 和 @gidds 不同意我的观点。
My brain prefers reading a line and not having to scan the next line \
:
foo bar baz ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... \
In the above I will have to see \
, what is on line 2 \
, before I can tell \
, what the command does \
. Maybe the command is complete \
? Or maybe the command continues \
on the next line \
?
To me it is much easier to read,
if \ is only used,
when a command cannot fit on a line.
通读我的代码，我也将评论视为一个问题：
foo ... ... ... ... ... ... ... ... |
# Now this does bar
bar ... ... ... ... ... ... ... ... ||
# And if that fails: fubar
fubar
我不知道，如果你使用你会怎么都做在管道中间评论\+换行之前|或||或&&。如果这是不可能的，我认为这是最重要的问题。没有注释的代码是不可维护的，注释通常应该尽可能接近代码，以鼓励在更改代码时更新文档。
Emacs 自动为我做缩进，所以缩进甚至不是额外的负担：
# This is indented automatically in emacs
ruby -run -e httpd -- -p 5000 . 2>&1 |
# Send the output to the screen and to grep
tee >(grep -Fq 'WEBrick::HTTPServer#start' &&
# If grep matches, open localhost:5000
open localhost:5000)
# Here is where emacs indents the next command to