Нижний регистр -r
была более старая опция, представленная в 4.1BSD, который просто скопирует все некаталоги как файлы. Таким образом, если бы это встретилось с устройством или FIFO, то это открыло бы его, считать содержание и создать файл в месте назначения с содержанием.
Верхний регистр -R
была стандартизированная опция (представленный BSD в 4.4BSD, хотя более ранние версии имели его как синоним к -r
) который был бы, при обнаружении с устройством, FIFO, или другим специальным файлом, сделать эквивалентный специальный файл в месте назначения.
Много реализаций действительно все еще поддерживают это различие, но некоторые (включая версию GNU, типичную к Linux) только, обеспечивают -R
семантика, с -r
как синоним.
alias cgrep='grep -nR --color'
Использование:
$ cgrep somestring /path/to/dir/or/file/with*/possible/*wild.card
Также одно из моего избранного:
$ pgrep some-hanging-process
перечислит весь pids процессов, которые соответствуют названию some-hanging-process, который можно использовать в следующей ситуации:
$ kill $(pgrep some-hanging-process)
Я нашел, что лучший способ к сутенеру grep состоит в том, чтобы использовать ack, который является чрезвычайно рекурсивным grep с интеллектуальным черным списком (например, не ищет .svn каталоги, игнорирует файлы резервных копий, и т.д.), цветное выделение результатов и жемчуга regexps. Это - то, что Вы хотите, чтобы grep сделал 98,6% времени.
Я установил это в своем .bashrc, вместо того, чтобы переопределить grep использование псевдонима:
export GREP_OPTIONS="--color=auto"
Для меня это работает над Linux, MacOSX & FreeBSD.
GREP_OPTIONS
должен считаться вредным. Я рекомендую использовать alias
вместо этого. Посмотрите здесь: bugs.launchpad.net/ubuntu/+bug/67141
– lesmana
25.03.2011, 18:44
Я рекомендовал бы избежать переменной среды GREP_OPTIONS, она будет влиять на каждый вызов grep, даже встроенные в других инструментах. Если те инструменты будут ожидать, что grep будет вести себя один путь, и Вы изменяете то поведение, то это будет и действительно повреждать те инструменты.
Вместо этого можно создать псевдоним, который работает хорошо. Это будет только влиять на вызовы к grep от Вашей интерактивной оболочки (т.е. что Вы вводите себя).
Заключительная опция, которую я люблю больше всего, состоит в том, чтобы создать сценарий обертки, который вызывает grep. Я предпочитаю это по псевдониму, потому что я могу вызвать эту обертку из других программ. Например, в энергии путем установки vimgrep, так, чтобы мои поиски из энергии вели себя тождественно к поискам в командной строке.
$ cat `which grp`
#!/usr/bin/env bash
grep -rI --color --exclude-dir=\.bzr --exclude-dir=\.git --exclude-dir=\.hg --exclude-dir=\.svn --exclude-dir=build --exclude-dir=dist --exclude=tags $*
Вызовите это использование:
$ grp pattern dir
например.
$ grp pattern .
будет искать экземпляры 'шаблона' во всех текстовых файлах в текущем dir и subdirs.
Заметьте, что я называю свой сценарий 'группой', а не затенением 'grep', так, чтобы я всегда знал, вызываю ли я grep со своими специализированными значениями по умолчанию или нет.
По умолчанию я включаю:
-r : search subdirs recursive
-I : skip binary files
--color : highlight matches in color
--exclude-dir : skip specified directories and their subdirs
--exclude : skip specified files
Я думаю, что все хотели бы пропустить директоров управления исходным кодом: .hg .git .bzr .svn
Пропуск 'сборки' и 'dist' является измами Python и вероятно не относится к большинству людей. Несомненно Вы разработаете свои собственные особенности, как Вы работаете.
'теги' являются выводом ctags, который я использую для, 'переходят к функциональному определению' и т.п. в инструментах как энергия. Как таковой это содержит по крайней мере одну копию каждого слова и символа от моего исходного кода, таким образом, это стоит пропустить от Ваших результатов поиска.
"$*" в конце является синтаксисом удара для "и все другие параметрические усилители от командной строки", таким образом, можно передать в шаблоне и dir для поиска как нормальные, и переопределять любые другие флаги командной строки Вы хотели бы.
--color
опция уже несколько раз упоминалась, но я хотел бы добавить, что возможно настроить цвет, в котором соответствия будут выделены с помощью переменной среды
export GREP_COLOR="1;33"
Цвет должен быть закодирован с помощью цветовых кодов ANSI для ссылки
Black 0;30 Dark Gray 1;30
Blue 0;34 Light Blue 1;34
Green 0;32 Light Green 1;32
Cyan 0;36 Light Cyan 1;36
Red 0;31 Light Red 1;31
Purple 0;35 Light Purple 1;35
Brown 0;33 Yellow 1;33
Light Gray 0;37 White 1;37
GREP_COLOR
удерживается от использования. Использовать GREP_COLORS
вместо этого.
– g33kz0r
07.04.2012, 00:48
Так как я не видел примеров фактического выбирания цветов, вот простая установка для GNU grep:
# turn on colors, natch.
export GREP_OPTIONS="--color=auto"
if [[ $(echotc Co) -ge 256 ]]; then
# 256 color terminals
export GREP_COLORS="mt=38;5;118:sl=:cx=:fn=38;5;18:ln=1;30:bn=37:se=30"
else
# everybody else
export GREP_COLORS="mt=31:sl=:cx=:fn=34:ln=1;30:bn=30:se=30"
fi
Будьте осторожны относительно GREP_OPTIONS
; не используйте его ни для чего кроме вещей как --color=auto
или это испортит любые сценарии, которые используют grep в Вашей системе.
grep
,grep -r
должен обычно предпочитатьсяgrep -R
поскольку первый не пересекает символьные ссылки. – Stéphane Chazelas 18.08.2014, 21:57