我有一条与此相似的行
grep -oP "data-context-item-title=.*.data-context-item-id" web.html | cut -d'"' -f2
我知道这条线正常工作，因为我在终端上使用它，它给了我想要的输出。但是，我想把这一行放在一个bash脚本中。所以到目前为止我有这个
title="$(grep -oP 'data-context-item-title=.*.data-context-item-id' web.html | cut -d'"' -f2)"
这是一个问题，因为它匹配第一个“（引用）与剪切”（引用）。反正有没有避免它？
没有剪切功能的输出与此类似
data-context-item-title="Some long title" data-context-item-id
data-context-item-title="Another very long title" data-context-item-id
请记住，我不能使用任何sed或awk命令来替换cut。
由于
答案 0 :(得分：3)
由于您正在使用bash，因此使用它是安全的：
title=$(grep -oP 'data-context-item-title=.*.data-context-item-id' web.html | cut -d'"' -f2)
这将保留变量中的内部间距（特别是换行符），因为您可以查看是否这样做：
echo "$title"
我认为如果您设法找到要使用的UNIX™7 th 版本Bourne Shell，则省略$(...)符号周围的双引号（或更准确地说，`...`符号）不安全，但它确实似乎在现代炮弹上安全地工作（比如在当前千年中最后更新的那些，而不是在前一个炮弹中）。困难在于找到一个旧的Bourne Shell来验证我现在摇摇欲坠的（因为遥远的）回忆。
令我感到困惑的是，在Mac OS X 10.7.5上运行bash 3.2（系统）和4.2（自制），无论是否使用双重代码，您的代码都能正常运行$(...)周围的引号。您使用的是哪个版本的bash，以及在哪个平台上使用？
答案 1 :(得分：0)
剪切中的分隔符参数是双引号而不是单引号。使用反向间距来逃避实际报价
答案 2 :(得分：0)
狂野的建议：你的命令中的一个引号是否可能不是普通的ASCII引号，而是某种类型的Unicode花哨引用（shell无法识别）？
答案 3 :(得分：0)
首先，要解决错误，请转义cut的双引号：
title="$(... | cut -d \" ...)"
但是，你正在使用grep的PCRE，所以你可以使用lookarounds和drop cut：
title=$(grep -oP '(?<=data-context-item-title=").*?(?=" data-context-item-id)' web.html)
答案 4 :(得分：-1)
不确定是否是拼写错误，但您似乎忘记了$(...)的右括号