LINUX.ORG.RU

sed и апострофы

 


0

1

Всем привет! :) Друзья, у меня есть файл test.txt

first line
second line:    'i need this text'
third line

мне нужно найти строку, содержащую «second line» и взять текст между апострофами.

я пишу:

sed -n 's/second line.*\'\(.*\)\'/\1/p' test.txt
и еще с двойными кавычками:
sed -n "s/second line.*\'\(.*\)\'/\1/p" test.txt

но, то экранирование не работает должным образом, то совпадение не находится.

Подскажите, ЧЯДНТ? Спасибо!

Ответ на: комментарий от Dob

и так та же беда с экранированием \' - после нажатия enter предлагается ввести что-то еще и закрыть кавычку (как я понимаю)

друзья, я бы хотел это сделать только на sed, если это возможно. я просто не понимаю, что не так с этими кавычками?

ancara ()

worksforme:

%sed -n "s/second line.*\'\(.*\)\'/\1/p" < test.txt
i need this text

про версию не скажу. из состава FreeBSD 9.0.

gsed не работает.

%gsed -n "s/second line.*\'\(.*\)\'/\1/p" < test.txt

takino ★★★★★ ()
$ echo "second line: 'i need this text'" | sed -n '/second line/s/.*'"'"'\([^'"'"']*\)'"'"'.*/\1/p'
i need this text

Arch Linux, sed (GNU sed) 4.2.2

anarquista ★★★★★ ()
Последнее исправление: anarquista (всего исправлений: 1)
Ответ на: комментарий от ancara

но я пока хотел бы прокачать хоть базовые навыки sed :)

попробуй \x27, это кавычка и есть. Одиночная.

drBatty ★★ ()
Ответ на: комментарий от ancara

друзья, я бы хотел это сделать только на sed, если это возможно. я просто не понимаю, что не так с этими кавычками?

это с bash не так. В нём внутри 'кавычек' ВСЁ работает как надо, КРОМЕ самоё кавычки. Вот оно и считает \' слешем и концом строки.

drBatty ★★ ()
$ echo "first line
second line:    'i need this text'
third line" |sed -r -n "s/second line.+'(.+)'/\1/p"; sed --version

i need this text

GNU sed version 4.2
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE,
to the extent permitted by law.

GNU sed home page: <http://www.gnu.org/software/sed/>.
General help using GNU software: <http://www.gnu.org/gethelp/>.
E-mail bug reports to: <bug-gnu-utils@gnu.org>.
Be sure to include the word ``sed'' somewhere in the ``Subject:'' field.
anonymous ()
Ответ на: комментарий от takino

И да, что и требовалось доказать:

у тебя наверное gsed работает как gnu sed с ключом -r

-r, --regexp-extended use extended regular expressions in the script.

просто скобки НЕ экранируй, и всё будет ОК. Ещё не нужно экранировать +{} и ещё что-то.

drBatty ★★ ()
Ответ на: комментарий от ancara

gsed - GNU sed
из состава coreutils
У тебя только он и есть.

takino ★★★★★ ()
Ответ на: комментарий от takino

Нет. gsed это gnu sed без лишних опций.

угу. Потому-что слешированая кавычка - это не кавычка, а конец строки в мультистрочном режиме gnu sed - расширения. Вот так работает:

$ sed -n "s/second line.*'\(.*\)'/\1/p" test.txt; sed --version
i need this text
GNU sed версия 4.2.1

Экранировать кавычку НЕ нужно.

drBatty ★★ ()
Ответ на: комментарий от takino

не баш, куда более 'тупой' шелл.

зачем быть умнее всех, и экранировать то, что в экранировании не нуждается? Есть большой риск нарвать на расширение.

drBatty ★★ ()
Ответ на: комментарий от Ip0

Куда как проще и нагляднее:

q="'"
echo -e "first line\nsecond line 'i need this text'\nthird line" | sed -n 's/second line.*'$q'\(.*\)'$q'/\1/p'

i need this text

anonymous ()
Ответ на: комментарий от ancara

Просто перестарался с экранированием

