sed и два пробела

символы «\» и n матчатся

см. выше. Мы возвращаемся к тому, что 0x0A — это LF.

https://upload.wikimedia.org/wikipedia/commons/e/e0/ASCII_Code_Chart-Quick_re...

просто выполни echo БЕЗ sed. Можешь выхлоп загнать в hexdump.

упс, перепутал -e с -n :3

Лучше объясни мне это:

~ $ echo -en '$$$$\n'>/tmp/tmp0002.tmp;sed 's/[^$]/Z/g' /tmp/tmp0002.tmp
$$$$                                                                                                                                                                                                               
                                                                                                                                                                                                                   
~ $

~ $ echo -en '$$$$\r\n'>/tmp/tmp0002.tmp;sed 's/[^$]/Z/g' /tmp/tmp0002.tmp                                                                                                                                          
$$$$Z                                                                                                                                                                                                              
                                                                                                                                                                                                                   
~ $ 

см. выше. Мы возвращаемся к тому, что 0x0A — это LF.

какая разница, что такое LF?

может у вас огрызко-проблемы, или шелло-проблемы, мне пофиг, у меня Linux и bash.

\n == EOL == LF == 0x0A

\r == CR == 0xOD

колись, что у тебя.

Лучше объясни мне это

мне отсюда не видно.

~ $ echo -en '$$$$\r\n'|hexdump
0000000 2424 2424 0a0d                         
0000006
~ $ echo -en '$$$$\n'|hexdump
0000000 2424 2424 000a                         
0000005
~ $ 

0x0d матчится sed'ом как EOL, а 0x0a — нет? Какие-то шеллопроблемы. Припоминаю читал книжку, там написание шелла как раз рассматривалось, в том числе обработка спецсимволов и escape-последовательностей.

0x0d матчится sed'ом как EOL, а 0x0a — нет?

в Linux строчки принято заканчивать 0x0a (\n), а 0x0d (\r) — просто символ, невидимый, и на моём терминале работает как CR

$ echo -e 'ABCDEF\rXYZ'
XYZDEF

на моём терминале

это и есть CR. Покажи echo -en '$$$$\r'>/tmp/tmp0002.tmp;sed 's/[^$]/Z/g' /tmp/tmp0002.tmp

$ echo -en '$$$$\r'>/tmp/tmp0002.tmp;sed 's/[^$]/Z/g' /tmp/tmp0002.tmp
$$$$Z

всё верно: \r это не доллар, и он матчится. И тут нет CR в выводе. На входе его тоже нет.

$ echo -e '$$$$\r'|sed 's/[^$]/Z/g'
$$$$Z

$ echo -e '$$$$\r\n\r'|sed 's/[^$]/Z/g'
$$$$Z
Z

как видишь, LF тут вообще в обработке не участвует, а напрямую едет на вывод.

$ echo -e '\n\n\r\n'|sed 's/[^$]/Z/g'


Z

Твоя правда, наверное. Я под веществами. И эмм, мне было скучно, извини. :>

Так что, с \r это мои глюки, но \n sed всё же воспринимает как конец строки:

~ $  echo -en '$$$$\n\n\r\r11\n'|sed 's/$/Z/g'
$$$$Z
Z
11Z
~ $ 

Теперь можно обсудить то, что я сказал изначально, а именно \n преобразуется во вполне определённые байты, т.е. является спецсимволом (пусть и невидимым, но он там есть) LF, который нужно учитывать при разборе строк.

Я под веществами.

\n sed всё же воспринимает как конец строки

как ещё оно может воспринимать конец строки?

\n преобразуется во вполне определённые байты, т.е. является спецсимволом (пусть и невидимым, но он там есть) LF, который нужно учитывать при разборе строк.

в sed скрипте нельзя. Нет там такого символа. Я его юзаю как раз тогда, когда мне нужен какой-то маркёр, которого ТОЧНО не будет.

например:

$ echo "ABCDEFGH"|\
sed -r 's/^/\n/;s/$/\n/;bl;:l;s/(.*)(\n.)(.*)(.\n)(.*)/\1\4\3\2\5/;tl;s/\n//g'
HGFEDCBA

Ну вот это мне и хотелось выяснить, мог бы сразу так и сказать.

ну теперь изучай мой скрипт. Как изучишь — приходи ☺

удалите долбайобау