grepping dotfiles with -R correctly?

Question

From time to time I need to find a culprit in an unknown dotfile and instead of trying to figure out which package is to be blamed (e.g. xfce4 or thunar?) and what is their naming convention (.app vs .application vs .some_old_name vs .config/app...), I just want to go for it the quick & dirty way:

me@here:~$ grep -IR .* -e culprit

But this quick & dirty way is also the silly way. After few minutes I figure out that .* means .. as well, and there we are. Sometimes I resort to probably even less quick & more dirty variant:

me@here:~$ grep -IR /home/me -e culprit

which turns out to be of a superior silliness, especially if I have some huge or distant mountains at my $HOME. Too bad that I can't figure out The Quick And Clean And Right Way. (And my disk heads are slowly wearing out.)

Is it possible to achieve this within wildcard expansion at all? I.e. a variant of .* that does not match .. (and ../.....)?

Answer 1

If you have bash available, you can use extglob to get only dotfiles.

shopt -s extglob
grep -IR 'foo' .!(|.)

The ! operator in an extended glob is "not". This pattern matches anything starting with a dot, excluding '.' and '..'.

Answer 2

If you're on Linux, you can try

grep -IR --exclude-dir=".." culprit .*

---

Since you asked about shell wildcards, my first thought is .[!.]* ..[!.]*, as in

grep -IR culprit .[!.]* ..[!.]*

Which has the problem that grep will exit with an error if there are no files starting with ... To get around that, you can either add -s to grep to tell it to ignore missing files:

grep -IRs culprit .[!.]* ..[!.]*

Or use the bash and zsh nullglob option to make ..[!.]* expand to nothing if there are no files beginning with ..

shopt -s nullglob   # for bash
setopt nullglob     # for zsh

grep -IR culprit .[!.]* ..[!.]*

Failing all of the above, there's always find

find . -path "./.*" -exec grep culprit {} +

Answer 3

Thanks to this wiki, I found there is this GLOBIGNORE variable:

The Bash variable (not shopt) GLOBIGNORE allows you to specify patterns a glob should not match. This lets you work around the infamous "I want to match all of my dot files, but not . or .." problem:

$ echo .*
. .. .bash_history .bash_logout .bashrc .inputrc .vimrc
$ GLOBIGNORE=.:..
$ echo .*
.bash_history .bash_logout .bashrc .inputrc .vimrc

Nice thing is that this has almost no side effects (I mean, how often you really want to match .. and .?), so it would be even acceptable to export GLOBIGNORE=.:.. from .bashrc, and for manual tasks just use the old .* glob, as in the first example in the Q.

me@here:~$ set | grep GLOBIGNORE
GLOBIGNORE=.:.
me@here:~$ grep -IR .* -e culprit
.some-app/congig: set culprit=1
me@here:~$

Answer 4

I use this script to quickly edit dotfiles:

dirs=($HOME/.$1* $HOME/.$1/ $XDG_CONFIG_HOME/$1/)

IFS=$'\n' 
read -r -d '' -a files /dev/null)
(( ${#files[*]} )) && "$EDITOR" "${files}"

A more POSIX version:

find "${dirs[@]}" -type f \( -name "*.conf" -o -name "conf" -o -name "config" \
-o -name "*rc" -o -name "*.

Answer 5

grep -IR culprit .[!.]*

.[!.]* matches all dot files except the ones that begin with ... Since dot files don't begin with .., that's ok.

Or you could use zsh, which never includes . or .. in a glob:

grep -IR culprit .*

More esoterically, in bash, if you have the extglob option turned on (shopt -s extglob), this works, and includes ..?* (it also works in ksh, and in zsh after setopt ksh_glob):

grep -IR culprit !(|.)

Answer 6

To solve your problem, try this instead (in bash), that matches everything but ..:

shopt -s dotglob; grep -e culprit -IR *

But actually you wanted this,

grep -e culprit -IR .

.* is unnecessary since you can start grep from current directory.

Answer 7

Just found this one:

me@here:~$ grep -IR .[a-zA-Z0-9]* -e culprit

ugly as hell and not trivial to type, but seems to do the job. Most of the time you could omit the caps and digits:

me@here:~$ grep -IR .[a-z]* -e culprit

There must be a nicer way, though...

Answer 8

Try:

grep -R -e culprit \.*

The backslash before the dot I think will make it a literal dot instead of treating dot as the meta character meaning match any atom.