Почему это правда, что для замены sed на окнах необходимы три обратные слеши
Обращаясь к этому вопросу:
Почему дополнительный \
необходимо в cmd.exe
работать с sed
(MinGW msys-1.0), когда \
не специальный символ в соответствии с cmd /?
(см. последний абзац или здесь)?
Следующие специальные символы требуют кавычек: & < > [ ] { } ^ =;! +, ` ~ [пробел]
Первая обратная косая черта ускользает от второй, лишая его особого значения. Два оставшихся обратных слеша даны sed
который избегает третьего с помощью второго, так что в конце остается одна дословная обратная косая черта, что соответствует моему поиску и замене. Но все же я не удовлетворен этим объяснением, потому что:
cmd не выполняет токенизацию, поэтому первый шаг экранирования не имеет смысла... отсюда, \
имеет только особое значение при предшествующем "
... так каково реальное объяснение?
на Bash в Linux:
echo 'sample\input' | sed 's/\\/----/'
sample----input
на cmd.exe
в windows xp sp3 (нет '
необходимо):
echo sample\input | sed "s/\\/----/"
sed: -e expression #1, char 9: unterminated 's' command
// for some reason sed received only one backslash which causes him trouble ?
echo sample\input | sed "s/\\\/----/"
sample----input
1 ответ
Сед делает это, он использует регулярные выражения в разделе "найти". он использует BRE или ERE или PCRE в зависимости от переключателя. Обратная косая черта является особой в регулярном выражении.
добавленной
Я не использовал вашу версию использования одинарных кавычек, потому что это не имеет смысла для меня в cmd.exe! cmd.exe использует двойные кавычки, если вообще.
И это прекрасно работает.
протестировано с помощью gnuwin32 sed, запущенного из cmd.exe, как и должно быть.
C:\>echo sample\input | sed "s/\\/----/"
sample----input
C:\>sed --v
GNU sed version 4.2.1
Copyright (C) 2009 Free Software Foundation, Inc.
Если бы я тестировал sed cygwin, я бы запустил его из окна cygwin, поскольку именно там должны запускаться программы cygwin. И тогда я бы использовал одинарные кавычки. В этом смысле msys похож на cygwin.
ОБНОВИТЬ
Вы можете запустить cygwin's sed из cmd или из cygwin. Они ведут себя по-разному, потому что они разные версии GNU, но я не вижу проблем, связанных с оболочкой, из cmd против запущенного из cygwin (кроме простого пункта об одинарных кавычках для cygwin, потому что, например, bash, и двойных кавычек для cmd).
И Cygwin's - намного более поздняя версия sed. Sed Gnuwin32, как и многие другие элементы gnuwin32, включая gnuwin32 grep, устарела на несколько лет. и, например, более поздние greps могут исправить ошибки в более ранних greps. Sed 2009, который использует gnuwin32, или менее современная версия, которую использует gnuwin32, может быть в порядке, но может быть лучше использовать последнюю версию, которую будет использовать cygwin.
Интересно, что seds ведут себя по-разному в отношении обратной косой черты. Я вижу, как заставить это работать в более позднем sed, который использует cygwin.
C:\blah>echo a\bc | c:\cygwin\bin\sed "s/\\/_/"
/usr/bin/sed: -e expression #1, char 6: unterminated `s' command
C:\blah>echo a\bc | c:\cygwin\bin\sed "s/\\\/_/"
a_bc
C:\blah>echo a\bc | "c:\Program Files (x86)\GnuWin32\bin\sed" "s/\\/_/"
a_bc
Более ранний sed (sed для gnuwin32), позволяет "s/\/_/" не выходить за косую черту. Таким образом, обратная косая черта избегает обратной косой черты, чтобы создать буквальную обратную косую черту. И слеш после двух обратных слешей остается в порядке. И это работает в этом.
Обратите внимание, что Cygwin's sed в cmd работает нормально. А так как это более поздняя версия, она предпочтительнее, чем sed gnuwin32.
Более поздний sed (cygwin's sed) не допускает "s/\/_/", потому что / экранирует косую черту. Инстинкт (и правильный инстинкт) будет пытаться добавить еще одну обратную косую черту и посмотреть, что произойдет. И это работает. Не уверен, что механика, но я думаю, что единственный слэш в более позднем седе \\\
,
C:\blah>echo \ | c:\cygwin\bin\sed "s/\\\/d/"
d