在新环境中使用unicode范围的sed表达式出现问题

问题描述 投票:0回答:1

我在几年前编写的干净脚本中有以下

sed
范围替换表达式,该脚本在旧环境中有效(或至少从未给出错误),但在新环境中失败(出现错误),我可以无法确定为什么新旧环境之间的范围无效。
该表达式的目的是从用于将数据导入数据库的 TSV 文件中删除不需要的 unicode 或控制字符。

一行中的表达式示例:

bash

旧环境:Ubuntu v16.04、Bash v4.3.46、GNU Sed v4.2.2
  • 新环境:Ubuntu v20.04、Bash v5.0.17、GNU Sed v4.7
  • 仅在新环境中出错(旧环境中没有错误):

sed -e 's,[\x00\x01-\x08\x0a-\x1f\x7f]\+,,g' file.tsv

我尝试在 
https://www.jdoodle.com/test-bash-shell-script-online

上运行表达式并选择使用 sed v4.7 的 bash v5.0.011 并且它不会产生错误,所以也许这不是 sed 或 bash 的版本问题。 我记不清我是如何组成所使用的字符范围的,或者为什么看起来有两个范围(两个 - ),但我觉得我知道它足以在多年前有效地组成它。现在,我在迁移到运行脚本的新 docker 容器环境时尝试记住并诊断这一点。

问题:

有什么值得注意的事情可以解释为什么这会在一种环境中失败而在另一种环境中却不会失败?

是否有可能不是 sed 等的版本,而是我在旧环境中进行的该表达式所需的设置?如果您对此有任何想法,我可以检查和测试。

注意:

我实际上不需要特定的内容来测试它,我可以只运行上面的示例而不使用“file.tsv”或空文件,它会在新环境中产生相同的错误。

linux bash sed unicode expression
1个回答
0
投票
/usr/bin/sed: -e expression #1, char 35: Invalid range end

,因为我脑子里有十六进制。

\x10

这是区域设置处理中的一些奇怪的错误。

© www.soinside.com 2019 - 2024. All rights reserved.