Способ узнать, действительно ли systemd является инициализацией по умолчанию

Из всех решений, предложенных на данный момент, мое оригинальное решение с использованием grep является самым быстрым, оно завершается за 25 секунд. Его недостаток в том, что добавлять и удалять ключевые слова очень утомительно. Поэтому я придумал скрипт (названный multi), который имитирует поведение, но позволяет изменить синтаксис:

#!/bin/bash

# Usage: multi [z]grep PATTERNS -- FILES

command=$1

# first two arguments constitute the first command
command_head="$1 -le '$2'"
shift 2

# arguments before double-dash are keywords to be piped with xargs
while (("$#")) && [ "$1" != -- ] ; do
  command_tail+="| xargs $command -le '$1' "
  shift
done
shift

# remaining arguments are files
eval "$command_head $@ $command_tail"

Так что теперь написание multi grep one two three -- * эквивалентно моему оригинальному предложению и выполняется за то же время. Я также могу легко использовать его для сжатых файлов, используя zgrep в качестве первого аргумента.

Другие решения

Я также экспериментировал со сценарием на Python, используя две стратегии: поиск всех ключевых слов построчно и поиск по ключевому слову во всем файле. В моем случае вторая стратегия была быстрее. Но она оказалась медленнее, чем просто использование grep, завершившись за 33 секунды. Построчный поиск по ключевому слову завершился за 60 секунд.

#!/usr/bin/python3

import gzip, sys

i = sys.argv.index('--')
patterns = sys.argv[1:i]
files = sys.argv[i+1:]

for f in files:
  with (gzip.open if f.endswith('.gz') else open)(f, 'rt') as s:
    txt = s.read()
    if all(p in txt for p in patterns):
      print(f)

Скрипт приведенный terdon завершил работу за 54 секунды. На самом деле это заняло 39 секунд времени стены, потому что мой процессор двухъядерный. Что интересно, потому что мой скрипт Python занял 49 секунд времени ожидания (а grep - 29 секунд).

Скрипт cas не смог завершиться за разумное время, даже на меньшем количестве файлов, которые обрабатывались с помощью grep менее 4 секунд, поэтому мне пришлось его убить.

Но его оригинальное предложение awk, хотя оно и медленнее, чем grep как есть, имеет потенциальное преимущество. В некоторых случаях, по крайней мере, по моему опыту, можно ожидать, что все ключевые слова должны появиться где-то в голове файла, если они вообще есть в файле. Это дает данному решению значительный прирост производительности:

for f in *; do
  zcat $f | awk -v F=$f \
    'NR>100 {exit} /one/ {a++} /two/ {b++} /three/ {c++} a&&b&&c {print F; exit}'
done

Завершение работы происходит за четверть секунды, по сравнению с 25 секундами.

Конечно, у нас может не быть преимущества поиска ключевых слов, которые, как известно, встречаются в начале файлов. В таком случае решение без NR>100 {exit} занимает 63 секунды (50 с времени стены).

Несжатые файлы

Нет существенной разницы во времени работы между моим решением grep и предложением awk от cas, оба решения выполняются за доли секунды.

Обратите внимание, что инициализация переменной FNR == 1 { f1=f2=f3=0; } в этом случае обязательна для сброса счетчиков для каждого последующего обрабатываемого файла. По существу, это решение требует редактирования команды в трех местах, если вы хотите изменить ключевое слово или добавить новые. С другой стороны, при использовании grep вы можете просто добавить | xargs grep -l four или отредактировать нужное ключевое слово.

Недостатком решения grep, использующего подстановку команд, является то, что оно зависнет, если в любом месте цепочки, до последнего шага, нет подходящих файлов. Это не влияет на вариант xargs, потому что труба будет прервана, как только grep вернет ненулевой статус. Я обновил свой сценарий, чтобы использовать xargs, так что мне не придется обрабатывать это самому, что упрощает сценарий.