sed и апострофы

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

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

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

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

gsed - это гнутый, очевидно.

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

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

о, класс!! sed --posix работает!!)) огромное спасибо! теперь знаю, куда курить)

p.s. а gsed у меня нет :( , у меня debian

т.е. похоже, что тут sed и есть gsed

$ 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

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

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

grep -w 'second line' test.txt | cut -d" " -f2 | sed 's/\'//g'

тогда уж в начало поставь cat test.txt |

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

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

worksforme:

работать будет, но учти, что BASH раскроет кучу символов внутри двойных кавычек.

Вот это говно.

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

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

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

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

т.е. похоже, что тут sed и есть gsed

именно так.

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

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

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

Одинарная кавычка в шеле не экранируется бекслешем.

Hint:

'"'"'

Нет. 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

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

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

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

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

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

Всё, разобрался!) Просто перестарался с экранированием))

Всем спасибо!)

мультистрочном режиме
sed

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Он над тобой издевался, ты и так там нагородил лес пайпов.

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

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

Он над тобой издевался, ты и так там нагородил лес пайпов.

уйди. Не мешай.

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

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

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

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

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

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

1 unixway

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

это уродство и mustdie way.

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

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

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

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

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

• grep
• pipe

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

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

это уродство и mustdie way.

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

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

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

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

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

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

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

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