Получить часть строки до последнего : (или удалить последний символ в строке) (не используя sed, awk и переменных)

[/dev/random]

бот Nazyvaemykh — на чём-то эукариотическом…

А таких я и словей-то не знаю (ispell, кстати, тоже не знает).

википедия://Эукариоты

[t.t]

"с ним" проще и короче если использовать сторонние утилиты, что противоречит условию.

С чего вдруг? Я не писал, что решение должно быть на чистом bash.

тут дело не в выходе из пайпа, а в группировке операций:
echo "x:y:z" | read a; echo ${a##*:}
вначале выполняется выделенная часть, а уж потом выполняется echo. При этом, a является локальной переменной.
нам это не нужно, потому и приходится использовать subshell

Вы называете (раз)группировкой операций то же самое, что /dev/random назвал выходом из пайпа.

Код: Выделить всё

$ echo "x:y:z" | ( read a; echo ${a##*:} ) | cat
z

Вы пишете, что здесь выход из пайпа есть, хотя его по-прежнему нет.

почему "нет"? subshell в данном случае работает как фильтр, вроде sed/awk. Он получает данные из входного потока, обрабатывает их, и отдаёт в выходной.

Вы задали вопрос и сразу же ответили на него.

Как вы и заказывали:
1. внутри конвейера
2. на bash, без использования сторонних утилит.
Не понимаю, чем вас не устраивает этот вариант?

Ещё раз: я не заказывал "без сторонних утилит"; но я ещё и заказывал "без переменных". Вариант с переменными не устраивает меня тем, что для него нужен цикл, который излишне усложняет конструкцию.

я не нашёл решения от sash-kan в этой теме.

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

Я показал выше, что при почти четырёх тысячах символов в строке разница по времени пренебрежимо мала. А это явно избыточно: в моей задаче и пятисот символов быть не может.

У меня всё чаще возникает впечатление, что я с ботом разговариваю. В частности, очевидные вещи приходится по четыре раза проговаривать.

очевидно, что Ваши ограничения и условия надуманы, и я уже в какой раз возвращаюсь к своему первоначальному тезису - вы сами неоправданно сузили область решений - задача тривиально решается той-же sed (о чём вы писали ещё в первом посте), или без конвейера. Напоминает разложение в ряд функции y=1/x в начальной школе - дескать дети ещё не проходили деление, и разложение в бесконечный ряд с предельным переходом, или аппроксимация многочленом функции 1/x для них будет проще, ведь там нет деления - только сложение/вычитание/умножение...

С чего это вдруг неоправданно? Последний раз по пунктам:
1. решение без конвейера меня не устраивает поскольку обработать нужно было наперёд неизвестное количество строк;
2. решения с sed и с grep -o я готов был рассмотреть, но вариант с rev я считаю более простым для человека, незнакомого с регэкспами;
3. начинать знакомство с регэкспами с такого достаточно узкого примера на мой взгляд нецелесообразно -- гораздо лучше будет в следующей статье разобрать более серьёзный пример, чтобы сразу хоть немного показать их гибкость.
Я понимаю, что последние два пункта -- вопрос личного мнения, и Вы можете по ним со мной не согласиться. Но и я как автор статей могу руководствоваться при их написании своим личным мнением, а не Вашим.

[drBatty]

Вы называете (раз)группировкой операций то же самое, что /dev/random назвал выходом из пайпа.

да, но в примере с (subshell) происходит именно нужная группировка операций. или нужный нам "выход из пайпа", называйте как хотите (:

почему "нет"? subshell в данном случае работает как фильтр, вроде sed/awk. Он получает данные из входного потока, обрабатывает их, и отдаёт в выходной.

Вы задали вопрос и сразу же ответили на него.

как я понял, sed/awk "пугают" вас сложностью RE. здесь никаких RE нет, мы имеем дело с чистым bash'ем.

Вариант с переменными не устраивает меня тем, что для него нужен цикл, который излишне усложняет конструкцию.

это я понял. действительно, цикл в одностроке выглядит жутко. Но ведь есть решение и без цикла.

Код: Выделить всё

( read a; echo ${a##*:} )

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

с фигурными что-то не работает. значит - не решение. А вот с круглыми - работает.
и уже вторую страницу не могу понять, что вам тут не нравится?

1. решение без конвейера меня не устраивает поскольку обработать нужно было наперёд неизвестное количество строк;

не вижу связи. цикл while read a; do echo a >output; done <input разве обрабатывает фиксированное число строк?

2. решения с sed и с grep -o я готов был рассмотреть, но вариант с rev я считаю более простым для человека, незнакомого с регэкспами;

ладно. с этим я согласен. проще. вот только я-бы примечание ввёл: типа "мы пока не умеем делать по человечески, потому нам приходится разворачивать строки задом вперёд, искать разделитель, а потом разворачивать обратно, чтоб зад стал задом. это требует времени, и может привести к проблемам"

3. начинать знакомство с регэкспами с такого достаточно узкого примера на мой взгляд нецелесообразно -- гораздо лучше будет в следующей статье разобрать более серьёзный пример, чтобы сразу хоть немного показать их гибкость.

угу. с этим-то я согласен. за одно, можно рассмотреть, как решить эту проблему без лишних телодвижений - ведь с помощью RE можно искать последний разделитель за один проход, с начала и до конца, и без всяких смен порядка символов.

Я понимаю, что последние два пункта -- вопрос личного мнения, и Вы можете по ним со мной не согласиться. Но и я как автор статей могу руководствоваться при их написании своим личным мнением, а не Вашим.

А я Вам уже четвёртую страницу пытаюсь объяснить, что проблема таки не в решении, проблема как раз в подходе к решению.

[t.t]

Вы называете (раз)группировкой операций то же самое, что /dev/random назвал выходом из пайпа.

да, но в примере с (subshell) происходит именно нужная группировка операций. или нужный нам "выход из пайпа", называйте как хотите (:
[...]
как я понял, sed/awk "пугают" вас сложностью RE. здесь никаких RE нет, мы имеем дело с чистым bash'ем.

Здесь речь была вообще не об RE, а о разрыве канала. С subshell, как и с фигурными скобками, разрыва канала (или выхода из пайпа, как говорил /dev/random) не происходит. Хватит опровергать очевидные вещи.

это я понял. действительно, цикл в одностроке выглядит жутко. Но ведь есть решение и без цикла.

Код: Выделить всё

( read a; echo ${a##*:} )

И зачем оно мне без цикла на многострочном-то вводе?

Код: Выделить всё

$ echo -e '1:2:3\n4:5:6\n7:8:9' | ( read a; echo ${a##*:} )
3

с фигурными что-то не работает. значит - не решение. А вот с круглыми - работает.
и уже вторую страницу не могу понять, что вам тут не нравится?

Это Ваши фантазии. Всё работает:

Код: Выделить всё

t $ echo -e '1:2:3' | { read a; echo ${a##*:}; }
3

1. решение без конвейера меня не устраивает поскольку обработать нужно было наперёд неизвестное количество строк;

не вижу связи. цикл while read a; do echo a >output; done <input разве обрабатывает фиксированное число строк?

Хорошо, добавляю пункт номер ноль (о котором тоже уже не раз здесь писал):
0. циклы применять не хочется, т.к. они слишком громоздки для этой задачи.
Теперь связь видна?

2. решения с sed и с grep -o я готов был рассмотреть, но вариант с rev я считаю более простым для человека, незнакомого с регэкспами;

ладно. с этим я согласен. проще. вот только я-бы примечание ввёл: типа "мы пока не умеем делать по человечески, потому нам приходится разворачивать строки задом вперёд, искать разделитель, а потом разворачивать обратно, чтоб зад стал задом. это требует времени, и может привести к проблемам"

Снова передёргиваете. На строках, вдесятеро превышающих по длине максимально возможные в этой задаче потери по скорости пренебрежимо малы. А возможная проблема совершенно искусственна: от рута скрипт выполняться не должен, а работать в локали C под обычным пользователем здравомыслящему человеку и в голову не придёт.

А я Вам уже четвёртую страницу пытаюсь объяснить, что проблема таки не в решении, проблема как раз в подходе к решению.

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

[drBatty]

Здесь речь была вообще не об RE, а о разрыве канала. С subshell, как и с фигурными скобками, разрыва канала (или выхода из пайпа, как говорил /dev/random) не происходит. Хватит опровергать очевидные вещи.

ок. НЕ происходит. Значит решение подходит под условие задачи?

Снова передёргиваете. На строках, вдесятеро превышающих по длине максимально возможные в этой задаче потери по скорости пренебрежимо малы. А возможная проблема совершенно искусственна: от рута скрипт выполняться не должен, а работать в локали C под обычным пользователем здравомыслящему человеку и в голову не придёт.

ок, ок.
хорошо.
я согласен.

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

устал чё-то я спорить.


ИЧСХ sed работает вдвое быстрее rev|cut|rev, что неудивительно...

[t.t]

устал чё-то я спорить.

ИЧСХ sed работает вдвое быстрее rev|cut|rev, что неудивительно...

Если устали, зачем тогда снова провокационные заявления делать? Выше уже было продемонстрировано, что sed быстрее только на непомерно длинных строках (кроме дампов мускула я и примеров-то таких не придумаю). Вот Вам последний аргумент -- тест на строке в миллион символов:

Код: Выделить всё

t $ time for c in $(seq 500000); do echo -n :1; done | rev | cut -d : -f 2- | rev >/dev/null

real    0m45.478s
user    0m38.518s
sys     0m9.353s
t $ time for c in $(seq 500000); do echo -n :1; done | sed 's/:[^:]*$//' >/dev/null

real    0m43.509s
user    0m37.710s
sys     0m9.965s
t $ time for c in $(seq 500000); do echo -n :1; done | LC_ALL=C sed 's/:[^:]*$//' >/dev/null

real    0m42.255s
user    0m37.190s
sys     0m9.185s

Даже здесь разница меньше восьми процентов, а никак не "вдвое".

[Nazyvaemykh]

t.t
вы измеряете время работы echo, а не sed и т.п.
переставьте time в другое место, результат будет другим.

[/dev/random]

t.t
вы измеряете время работы echo, а не sed и т.п.
переставьте time в другое место, результат будет другим.

В bash time - ключевое слово, распространяющееся на всю команду, со всеми пайпами.

[Nazyvaemykh]

Меня было смутило большое время работы, думал, что значительную его часть составляет работа echo. Ошибся.

[drBatty]

Вот Вам последний аргумент -- тест на строке в миллион символов:

Даже здесь разница меньше восьми процентов, а никак не "вдвое".

повторяю: так не честно. давайте уж напишите cut для utf8, или sed включите для latin1.

вы измеряете время работы echo, а не sed и т.п.

это тоже.

Меня было смутило большое время работы, думал, что значительную его часть составляет работа echo. Ошибся.

вопрос - сколько-же занимает тут sed или rev|cut|rev?
судя по всему - seq занимает больше, потому и разницы нет.

В bash time - ключевое слово, распространяющееся на всю команду, со всеми пайпами.

Код: Выделить всё

time команда X; sleep 1h

Код: Выделить всё

time команда Y; sleep 1h

обе команды займут 1 час времени. И что?

[Nazyvaemykh]

drBatty, я проверил, и seq, и echo занимают копейки.

[drBatty]

я проверил, и seq, и echo занимают копейки.

ок. дык что там занимает время? cut или rev?

[/dev/random]

В bash time - ключевое слово, распространяющееся на всю команду, со всеми пайпами.

Код: Выделить всё

time команда X; sleep 1h

Код: Выделить всё

time команда Y; sleep 1h

обе команды займут 1 час времени. И что?

На точку с запятой не распространяется. Только "|".

Pipelines
A pipeline is a sequence of one or more commands separated by one of the control operators | or |&. The format for a pipeline is:

[time [-p]] [ ! ] command [ [|⎪|&] command2 ... ]

The standard output of command is connected via a pipe to the standard input of command2. This connection is performed before any redirec‐
tions specified by the command (see REDIRECTION below). If |& is used, the standard error of command is connected to command2's standard
input through the pipe; it is shorthand for 2>&1 |. This implicit redirection of the standard error is performed after any redirections
specified by the command.

The return status of a pipeline is the exit status of the last command, unless the pipefail option is enabled. If pipefail is enabled, the
pipeline's return status is the value of the last (rightmost) command to exit with a non-zero status, or zero if all commands exit success‐
fully. If the reserved word ! precedes a pipeline, the exit status of that pipeline is the logical negation of the exit status as
described above. The shell waits for all commands in the pipeline to terminate before returning a value.

If the time reserved word precedes a pipeline, the elapsed as well as user and system time consumed by its execution are reported when the
pipeline terminates. The -p option changes the output format to that specified by POSIX. The TIMEFORMAT variable may be set to a format
string that specifies how the timing information should be displayed; see the description of TIMEFORMAT under Shell Variables below.

Each command in a pipeline is executed as a separate process (i.e., in a subshell).

[drBatty]

На точку с запятой не распространяется. Только "|".

не суть.

[t.t]

повторяю: так не честно. давайте уж напишите cut для utf8, или sed включите для latin1.

Я для sed локаль C включил, как видите выше. Время обработки поменялось не радикально; я бы даже сказал, незаметно.

[drBatty]

Я для sed локаль C включил, как видите выше. Время обработки поменялось не радикально; я бы даже сказал, незаметно.

потому-что ваша команда тратит основное время на генерацию информации, а не на её обработку. Если мы сделаем так:

Код: Выделить всё

$ time for c in $(seq 500000); do echo -n :1; done >z.txt

real    0m12.530s
user    0m9.636s
sys    0m2.131s

А потом так:

Код: Выделить всё

$ time rev z.txt| cut -d : -f 2- | rev >/dev/null

real    0m0.187s
user    0m0.109s
sys    0m0.032s

$ time sed 's/:[^:]*$//' z.txt >/dev/null

real    0m0.283s
user    0m0.262s
sys    0m0.011s

$ time LC_ALL=C sed 's/:[^:]*$//' z.txt >/dev/null

real    0m0.094s
user    0m0.070s
sys    0m0.010s

то увидим совсем иные результаты.

ЗЫЖ файл получился размером в 977К, для чистоты эксперимента брался НЕ первый замер, а второй и т.д., к тому времени файл уже был полностью в памяти, в дисковом кеше. Если это не так, то ко времени обработки добавится ещё и время чтения с HDD (которое может составлять сотни миллисекунд).

[ZyX]

У zsh есть такая интересная переменная: REPORTTIME. С ней можно посмотреть, что занимает какое время:

/tmp/zsh - 1 (Created by format.vim)

(zyx:/tmp) % REPORTTIME=0 [EOF - dtach terminating]c<=5000000 ; c++)); do echo -n :1; done | rev | cut -d : -f 2- | rev >/dev/null for ((c=1 ; c<=5000000 ; c++)) do; echo -n :1; done 12,86s user 8,00s system 98% cpu 21,126 total rev 8,85s user 0,51s system 43% cpu 21,417 total cut -d : -f 2- 0,20s user 0,01s system 0% cpu 21,416 total rev > /dev/null 0,32s user 0,01s system 1% cpu 21,625 total (zyx:/tmp) % for ((c=1 ; c<=5000000 ; c++)); do echo -n :1; done | sed 's/:[^:]*$//' >/dev/null for ((c=1 ; c<=5000000 ; c++)) do; echo -n :1; done 12,69s user 7,92s system 98% cpu 20,908 total sed 's/:[^:]*$//' > /dev/null 10,29s user 0,35s system 47% cpu 22,562 total (zyx:/tmp) % for ((c=1 ; c<=5000000 ; c++)); do echo -n :1; done | LC_ALL=C sed 's/:[^:]*$//' >/dev/null for ((c=1 ; c<=5000000 ; c++)) do; echo -n :1; done 12,54s user 7,73s system 98% cpu 20,543 total LC_ALL=C sed 's/:[^:]*$//' > /dev/null 8,69s user 1,41s system 47% cpu 21,075 total (zyx:/tmp) % for ((c=1 ; c<=5000000 ; c++)); do echo -n :1; done | perl -p -i -e 's/:[^:]*$//' >/dev/null for ((c=1 ; c<=5000000 ; c++)) do; echo -n :1; done 13,00s user 9,16s system 99% cpu 22,369 total perl -p -i -e 's/:[^:]*$//' > /dev/null 11,63s user 0,67s system 52% cpu 23,352 total (zyx:/tmp) % for ((c=1 ; c<=5000000 ; c++)); do echo -n :1; done | gawk -F: 'BEGIN{OFS=":"};{NF=NF-1;print}' >/dev/null for ((c=1 ; c<=5000000 ; c++)) do; echo -n :1; done 11,84s user 3,13s system 99% cpu 15,056 total gawk -F: 'BEGIN{OFS=":"};{NF=NF-1;print}' > /dev/null 15,53s user 0,68s system 98% cpu 16,400 total (zyx:/tmp) % for ((c=1 ; c<=5000000 ; c++)); do echo -n :1; done | LC_ALL=C gawk -F: 'BEGIN{OFS=":"};{NF=NF-1;print}' >/dev/null for ((c=1 ; c<=5000000 ; c++)) do; echo -n :1; done 11,66s user 3,07s system 99% cpu 14,785 total LC_ALL=C gawk -F: 'BEGIN{OFS=":"};{NF=NF-1;print}' > /dev/null 15,02s user 0,73s system 98% cpu 15,945 total (zyx:/tmp) % for ((c=1 ; c<=5000000 ; c++)); do echo -n :1; done | LC_ALL=C python -c $'import sys\nfor line in sys.stdin:\n sys.stdout.write(line[:line.rfind(":")])' >/dev/null for ((c=1 ; c<=5000000 ; c++)) do; echo -n :1; done 12,90s user 7,81s system 99% cpu 20,909 total LC_ALL=C python -c > /dev/null 7,25s user 0,91s system 38% cpu 20,932 total (zyx:/tmp) % for ((c=1 ; c<=5000000 ; c++)); do echo -n :1; done | { read -r VAR ; echo ${VAR%:*} } >/dev/null

К сожалению, в последнем случае zsh упала, поэтому можно увидеть [EOF - dtach terminating].

[ZyX]

Всё это в таблице:

Код:

user system cpu total rev|cut|rev 8,85 0,51 43 21,417 0,20 0,01 0 21,416 0,32 0,01 1 21,625 sed 10,29 0,35 47 22,562 C sed 8,69 1,41 47 21,075 perl 11,63 0,67 52 23,352 gawk 15,53 0,68 98 16,400 C gawk 15,02 0,73 98 15,945 python2 6,77 1,28 39 20,470 C python2 7,25 0,91 38 20,932 python3 13,11 1,98 92 16,288

[t.t]

потому-что ваша команда тратит основное время на генерацию информации, а не на её обработку.

Насчёт генерации согласен. Но у меня на ста строках цифры совсем другие получаются:

Код: Выделить всё

t $ for s in $(seq 100); do for c in $(seq 500000); do echo -n :1; done; echo; done >tmp/txt
t $ time rev tmp/txt | cut -d : -f 2- | rev >/dev/null

real    0m35.011s
user    0m47.427s
sys     0m1.804s
t $ time LC_ALL=C sed 's/:[^:]*$//' tmp/txt >/dev/null

real    0m40.080s
user    0m39.834s
sys     0m0.228s

[drBatty]

Насчёт генерации согласен. Но у меня на ста строках цифры совсем другие получаются

этому есть простое объяснение: файл у меня получился ~1Мб, и потому гарантированно влез в кеш. У вас в ~100Мб, и видимо влез в кеш не полностью. Частично или полностью он читался с HDD, а как все мы знаем, чтение с HDD _на несколько порядков дольше_ чтения из RAM. Обработка тут очень простая, и сопоставима по времени с чтением из RAM, вот потому-то у вас и получился такой результат - это цена доступа к HDD.

[/dev/random]

этому есть простое объяснение: файл у меня получился ~1Мб, и потому гарантированно влез в кеш. У вас в ~100Мб, и видимо влез в кеш не полностью. Частично или полностью он читался с HDD, а как все мы знаем, чтение с HDD _на несколько порядков дольше_ чтения из RAM. Обработка тут очень простая, и сопоставима по времени с чтением из RAM, вот потому-то у вас и получился такой результат - это цена доступа к HDD.

Время доступа к HDD команда time включает только в поле real.

Shell

$ time dd if=~/Video/(имя файла вырезано) of=/dev/null bs=10M 223+1 записей считано 223+1 записей написано скопировано 2343739392 байта (2,3 GB), 427,031 c, 5,5 MB/c real 7m7.168s user 0m0.001s sys 0m6.602s

[drBatty]

Время доступа к HDD команда time включает только в поле real.

ну конечно результата исполнения МОИХ команд я не увижу, только ваши. Да?
Что там куда включается - далеко не факт, данные поступают в поток не напрямую, а через дисковый кеш. Как именно всё это считается командой time - нам неизвестно. В любом случае, мои результаты качественно отличаются от Ваших. Вы полагаете я свои результаты подделал? У вас получается иначе? И как-же? А если не подделал, и у Вас такие-же результаты, то как Вы объясните это расхождение? Попробуйте другой вариант - вместо одного файла в 100 строк, попробуйте выполнить 100 раз одну команду над файлом в одну строку. В данном случае всё будет гарантированно браться из RAM, и никаких погрешностей от работы HDD принципиально не будет. Кстати, время позиционирования и время выхода из ждущего режимам HDD команда time куда относит? Пруф или небыло? ;)

[/dev/random]

ну конечно результата исполнения МОИХ команд я не увижу, только ваши. Да?
Что там куда включается - далеко не факт, данные поступают в поток не напрямую, а через дисковый кеш. Как именно всё это считается командой time - нам неизвестно. В любом случае, мои результаты качественно отличаются от Ваших. Вы полагаете я свои результаты подделал? У вас получается иначе? И как-же? А если не подделал, и у Вас такие-же результаты, то как Вы объясните это расхождение? Попробуйте другой вариант - вместо одного файла в 100 строк, попробуйте выполнить 100 раз одну команду над файлом в одну строку. В данном случае всё будет гарантированно браться из RAM, и никаких погрешностей от работы HDD принципиально не будет. Кстати, время позиционирования и время выхода из ждущего режимам HDD команда time куда относит? Пруф или небыло?

o_O Что это было?

ну конечно результата исполнения МОИХ команд я не увижу, только ваши. Да?

Я не вижу, чтобы вы здесь привели ВАШИ команды, тестирующие то, как time учитывает время ожидания IO.

В любом случае, мои результаты качественно отличаются от Ваших.

Я не вижу, чтобы я приводил здесь какие-либо результаты, которые можно было бы сравнивать с вашими.

Вы полагаете я свои результаты подделал?

Я не вижу, чтобы я что-то говорил о ваших _результатах_. Только о выводах.

...

Ну и так далее. Что-то у меня ощущение, что вы вообще не на мой пост отвечали.

[t.t]

Насчёт генерации согласен. Но у меня на ста строках цифры совсем другие получаются

этому есть простое объяснение: файл у меня получился ~1Мб, и потому гарантированно влез в кеш. У вас в ~100Мб, и видимо влез в кеш не полностью. Частично или полностью он читался с HDD, а как все мы знаем, чтение с HDD _на несколько порядков дольше_ чтения из RAM. Обработка тут очень простая, и сопоставима по времени с чтением из RAM, вот потому-то у вас и получился такой результат - это цена доступа к HDD.

Вы бы хоть прикинули, сколько занимает чтение с диска стомегабайтного файла, прежде чем такие аргументы приводить. Например, согласно википедии, скорость считывания с современных винчестеров колеблется от 44,2 до 111,4 Мб/с (в зависимости от скорости вращения и расстояния от центра блина). Т.е. на весь файл одна-две секунды (грубо). Но разница, связанная с чтением с диска, ограничена размером кеша, т.е. 8 Мб в моём случае. Итого от 0.07 до 0.18 секунды -- это верхний предел. Тестирование подтверждает эти цифры: несколько прогонов этих команд показали разницу между прогонами не более 0.12 секунды по каждой из позиций.

[drBatty]

Вы бы хоть прикинули, сколько занимает чтение с диска стомегабайтного файла, прежде чем такие аргументы приводить. Например, согласно википедии, скорость считывания с современных винчестеров колеблется от 44,2 до 111,4 Мб/с

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

Т.е. на весь файл одна-две секунды (грубо). Но разница, связанная с чтением с диска, ограничена размером кеша, т.е. 8 Мб в моём случае.

а дисковый кеш в оперативной памяти у вас отключён? а у меня - включён.

Тестирование подтверждает эти цифры: несколько прогонов этих команд показали разницу между прогонами не более 0.12 секунды по каждой из позиций.

конечно, предлагаемая мной методика тестирования и полученные мною цифры вами попросту игнорируются... Ну ладно. Что спорить-то?..

[t.t]

конечно, предлагаемая мной методика тестирования и полученные мною цифры вами попросту игнорируются... Ну ладно. Что спорить-то?..

В полученных Вами цифрах общее время по порядку величины равно возможной погрешности измерений; как их можно обсуждать всерьёз? Повторю свой основной аргумент: я провёл измерения по пять раз для каждого из двух вариантов; разброс был пренебрежимо мал. Вы пытаетесь меня убедить, что во всех десяти измерениях влияние дисковых задержек сложилось не в пользу sed? Позвольте этому не поверить.