Мобильная версияПроблема с выражением sed с использованием диапазона Юникода в новой среде ⇐ Linux
-
Anonymous
Проблема с выражением sed с использованием диапазона Юникода в новой среде
У меня есть следующее выражение замены диапазона sed в чистом сценарии bash, который я написал много лет назад, который работает (или, по крайней мере, никогда не выдавал ошибок) в старой среде, но происходит сбой (с ошибкой) в новой среде, и я не могу определить, почему диапазон между старой и новой средами недействителен.
Целью выражения является удаление нежелательных символов Юникода или управляющих символов из файлов TSV, используемых для импорта данных в нашу базу данных.
Пример выражения в одну строку:
sed -e 's,[\x00\x01-\x08\x0a-\x1f\x7f]\+,,g' file.tsv [*]Старая среда: Ubuntu v16.04, Bash v4.3.46, GNU Sed v4.2.2 [*]Новая среда: Ubuntu v20.04, Bash v5.0.17, GNU Sed v4.7 Ошибка только в новой среде (в старой нет ошибок):
/usr/bin/sed: -e выражение №1, символ 35: неверный конец диапазона Я попробовал запустить выражение на https://www.jdoodle.com/test-bash-shell-script-online и выбрать bash v5.0.011, который использует sed v4.7, и он НЕ выдает ошибку, так что, возможно, это НЕ проблема версии sed или bash.
Я не могу точно вспомнить, как я составил используемый диапазон символов или почему оказалось, что существует два диапазона (два -), но я чувствую, что знал это достаточно, чтобы эффективно составить его много лет назад. Теперь я пытаюсь запомнить и диагностировать это при переходе в новую среду докер-контейнера, в которой выполняется сценарий.
Вопросы:
Примечательно ли что-нибудь, почему это может привести к сбою в одной среде, но не в другой?
Возможно ли, что это выражение требует не версий sed и т. д., а настроек, которые я сделал в старой среде? Если у вас есть идеи по этому поводу, я могу проверить и протестировать.
Примечание. На самом деле для проверки мне не нужен конкретный контент, я могу просто запустить приведенный выше пример без файла file.tsv или пустого файла, и он выдаст ту же ошибку в новая среда.
У меня есть следующее выражение замены диапазона sed в чистом сценарии bash, который я написал много лет назад, который работает (или, по крайней мере, никогда не выдавал ошибок) в старой среде, но происходит сбой (с ошибкой) в новой среде, и я не могу определить, почему диапазон между старой и новой средами недействителен.
Целью выражения является удаление нежелательных символов Юникода или управляющих символов из файлов TSV, используемых для импорта данных в нашу базу данных.
Пример выражения в одну строку:
sed -e 's,[\x00\x01-\x08\x0a-\x1f\x7f]\+,,g' file.tsv [*]Старая среда: Ubuntu v16.04, Bash v4.3.46, GNU Sed v4.2.2 [*]Новая среда: Ubuntu v20.04, Bash v5.0.17, GNU Sed v4.7 Ошибка только в новой среде (в старой нет ошибок):
/usr/bin/sed: -e выражение №1, символ 35: неверный конец диапазона Я попробовал запустить выражение на https://www.jdoodle.com/test-bash-shell-script-online и выбрать bash v5.0.011, который использует sed v4.7, и он НЕ выдает ошибку, так что, возможно, это НЕ проблема версии sed или bash.
Я не могу точно вспомнить, как я составил используемый диапазон символов или почему оказалось, что существует два диапазона (два -), но я чувствую, что знал это достаточно, чтобы эффективно составить его много лет назад. Теперь я пытаюсь запомнить и диагностировать это при переходе в новую среду докер-контейнера, в которой выполняется сценарий.
Вопросы:
Примечательно ли что-нибудь, почему это может привести к сбою в одной среде, но не в другой?
Возможно ли, что это выражение требует не версий sed и т. д., а настроек, которые я сделал в старой среде? Если у вас есть идеи по этому поводу, я могу проверить и протестировать.
Примечание. На самом деле для проверки мне не нужен конкретный контент, я могу просто запустить приведенный выше пример без файла file.tsv или пустого файла, и он выдаст ту же ошибку в новая среда.
