История изменений

Всякое бывает,

Ну логику вставки во внутрь всё же хочется увидеть. Вот «stat» давно напрашивался, ибо в «[]» он наполовину всегда был, и это раздражало. Типа проверка на пустой файл есть, и вообще пол алфавита ключей [ -* FILE ], а проверить, что ровно 1 байт — уже вызывай внешний stat. А почему «rm» теперь такая честь отдана?

надо просто помнить что вызов внешних утилит «дорогая» операция. Я лет 15 назад тут на ЛОРе писал о том как один шелл-скрипт, с 4-5 вложенными циклами и 5-8 вызовами sed/grep/awk во внутреннем цикле, работал около часа, а один в один переписанный алгоритм на перле (т.е. без fork-exec) стал отрабатывать за 1-2 сек на той ве машине.

Это на самом деле весьма сложный вопрос, который меняется со временем. 35 лет назад fork+exec был чудовищно медленными сисколами сами по себе. Потом это стало медленным по причине, что у вас вот вся память сожрана на текущие процессы и кеш диска. А теперь оно скорее тормозит из-за жирноты самих sed/grep/awk, которые пока запустятся, пока распарсят зачастую один и тот же регекс/скрипт в циклах со всё возрастаемыми фичами и только потом станут исполнять свой внутренний jit.

Всякое бывает,

Ну логику вставки во внутрь всё же хочется увидеть. Вот «stat» давно напрашивался, ибо в «[]» он наполовину всегда был, и это раздражало. Типа проверка на пустой файл есть, и вообще пол алфавита ключей [ -* FILE ], а проверить, что ровно 1 байт — уже вызывай внешний stat. А почему «rm» теперь такая честь отдана?

надо просто помнить что вызов внешних утилит «дорогая» операция. Я лет 15 назад тут на ЛОРе писал о том как один шелл-скрипт, с 4-5 вложенными циклами и 5-8 вызовами sed/grep/awk во внутреннем цикле, работал около часа, а один в один переписанный алгоритм на перле (т.е. без fork-exec) стал отрабатывать за 1-2 сек на той ве машине.

Это на самом деле весьма сложный вопрос, который меняется со временем. 35 лет назад fork+exec был чудовищно медленными сисколами сами по себе. Потом это стало медленным по причине, что у вас вот вся память сожрана на текущие процессы и кеш диска. А теперь оно скорее тормозит из-за жирноты самих sed/grep/awk, которые пока запустятся, пока распарсят зачастую один и тот же скрипт в циклах со всё возрастаемыми фичами и только потом станут исполнять свой внутренний jit.

Всякое бывает,

Ну логику вставки во внутрь всё же хочется увидеть. Вот «stat» давно напрашивался, ибо в «[]» он наполовину всегда был, и это раздражало. Типа проверка на пустой файл есть, и вообще пол алфавита ключей [ -* FILE ], а проверить, что ровно 1 байт — уже вызывай внешний stat. А почему «rm» теперь такая честь отдана?

надо просто помнить что вызов внешних утилит «дорогая» операция. Я лет 15 назад тут на ЛОРе писал о том как один шелл-скрипт, с 4-5 вложенными циклами и 5-8 вызовами sed/grep/awk во внутреннем цикле, работал около часа, а один в один переписанный алгоритм на перле (т.е. без fork-exec) стал отрабатывать за 1-2 сек на той ве машине.

Это на самом деле весьма сложный вопрос, который меняется со временем. 35 лет назад fork+exec был чудовищно медленными сисколами самим по себе. Потом это стало медленным по причине, что у вас вот вся память сожрана на текущие процессы и кеш диска. А теперь оно скорее тормозит из-за жирноты самих sed/grep/awk, которые пока запустятся, пока распарсят зачастую один и тот же скрипт в циклах со всё возрастаемыми фичами и только потом станут исполнять свой внутренний jit.

Всякое бывает,

Ну логику вставки во внутрь всё же хочется увидеть. Вот «stat» давно напрашивался, ибо в «[]» он наполовину всегда был, и это раздражало. Типа проверка на пустой файл есть, и вообще пол алфавита ключей [ -* FILE ], а проверить, что ровно 1 байт — уже вызывай внешний stat. А почему «rm» теперь такая честь отдана?

надо просто помнить что вызов внешних утилит «дорогая» операция. Я лет 15 назад тут на ЛОРе писал о том как один шелл-скрипт, с 4-5 вложенными циклами и 5-8 вызовами sed/grep/awk во внутреннем цикле, работал около часа, а один в один переписанный алгоритм на перле (т.е. без fork-exec) стал отрабатывать за 1-2 сек на той ве машине.

Это на самом деле весьма сложный вопрос, который меняется со временем. 35 лет назад fork+exec был чудовищно медленным сисколом самим по себе. Потом это стало медленным по причине, что у вас вот вся память сожрана на текущие процессы и кеш диска. А теперь оно скорее тормозит из-за жирноты самих sed/grep/awk, которые пока запустятся, пока распарсят зачастую один и тот же скрипт в циклах со всё возврастаемыми фичами и только потом станут исполнять свой внутренний jit.