根据我在本网站和其他在线资源中发现的内容,它表示在变量周围使用双引号。但那不适合我。
例如:
我的变量是$GTUNNELNATNETIP
[johnwayne:630 ~] GTUNNELNATNETIP=`cat iptables.out |awk '{print $NF}'|cut -d "/" -f1`
[johnwayne:631 ~] echo $GTUNNELNATNETIP
10.19.192.0
[johnwayne:632 ~]
我正在搜索的文件是iptables2.out
不带引号的搜索会找到值但不是没有错误
[johnwayne:632 ~] grep $GTUNNELNATNETIP iptables2.out
grep: : No such file or directory
iptables2.out:-A POSTROUTING -s 10.19.192.0/22 -o eth1 -j SNAT --to-source 64.134.58.175
[johnwayne:633 ~]
它不适用于双引号或单引号。或者我试过的任何其他格式
[johnwayne:633 ~] grep "$GTUNNELNATNETIP" iptables2.out
grep: Trailing backslash
[johnwayne:634 ~] grep '$GTUNNELNATNETIP' iptables2.out
[johnwayne:635 ~] grep `echo $GTUNNELNATNETIP` iptables2.out
grep: : No such file or directory
iptables2.out:-A POSTROUTING -s 10.19.192.0/22 -o eth1 -j SNAT --to-source 64.134.58.175
[johnwayne:636 ~] /bin/grep $GTUNNELNATNETIP iptables2.out
/bin/grep: : No such file or directory
iptables2.out:-A POSTROUTING -s 10.19.192.0/22 -o eth1 -j SNAT --to-source 64.134.58.175
[johnwayne:637 ~]
当我传递实际值时没有错误
[johnwayne:637 ~] grep 10.19.192.0 iptables2.out
-A POSTROUTING -s 10.19.192.0/22 -o eth1 -j SNAT --to-source 64.134.58.175
[johnwayne:638 ~]
那么为什么文件和目录确实存在时会发生grep错误?如何在没有错误的情况下传递变量。我正在尝试计算grep返回的行数,并在没有显示文件名的情况下获取确切的iptables
命令。
[johnwayne:637 ~] /bin/grep 10.19.192.0 iptables2.out
-A POSTROUTING -s 10.19.192.0/22 -o eth1 -j SNAT --to-source 64.134.58.175
[johnwayne:638 ~]
与此相反:
[johnwayne:620 ~] grep $GTUNNELNATNETIP iptables2.out
grep: : No such file or directory
iptables2.out:-A POSTROUTING -s 10.19.192.0/22 -o eth1 -j SNAT --to-source 64.134.58.175
[johnwayne:621 ~]
答案 0 :(得分:3)
你应该引用它
grep "$GTUNNELNATNETIP" iptables2.out
Read more about quoting variables in bash
这必须奏效。
我无法重现您的trailing backslash
错误,但很可能您在$GTUNNELNATNETIP
变量中有一些垃圾
答案 1 :(得分:2)
问题是没有引号的echo $GTUNNELNATNETIP
会导致shell删除“无关紧要”的shell特殊字符。使用echo "$GTUNNELNATNETIP"
你会发现它确实有一个尾随反斜杠,可能还有其他问题。
(更好的是,学习使用printf
,set
或env
来检查变量。)
作业uses cat
uselessly并且无论如何都可以使用一些额外的重构。试试这个?
GTUNNELNATNETIP=$(awk '{split(/\//,g,$NF); print g[1] }' iptables.out)
...但这并没有尝试解决问题,因为我们并不确切知道该值是如何存在缺陷的。也许只是在打印之前添加gsub(/\\/,"",g[1]);
?