Оболочка Linux управляет для фильтрации текстового файла с методической точностью длина
Если я буду использовать уникальный сценарий, то все домены получат доступ к нему одновременно, сервер будет работать медленнее по сравнению с ситуацией где каждый домен, названный его собственным сценарием?
Я думаю, что это наоборот. Это не должно быть медленнее. Вопрос, "будет выполнение совместно использованного, делают его быстрее"? Относительно той точки - теоретически, да. Но практическое различие может быть неразличимым.
Точка - если существует один сценарий только для всех пользователей (идея общих библиотек), не только легче поддержать, как указано ранее здесь, но и встроенные механизмы кэширования должны быть более эффективными (по крайней мере, от моего понимания предмета). Один файл для чтения, простой способ кэшироваться в памяти. Несколько идентичных файлов (не sym-/hardlinked, другой inodes) - это более проблематично. Или я недооцениваю поддержку Linux здесь? Исправьте меня, если бы я неправ - мое знание внутренностей не настолько глубоко, но я думаю, что это привело бы к независимому политику, ищет/буферизует.
Другая точка - использование кэшей кода операции. Я не уверен в том, как это смотрит в различных реализациях, но в большинстве случаев использующий несколько идентичных сценариев привел бы к ненужным записям кэша. Однако существует одна потенциальная проблема с общими сценариями - когда кэширование становится слишком агрессивным (как кэширование внешних конфигурационных файлов между различными пользователями). Я недавно встретился с этим видом поведения с XCache и hardlinks. С надлежащей конфигурацией и неошибочными реализациями это не проблема все же.
Так, мое заключение:
Если бы это выполнимо, я использовал бы совместно использованные установки и для удобства и для производительности. Однако в некоторых ситуациях разница в производительности может быть незначительной, таким образом, это, вероятно, "что соответствует Вашей ситуации лучше".
awk '{ if (length($0) < 16384) print }' yourfile >your_output_file.txt
будет печатать строки короче 16 килобайт, как в вашем собственном примере.
Или, если вам нравится Perl:
perl -nle 'if (length($_) < 16384) { print }' yourfile >your_output_file.txt
Это похоже на ответ Ансгара, но немного быстрее в моих тестах:
awk 'length($0) < 16384' infile >outfile
Это такая же скорость, как и другие ответы awk. Он полагается на неявный print истинного выражения, но не требует времени, чтобы разделить строку, как это делает Ансгар.
Обратите внимание, что AWK дает вам if бесплатно. Приведенная выше команда эквивалентна:
awk 'length($0) < 16384 {print}' infile >outfile
Нет явного if (или окружающего его набора фигурных скобок), как в некоторых других ответах.
Вот способ сделать это в ] sed :
sed '/.\{16384\}/d' infile >outfile
или:
sed -r '/.{16384}/d' infile >outfile
, которые удаляют любую строку, содержащую 16384 (или более) символа.
Для полноты, вот как вы могли бы использовать sed , чтобы дольше сохранять строки чем ваш порог:
sed '/^.\{0,16383\}$/d' infile >outfile
Вы можете awk , например:
$ awk '{ if (length($0) < 16384) { print } }' /path/to/text/file
Это напечатает строки короче 16К символов (16 * 1024).
Вы можете использовать grep также:
$ grep ".\{,16384\}" /path/to/text/file
Это напечатает строки не более 16K символов.
Не очень отличается от уже приведенных ответов, но еще короче:
awk -F '' 'NF < 16384' infile >outfile