New answers tagged

0

The easiest way in bash to print matching dot files, ignoring . and .. is: $ GLOBIGNORE=/+/ $ printf '%s\n' * To test: $ cd tmp; mkdir empty; cd empty; touch {,.}{a..h} $ GLOBIGNORE=/+/ $ ls * a .a b .b c .c d .d e .e f .f g .g h .h It printed all files with dots or not, with the notable exception of . and ... Your example will ...


29

There are two problems with your example. The primary one is that you're assuming that regular expressions work the same as glob patterns in that * is a wildcard meaning "any sequence of characters." In regular expressions, * means "any number of the previous atom" instead, so fil* means f followed by i followed by zero or more l characters. You need to say ...


1

* is a glob that is expanded by the shell. By default shells don't include files whose name starts with a . (called hidden files or dotfiles) unless the leading . is entered literally. * or [.]* or ?* or *.* or dir/* will not include dotfiles. .* or dir/.* will. So you could do: mv -- * .* /dest/ however some shells including bash (but not zsh, mksh ...


0

This problem is caused by bugs in the "bash-completion" package. When the package is not installed bash does it's default completion, this is a pretty good generalised file name completion engine. The "bash-completion" package is supposed to look at the rest of the line and be "smart" about the lists it generates. However, it's unable to duplicate the ...


4

? is special (being used by both glob and history expansion, see zshexpn(1)), and thus requires escaping, but otherwise can be used as an alias, though probably should not be, given that it is special. % alias \?='echo hi' % ? hi


1

Short reason: the string ./.ignoramus is not matching .ignoramus. Short solution: use GLOBIGNORE=*ignoramus (also read detail at the end). $ GLOBIGNORE=*ignoramus $ ls .* | grep ignor ### empty $ ls ./.* | grep ignor ### also empty The asterisk will match anything (even an slash / before the name). Of course, that will also ...


4

The $GLOBIGNORE setting is processed by the shell when it expands the wildcard in your command line. In your first case, the shell first expands .* to .ignoramus, which is matched by $GLOBIGNORE, so it is not included in the names passed to ls. In your second case, the shell expands ./.* to ./.ignoramus, which is not matched by $GLOBIGNORE. If you set ...


8

No, it isn't dangerous. The extglob option doesn't increase the risk of accidentally causing damage. The only reason it isn't enabled by default is for backward compatibility with previous versions of bash, and even then, the cases where it breaks compatibility are pretty far-fetched, because most of what extglob enables is a syntax error if it isn't set due ...


2

Try using arrays for your exclusions, and expand them into --exclude-dir and --exclude options. e.g. in your ~/.codesearch_config script (presumably this is sourced by your main script?): #! /bin/bash # temporary array variables declare -a __exclude_directories declare -a __exclude_files if [[ "$PWD" == "$HOME/project"* ]]; then ...



Top 50 recent answers are included