Старая проблема с галочками и круглыми скобками :запутала
Возможно, это не лучший способ сделать это в sed, но:
$ sed '1{h;d;}; G; s/\(.*\)\n\(.*\)/\2: \1/' file
black: widow
black: card
black: Friday
black: berry
Пояснение:
1{h;d;}для первой строки скопируйте пространство шаблона, чтобы сохранить место, а затем удалитеGдобавить новую строку к содержимому пространства шаблонов, а затем добавить содержимое пространства удержания к содержимому пространства шаблонов. Теперь у нас есть два правильных слова в пространстве шаблонов, но в неправильном порядке и с неправильным разделителем(\nвместо:) .s/\(.*\)\n\(.*\)/\2: \1/'поменять местами части до и после новой строки, заменив новую строку двоеточием и пробелом
Bash FAQ приводит ряд причин, по которым –предпочитают круглые скобки обратным кавычкам, но не существует универсального правила, согласно которому вы никогда не должны использовать обратные кавычки.
Основная причина, по которой я предпочитаю круглые скобки, на мой взгляд, заключается в том, что синтаксический анализ внутри $()согласуется с синтаксическим анализом, выполняемым снаружи, чего нельзя сказать о обратных апострофах. Это означает, что вы можете взять команду оболочки и без особых размышлений обернуть ее "$()"; это неверно, если вместо этого вы используете обратные кавычки. Это каскадно, поэтому обертка команды, которая сама содержит подстановку, легко выполняется с помощью "$()", но не с обратными кавычками.
В конечном счете, я думаю, это вопрос привычки. Если вы решите использовать обратные кавычки для простых случаев и круглые скобки для других, вам придется делать этот выбор каждый раз, когда вы хотите заменить команду. Если вы решите всегда использовать круглые скобки, вам никогда не придется думать об этом снова.
Последнее может объяснить наличие правила «не использовать обратные кавычки» в некоторых руководствах по кодированию :, оно упрощает разработку и устраняет источник ошибок для разработчиков и рецензентов. Это также объясняет, почему использование круглых скобок может быть рекомендовано даже для одного -лайнера :трудно укоренить привычку к написанию сценария -, когда это не применяется повсеместно.
(Что касается манипуляции, то это зависит от раскладки клавиатуры; на моей клавиатуре AZERTY $()не требует никакого сдвига, тогда как обратные кавычки писать довольно больно.)
Лично я всегда использовал бы $(...)просто потому, что он более согласован в крайних случаях вложенных кавычек и расширений, и мне нравится идея, что раскрытия начинаются со знака доллара, а скобки более заметны. чем обратные кавычки, которые в некоторых шрифтах довольно легкие и могут быть перепутаны с одинарными кавычками, такими как , упомянутыми в комментариях . Но помимо первого, речь идет о внешнем виде и эстетике, поэтому ваше мнение может отличаться.
На основании обсуждения в Устарели ли обратные кавычки (, т. е. `cmd `)в оболочках *sh? , не похоже, что поддержка обратных кавычек скоро будет удалена, так что это не повод говорить «никогда».
Однако обратите внимание, что разбор обратных кавычек в некоторых случаях работает странно.Добавление дополнительных обратных кавычек для вложенных расширений довольно просто:
echo `echo \`echo foo\` `
Но это еще не все. Как отмечает Стефан в , ответ на Как использовать специальный символ вместо обычного? , даже вложение двойных кавычек с обратными кавычками между ними не работает в ksh, например (Я воспроизведу это здесь для облегчения доступа):
ksh$ echo "`date +"%F %T"`"
ksh: : cannot execute [Is a directory]
2020-10-01 %T
и вы также должны экранировать внутренние двойные кавычки, хотя это выглядит как , было бы однозначно разобрать даже без них:
ksh$ echo "`date +\"%F %T\"`"
2020-10-01 14:14:27
(Кавычки вокруг подстановки команд уместны из-за подстановки команд, но не с echoздесь.)
Таким образом, хотя это действительно похоже на случай «никогда не говори никогда», и хотя обратные апострофы прекрасно работают в простых случаях, я думаю, что достаточно, чтобы настоятельно рекомендовать просто использовать вместо этого $().:)