надо отдавать себе отчёт в том, что в шелл и в sed есть экранирование, и оно у каждого своё собственное. Причём в шелле экранирование разное для каждого шелла (в sed тоже, кстати). Потому лучше использовать одиночные кавычки, дабы экранирование шелла не мешало. А саму кавычку вводить как \x27.

drBatty ★★ ()
Ответ на: комментарий от drBatty

И надеяться, что данный sed поймет что от него хотят.

anonymous ()
Ответ на: комментарий от takino

непонимание.

Обычно sed работает с буфером, в котором всего одна строка, и хватает символов ^ и $ для начала и для конца строки/буфера соответственно. Однако, используя N, H и другие команды, можно загрузить в буфер несколько строк. Кроме того имеются модификаторы mM для работы с таким буфером. В этом случае требуется различать начало(конец) строки от начала(конца) буфера. Для этого используются gnu расширения \' и \`

drBatty ★★ ()
Ответ на: комментарий от drBatty

Я и говорю - непонимание, зачем нужно 'мультистрочность' в седе.
сед - по идее, по posix, etc - построковый потоковый редактор, нет?

takino ★★★★★ ()
Ответ на: комментарий от takino

Тут непонимание, зачем в GNU реализуют (в общем-то не нужную, т.к.) функциональность и раздувают утилиты до размера фиг пойми чего.

takino ★★★★★ ()
Ответ на: комментарий от takino

Я и говорю - непонимание, зачем нужно 'мультистрочность' в седе.

потому-что большинство текстов - мультистрочные. Даже тот же HTML. Примеров - несть числа. Даже посты на LOR'е мультистрочные, и по одной строчке их не обработать.

сед - по идее, по posix, etc - построковый потоковый редактор, нет?

нет. Это сначала ТЕКСТОВЫЙ, а уж потом - строчный. Я не виноват, что большинство текстов многострочные, и по строкам их обрабатывать невозможно. Ну а POSIX - это древний стандарт - там написано что обязательно должно быть. В GNU Sed это всё есть, т.ч. не вижу проблемы.

drBatty ★★ ()
Ответ на: комментарий от drBatty

Кстати. N и H - это POSIX sed. А как работать с результатом этих команд, в POSIX подумали? Забыли. Как обычно.

drBatty ★★ ()
Ответ на: комментарий от akk

Нахрена лишний пайп, если программа сама умеет читать из файла?

чтоб был. Какая разница - два лишних пайпа и две лишние команды, или три? Для полноты картины я-бы в конце tail -n1 добавил, а то вдруг там больше одной строки и вдруг нужно одну?

drBatty ★★ ()
Ответ на: комментарий от akk

Нахрена лишний пайп, если программа сама умеет читать из файла?

1 unixway
2 так нагляднее, ваш компактный нечитаемый вариант не пройдёт code review

anonymous ()
Ответ на: комментарий от anonymous

drBatty, ты такой двуличный, просто хочется пнуть ногой :-)

там я серьёзно писал. А здесь прикалываюсь.

drBatty ★★ ()
Ответ на: комментарий от anonymous

Поспорим что grep+cut медленнее одного awk, в данном случае?

ага. А вот awk медленнее одной sed. Хотя так будет только если везде включить(выключить) utf8. А вот в cut, ЕМНИП это невозможно.

Но дело не в скорости, а в целых двух лишних сущностях:

  • grep
  • pipe
drBatty ★★ ()
Ответ на: комментарий от anonymous

Не мешать издеваться над детьми? Не могу гражданская совесть не позволяет.

иначе они не понимают. Проверено.

drBatty ★★ ()
Ответ на: комментарий от anonymous

Ранняя оптимизация — зло! Это же прописная истина.

при чём тут «оптимизация»? лишние сущности не нужны. И не только и не столько потому, что они ещё и тормозят.

как однострочником узнать размеры файлов заданных списком? (комментарий)

если ты не в состоянии сразу оформить свою мысль, не нужно думать, что все настолько неопытные. И что всем нужны твои костыли. И кроме того, кто тебе сказал, что твой путь самый понятный и правильный для всех?

drBatty ★★ ()
Ответ на: комментарий от drBatty

И кроме того, кто тебе сказал, что твой путь самый понятный и правильный для всех?

Но ты то уверен, что только ты глаголишь истину в последней инстанции. ЧСВ притуши — коптит.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.