我正在尝试使用Bash脚本来获取某些日志条目，并通过exec和swatch生成更加用户友好的通知电子邮件。但是，我发现当swatch选择相应的日志文件行以匹配特定应用程序时，Bash脚本错误地显示sh: script: No such file or directory。
这似乎是由于有问题的日志行输出如下：
[2017-05-22 20:00:41] somehost someapp[3999]: INFO: <script>: bad stuff happened bruh
我已经使用rsyslog到/ var / log / messages和secure这样的输出测试了脚本，这不会导致问题。我正在尝试进行这些通知的这个特定应用程序只是有问题，因为日志行本身包含<script>，我无法排除。具体来说，这似乎与<script一起蹦蹦跳跳，因为我已经搞砸了那些可能被解释为文本之外的日志行中的字符。
有关如何不让Bash脚本尝试将<script>解释为原始日志中的文件/目录的任何想法？如果建议的答案是简单地将其撕掉，那就更好了。我已尝试使用sed -i 's/\<script\>//g ${@}删除<script>以剥离并存储到临时变量，目的是执行以下操作：echo -e "${plainenglish}\n\nThe original log message is:${logline}" >> $outputfile但我得到上述相同的错误。
编辑：更多信息。问题应用程序是Kamailio，其中大部分来自路由执行的日志记录都是由xlog模块编写的。默认情况下，xlog会在您记录的所有内容之前推送<script>。该模块包含前缀的参数覆盖（modparam），默认为<script>。
答案 0 :(得分：0)
我意识到这对于问题和解决方案来说有点具体，但是这里有一个总结，然后是建议：
- 使用Kamailio（SIP服务器/代理等）对xlog配置记录调用某些日志文件（例如：/ var / log / kamailio）
- 使用swatch或某些工具来获取特定的Kamailio日志，目的是通知，例如路由失败或收到的可疑请求（例如：+18928751123@1.1.1.1：5060）
- 使用Bash shell脚本以某种方式清理/规范化相应的日志行以进行调度。
解决方案：在尝试处理日志行时，将xlog的前缀modparam设置为Bash不会将其解释为合法命令（脚本是合法命令）。
一旦Bash处理到达默认xlog生成的日志文件行中的<script>行，它就会被抛入歧途。