管道bash字符串操作


9

我读过其他一些管道bash字符串操作问题,但它们似乎是专门的应用程序。

从本质上讲,有没有一种方法可以使以下操作更简单?

代替

$ string='hello world'; string2="${string// /_}"; echo "${string2^^}"
HELLO_WORLD

就像是

$ echo 'hello world' | $"{-// /_}" | "${ -^^}"
HELLO_WORLD

编辑我有兴趣尽可能保持bash操纵以保持速度(与sed / awk相反,后者往往会大大减慢我的脚本的速度)

Edit2:@jimmij

我喜欢第二个示例,并引导我编写了一个函数。

bash_m() { { read x; echo "${x// /_}"; } | { read x; echo "${x^^}"; }; }
echo hello world | bash_m
HELLO_WORLD

1
您为什么认为sed / awk为此目的会变慢?他们跟他们一样快。
mkc 2014年

1
@Ketan Sed和awk是独立的进程,因此它们永远不会很快,因为bash在不启动独立进程的情况下可以本地完成。通常,这种差异几乎不会引起注意,但是在shell脚本中性能通常很重要的情况下,就是某个循环或计算被重复很多次,并且生成数以千计的进程比在bash中进行简单的字符串操作要慢得多。
jw013

2
@ jw013对于问题中的短字符串,如“ hello world”,这是正确的,但如果tr手册说字符串很长,则相反,因为与产生字符串的时间相比,产生进程的时间可以忽略不计sedawk致力于。如果字符串非常长,请参见整个bash手册,则由于某些内部限制,bash可能会完全拒绝继续进行。
jimmij 2014年

2
@ jw013我声称bash的字符串操作的代码效率不高则专用工具sedawktr或类似的。看一下gena2x答案,我在一段时间前编辑了它,确切地添加了以下信息:unix.stackexchange.com/questions/162221/…您可能想将它与同一个问题的terdon答案进行比较,在该问题中他给了一些时间来输入短字符串,其中案例处理产生时间最多。您可以自己测试并发布结果。
jimmij 2014年

1
@Miati为什么您认为这额外read x; echo $x的性能会更好?该语法看起来并不简短或更简洁。x=${x// /_}; x=${x^^}{read x; echo ${x...。相同的方法是一种更简洁的方法。就性能而言,@jimmij指出tr/ sed将比bash,叉数相等要快。使用管道始终会导致额外的过程,因此保存分叉的论点不再适用。因此,如果使用管道,则只需使用sed/ tretc read x; echo $x
jw013

Answers:


9

吉米吉说了什么。他的最后一个示例是您在管道表达式中尝试获得的最接近的示例。

这是该主题的一个变体:

echo 'hello world'|echo $(read s;s=${s^^};echo ${s// /_})

我倾向于使用tr,因为它非常快。

echo 'hello world'|tr ' [:lower:]' '_[:upper:]'

我认为bash不允许嵌套参数扩展很可惜。OTOH,此类嵌套表达式的使用很容易导致难以阅读的代码。除非您确实需要使事情尽可能快地运行,否则最好编写易于阅读,理解和维护的代码,而不要编写看起来像是要调试的PITA的聪明代码。而且,如果您确实确实需要以最快的速度完成操作,则应该使用编译后的代码,而不是脚本。


7

您不能以这种方式传递参数扩展。当以形式形式x使用$符号时"${x}",它必须是实变量名称,而不是标准输入,至少不是in bash。在zsh您可以通过以下方式进行嵌套替换参数:

$ x=''hello world'
$ echo ${${x// /_}:u}
HELLO_WORLD

(注::uzsh一样^^bash

无法嵌套在bash中,我认为您所写的是最好的,但是如果出于任何奇怪的原因需要将管道包含在等式中,则可以尝试以下方法:

$ echo 'hello world' | { read x; echo "${x// /_}"; } | { read y; echo "${y^^}"; }
HELLO_WORLD

1
考虑到我们最近关于tr/ 如何sedbash字符串处理更快的讨论,并考虑如何使用管道通过标准I / O传递字符串,与tr/ 相比,在bash中执行这些操作实际上是零点sed。为什么有人会| { read x; echo $x... }反对| sed做同样的事情呢?
jw013

1
@ jw013坦白地说,我几乎看不到任何内容。这只是强制解决问题的管道的一个示例,因为OP明确要求它们并且不希望使用外部程序(echo并且read都是bash内置程序,因此原则上要快一些)。正如我已经在答案中写到的那样,OP在问题中对OP的最佳处理是我认为最好的bash任务。无论如何,这个问题是学术上的。
jimmij 2014年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.