Вопросы Теги

Linux: Действительно находит | xargs grep, имеют ограничения?

Если Вы просто хотите запустить программу с определенной реализацией Java, дайте полный путь java интерпретатор:

/usr/lib/jvm/jre-1.6.0-openjdk/bin/java my-app.jar

Если Вы хотите изменить интерпретатор по умолчанию, просто необходимо работать update-alternatives как корень:

sudo update-alternatives --config java

2
25.10.2012, 16:52
4 ответа

Каталоги с именами, которые содержат пробелы, видимые от /foo/bar а не от barfoo, вероятные преступники. xargs разделяет его вывод пробелами и также интерпретирует кавычки, обратные косые черты, и даже _ символ — видит руководство для получения дополнительной информации таким образом, пробел на имена файла или каталога заставляет это передавать неполные имена файлов grep.

Для работы вокруг этой проблемы использовать find -print0 в сочетании с xargs -0, как это:

find . -print0 2>/dev/null | xargs -0 grep -i something_to_find 2>/dev/null

-print0 опция говорит find разделить имена файлов с двоичными 0 символами, которые не могут появиться на имя правильного файла. Соответствие -0 опция говорит части использовать тот же самый символ в качестве разделителя и также не интерпретировать кавычки и обратные косые черты.

7
27.01.2020, 21:55
  • 1
    Ваше объяснение имеет смысл. То, что я не полностью понимаю, - то, почему это отказало бы и не продвинулось бы, даже если бы это встретилось с файлом, который не существовал. Независимо, это решило мой конкретный вопрос +5 (если я мог) –  vol7ron 25.10.2012, 01:21
  • 2
    Возможно, это не пробелы, xargs возможно, также встретился с апострофом в имени файла (часто существующий в именах файлов песен или фильмов), который заставит его искать "кавычку соответствия", нигде не быть найденным. Так как Вы полностью отбрасываете вывод ошибок, Вы не видели бы "несопоставленной одинарной кавычки" ошибка, ни ошибки от grep. При отладке проблем это - хорошая идея по крайней мере временно удалить 2>/dev/null перенаправления, таким образом, программы могут предупредить Вас об ошибках. –   25.10.2012, 01:40
  • 3
    Когда я отладил, я удалил ошибочное перенаправление (removing the redirection of STDERR has no bearing on the result, or lack thereof) и я не заметил, что что-либо кроме разрешения отклонило / не, существуют ошибки (никакие специальные символы). Я думаю, что не существует, ошибки были из-за пробелов, но он встретился с несколькими из тех и все еще продвинулся. Я все еще озадачен на том, каков истинный характер был, но благодарен из Вашей справки. Я думаю, что попробовал -0 на xargs, но не сделал -print0 на находке - еще раз спасибо! выполнение –  vol7ron 25.10.2012, 01:44

Учитывая Ваше последнее редактирование я хотел бы указать на Вас на свой комментарий выше снова:

Так как Вы упоминаете "тот же сервер": Есть ли шанс, что специальные файлы как/proc/kcore или/dev/zero находятся где-нибудь в пути? Это, конечно, мешало бы grep идти дальше.....

Начиная с добавления расширения производит различные результаты выполнения w/o такие пробелы правил как преступник.

0
27.01.2020, 21:55
  • 1
    , это - действительный комментарий, и я пытался ответить на это с I realize I wasn't specific on the path, but these are all well-named directories, not to be confused with any devices. Все еще возможно, что уродливое имя файла с пробелами, возможно, разделило странно - я должен буду проверить, когда у меня есть немного больше времени; однако я сомневаюсь относительно этого. Я обычно не использую пробелы в Linux. Я думаю в рассмотрении "ошибок", которыми останавливающаяся точка была в различных местах, но как я сказал... Я проверю, потому что я очень не хочу не знать причину проблем предотвратить их в будущем. лень –  vol7ron 25.10.2012, 06:36

Попробуйте это:

find . -type f -print0 | tee /tmp/file-list | xargs -0 egrep whatever

/tmp/file-list (просматривают его с чем-то, что не возражает, аннулирует), содержат Ваш желаемый файл (файлы)? Если не, это - проблема находки. Если да, это - вопрос xargs.

Я имею намеренно не 2> 'd далеко ошибки. Они могут быть полезными.

-1
27.01.2020, 21:55

Попробуйте 

grep -r something_to_find 2>/dev/null

"grep -r..." будет рекурсивно искать все файлы из $PWD.

0
27.01.2020, 21:55

Теги

Похожие вопросы