Como posso o `find` ignorar os diretórios .svn?


227

Costumo usar o findcomando para pesquisar no código fonte, excluir arquivos, o que for. Irritantemente, porque o Subversion armazena duplicatas de cada arquivo em seus .svn/text-base/diretórios, minhas pesquisas simples acabam obtendo muitos resultados duplicados. Por exemplo, desejo pesquisar recursivamente uintem vários arquivos messages.he messages.cpp:

# find -name 'messages.*' -exec grep -Iw uint {} +
./messages.cpp:            Log::verbose << "Discarding out of date message: id " << uint(olderMessage.id)
./messages.cpp:    Log::verbose << "Added to send queue: " << *message << ": id " << uint(preparedMessage->id)
./messages.cpp:                Log::error << "Received message with invalid SHA-1 hash: id " << uint(incomingMessage.id)
./messages.cpp:            Log::verbose << "Received " << *message << ": id " << uint(incomingMessage.id)
./messages.cpp:            Log::verbose << "Sent message: id " << uint(preparedMessage->id)
./messages.cpp:        Log::verbose << "Discarding unsent message: id " << uint(preparedMessage->id)
./messages.cpp:        for (uint i = 0; i < 10 && !_stopThreads; ++i) {
./.svn/text-base/messages.cpp.svn-base:            Log::verbose << "Discarding out of date message: id " << uint(olderMessage.id)
./.svn/text-base/messages.cpp.svn-base:    Log::verbose << "Added to send queue: " << *message << ": id " << uint(preparedMessage->id)
./.svn/text-base/messages.cpp.svn-base:                Log::error << "Received message with invalid SHA-1 hash: id " << uint(incomingMessage.id)
./.svn/text-base/messages.cpp.svn-base:            Log::verbose << "Received " << *message << ": id " << uint(incomingMessage.id)
./.svn/text-base/messages.cpp.svn-base:            Log::verbose << "Sent message: id " << uint(preparedMessage->id)
./.svn/text-base/messages.cpp.svn-base:        Log::verbose << "Discarding unsent message: id " << uint(preparedMessage->id)
./.svn/text-base/messages.cpp.svn-base:        for (uint i = 0; i < 10 && !_stopThreads; ++i) {
./virus/messages.cpp:void VsMessageProcessor::_progress(const string &fileName, uint scanCount)
./virus/messages.cpp:ProgressMessage::ProgressMessage(const string &fileName, uint scanCount)
./virus/messages.h:    void _progress(const std::string &fileName, uint scanCount);
./virus/messages.h:    ProgressMessage(const std::string &fileName, uint scanCount);
./virus/messages.h:    uint        _scanCount;
./virus/.svn/text-base/messages.cpp.svn-base:void VsMessageProcessor::_progress(const string &fileName, uint scanCount)
./virus/.svn/text-base/messages.cpp.svn-base:ProgressMessage::ProgressMessage(const string &fileName, uint scanCount)
./virus/.svn/text-base/messages.h.svn-base:    void _progress(const std::string &fileName, uint scanCount);
./virus/.svn/text-base/messages.h.svn-base:    ProgressMessage(const std::string &fileName, uint scanCount);
./virus/.svn/text-base/messages.h.svn-base:    uint        _scanCount;

Como posso dizer findpara ignorar os .svndiretórios?


Atualização : se você atualizar o seu cliente SVN para a versão 1.7, isso não será mais um problema.

Um recurso importante das alterações introduzidas no Subversion 1.7 é a centralização do armazenamento de metadados da cópia de trabalho em um único local. Em vez de um .svndiretório em todos os diretórios da cópia de trabalho, as cópias de trabalho do Subversion 1.7 têm apenas um .svndiretório - na raiz da cópia de trabalho. Este diretório inclui (entre outras coisas) um banco de dados baseado em SQLite que contém todos os metadados que o Subversion precisa para essa cópia de trabalho.


4
Para desempenho, tente usar em find ... -print0 | xargs -0 egrep ...vez de find ... -exec grep ...(não bifurca greppara cada arquivo, mas para vários arquivos por vez). Usando este formulário, você também pode remover .svndiretórios sem usar a -pruneopção find, ou seja,find ... -print0 | egrep -v '/\.svn' | xargs -0 egrep ...
vladr

3
@ Vlad: Tanto quanto eu sei, usando -execcom +não bifurca greppara cada arquivo, enquanto usá-lo com ;faz. Usar -execé realmente mais correto do que usar xargs. Observe que comandos como lsfazem algo mesmo que a lista de argumentos esteja vazia, enquanto comandos como chmoddão um erro se houver argumentos insuficientes. Para ver o que quero dizer, tente o seguinte comando em um diretório que não tem qualquer script shell: find /path/to/dir -name '*.sh' -print0 | xargs -0 chmod 755. Compare com esta: find /path/to/dir -name '*.sh' -exec chmod 755 '{}' '+'.
você precisa saber é o seguinte

2
@ Vlad: Além disso, grepsair .svntambém não é uma boa ideia. Enquanto findé especializado para manipular propriedades de arquivo, grepnão. No seu exemplo, um arquivo chamado '.svn.txt' também será filtrado pelo seu egrepcomando. Embora você possa modificar seu regex para '^ / \. Svn $' , ainda não é uma boa prática fazer isso. O -prunepredicado findfunciona perfeitamente para filtrar um arquivo (por nome de arquivo ou carimbo de data / hora da criação ou qualquer condição que você forneceu). É como se você pudesse matar uma barata usando uma espada grande, não significa que é a maneira sugerida de fazê-lo :-).
você precisa saber é o seguinte

3
Mudar para o Git corrigiu esse problema (entre muitos outros). Faz apenas uma pasta .git na raiz da cópia de trabalho, não em todas as pastas como SVN. Além disso, a pasta .git não contém arquivos simples que seriam confundidos com seus arquivos reais pelos mesmos nomes.
Tronic

3
2Dan Molding: svn 1.7 cria apenas um diretório .svn de nível superior
ccpizza

Respostas:


65

Para pesquisar, posso sugerir que você olhe para ack ? É compatível com o código-fonte e find, como tal, ignorará automaticamente muitos tipos de arquivos, incluindo informações sobre o repositório do código-fonte, como o descrito acima.


3
Eu gosto ackmuito, mas achei que era substancialmente mais lento do que find -type f -name "*.[ch]" | xargs grepquando lida com uma grande base de código.
John Ledbetter

63
John, eu sou o autor do ack, e se você puder me dar detalhes dos problemas de velocidade do ack vs. grep, eu agradeceria. Eles foram completamente comparáveis ​​em todos os casos que encontrei. Informe- me em github.com/petdance/ack/issues ou envie-me um e-mail para andy em petdance.com. Thansk.
Andy Lester

63
Gente, isso é uma dica, mas definitivamente não é uma resposta para a pergunta! :)
dolzenko

8
O ackfaturamento não é melhor grep, nem reconhece a fonte find? Alguns exemplos de como substituí find-lo tornariam essa uma resposta real.
Michiakig

3
É uma resposta para a pergunta que ele não sabia que estava fazendo. =)
Frungi

293

porque não apenas

find . -not -iwholename '*.svn*'

O predicado -not nega tudo o que tem .svn em qualquer lugar do caminho.

Então, no seu caso, seria

find -not -iwholename '*.svn*' -name 'messages.*' -exec grep -Iw uint {} + \;

5
Super grande +1 para "-not" e "-iwholename". Ack é maravilhoso e eu uso, mas o find / exec ainda tem seus usos.
David Blevins

9
A única resposta que realmente respondeu à pergunta original.
Brendon Crawford

14
Estou fora do meu elemento e tenho certeza de que serei criticado por esse comentário, mas aparentemente -not e -wholename não são compatíveis com POSIX. Eu usei ! no lugar de -not e -path no lugar de -iwholename e obteve os mesmos resultados. De acordo com minhas páginas de manual (Ubuntu 12.04), esta sintaxe é compatível com POSIX.
John

1
@ Whaley Você disse '*.svn*'no começo, mas depois '*.svn'. Qual é certo? Os dois funcionam? Eu acho que provavelmente deveria ser '*.svn*'?
21418 Keith M

1
@KeithM grande captura, na verdade. Esta resposta está aqui há anos e não acho que alguém tenha percebido isso até agora.
Whaley

141

Do seguinte modo:

find . -path '*/.svn*' -prune -o -print

Ou, alternativamente, com base em um diretório e não em um prefixo de caminho:

find . -name .svn -a -type d -prune -o -print

14
@Kaleb: Olá. Eu sugiro find . -type d -name .svn -prune -o -printporque é um pouco mais rápido. De acordo com o padrão POSIX , as expressões são avaliadas uma a uma, na ordem especificada. Se a primeira expressão em -afor false, a segunda expressão não será avaliada (também chamada de curto-circuito e avaliação ).
você precisa saber é o seguinte

2
@ Kaleb: Como comparar o tipo de arquivo (equivalente a testar se um bit está definido em um número inteiro) é mais rápido do que comparar o nome do arquivo (equivalente a uma comparação de cadeias de caracteres, que é O (n)), colocar -type dantes -name .svné teoricamente mais eficiente. No entanto, geralmente é insignificante, exceto se você tiver uma árvore de diretórios muito grande.
você precisa saber é o seguinte

5
@ SiuChingPong-AsukaKenji -, comparar apenas o nome do arquivo é mais rápido porque -type requer uma chamada stat (2) em cada arquivo. O nome do arquivo, no entanto, faz parte da resposta readdir (3).
Hraban

3
@JonathanHartley Está faltando a -printparte da última expressão. Algo como find . -name .git -prune -o \( -type f -name LICENSE -print \)funciona como esperado.
precisa saber é o seguinte

1
Se você deseja ignorar os arquivos .git e .svn e apenas lista os outros diretórios find . -name .svn -prune -o -name .git -prune -o -type d -print,. Pode ser alguns milissegundos mais rápido -type dantes dos dois -name, mas não vale a pena digitar mais.
JPaget 6/06/19

34

Para ignorar .svn, .gite outros diretórios ocultos (que começam com um ponto), tente:

find . -type f -not -path '*/\.*'

No entanto, se o objetivo de usar findestiver pesquisando nos arquivos, você pode tentar usar estes comandos:

  • git grep - comando especialmente projetado para pesquisar padrões no repositório Git.
  • ripgrep- que por padrão ignora arquivos ocultos e arquivos especificados em .gitignore.

Relacionado: Como encontro todos os arquivos que contêm texto específico no Linux?


Melhor resposta imo. Os outros tentam explicar coisas que não respondem à pergunta simples.
Anthony

19

Aqui está o que eu faria no seu caso:

find . -path .svn -prune -o -name messages.* -exec grep -Iw uint {} +

O rgrepcomando interno do Emacs ignora o .svndiretório e muitos outros arquivos nos quais você provavelmente não está interessado ao executar um find | grep. Aqui está o que ele usa por padrão:

find . \( -path \*/SCCS -o -path \*/RCS -o -path \*/CVS -o -path \*/MCVS \
          -o -path \*/.svn -o -path \*/.git -o -path \*/.hg -o -path \*/.bzr \
          -o -path \*/_MTN -o -path \*/_darcs -o -path \*/\{arch\} \) \
     -prune -o \
       \( -name .\#\* -o -name \*.o -o -name \*\~ -o -name \*.bin -o -name \*.lbin \
          -o -name \*.so -o -name \*.a -o -name \*.ln -o -name \*.blg \
          -o -name \*.bbl -o -name \*.elc -o -name \*.lof -o -name \*.glo \
          -o -name \*.idx -o -name \*.lot -o -name \*.fmt -o -name \*.tfm \
          -o -name \*.class -o -name \*.fas -o -name \*.lib -o -name \*.mem \
          -o -name \*.x86f -o -name \*.sparcf -o -name \*.fasl -o -name \*.ufsl \
          -o -name \*.fsl -o -name \*.dxl -o -name \*.pfsl -o -name \*.dfsl \
          -o -name \*.p64fsl -o -name \*.d64fsl -o -name \*.dx64fsl -o -name \*.lo \
          -o -name \*.la -o -name \*.gmo -o -name \*.mo -o -name \*.toc \
          -o -name \*.aux -o -name \*.cp -o -name \*.fn -o -name \*.ky \
          -o -name \*.pg -o -name \*.tp -o -name \*.vr -o -name \*.cps \
          -o -name \*.fns -o -name \*.kys -o -name \*.pgs -o -name \*.tps \
          -o -name \*.vrs -o -name \*.pyc -o -name \*.pyo \) \
     -prune -o \
     -type f \( -name pattern \) -print0 \
     | xargs -0 -e grep -i -nH -e regex

Ele ignora os diretórios criados pela maioria dos sistemas de controle de versão, além de gerar arquivos para muitas linguagens de programação. Você pode criar um alias que chama esse comando e substituir finde greppadrões para seus problemas específicos.


12

Localização GNU

find .  ! -regex ".*[/]\.svn[/]?.*"

Eu estava carregando os caminhos do diretório em uma matriz para o PHP processar. As outras respostas superiores (por qualquer motivo) não filtraram os arquivos na descoberta (apesar do -type d) - essa resposta foi. +1
be hollenbeck

11

Eu uso grep para esse fim. Coloque isso no seu ~ / .bashrc

export GREP_OPTIONS="--binary-files=without-match --color=auto --devices=skip --exclude-dir=CVS --exclude-dir=.libs --exclude-dir=.deps --exclude-dir=.svn"

O grep usa automaticamente essas opções na invocação


1
Vale a pena notar que 'grep' ganhou apenas a opção '--exclude-dir' há um ou dois anos. Distribuições recentes do Linux incluem, mas se bem me lembro, tive que compilar meu próprio grep (ou pedir para a homebrew fazer isso) no OSX.
Jonathan Hartley

Eu uso uma variante menor disso. Meu .bashrc cria uma função Bash 'grp', definida como GREP_OPTIONS=xxx grep "$@". Isso significa que a variável GREP_OPTIONS é definida apenas para instâncias do grep executadas manualmente usando 'grp'. Isso significa que nunca recebo uma situação em que executo uma ferramenta e, internamente, ela chama grep, mas a ferramenta fica confusa porque o grep não está se comportando conforme o esperado. Além disso, tenho uma segunda função 'grpy', que chama 'grp', mas acrescenta --include=*.py, apenas para pesquisar arquivos Python.
9788 Jonathan Steinley

Na verdade, pensando bem, fazer do meu jeito não precisa mais usar GREP_OPTIONS. Agora eu só tenho uma função shell 'grp' que chama grep --exclude=tags --exclude_dir=.git ...etc... "$@". Gosto que isso funcione como 'ack', mas mantenho a consciência e o controle sobre o que está fazendo.
Jonathan Hartley

9

find . | grep -v \.svn


Você tem que escapar .na .svnregexp.
vladr

4
Use --fixed-strings com grep: | fgrep -v /.svn/ou `| grep -F -v / .svn / `para excluir exatamente o diretório e não os arquivos com" .svn "como parte de seu nome.
Stephen P

8

Por que você não canaliza seu comando com grep, que é facilmente compreensível:

your find command| grep -v '\.svn'

Você tem que escapar .na .svnregexp.
vladr

@Yclian sem sombra de dúvida; caso contrário, os diretórios chamados 'tsvn', '1svn', 'asvn' etc. também serão ignorados desde '.' é um curinga regexp: 'corresponde a qualquer caractere'.
vladr

Tudo bem, eu pensei que isso só aconteceria no caso de -E e -G. Acabei de testar, meu mal. :(
yclian

2
Eu gosto desta resposta porque é conceitualmente mais simples que todas as outras. Não me lembro da sintaxe ridícula do uso 'find', mas definitivamente consigo me lembrar de como usar grep -v, pois é usado em muitas situações.
mattismyname

8

Crie um script chamado ~/bin/svnfind:

#!/bin/bash
#
# Attempts to behave identically to a plain `find' command while ignoring .svn/
# directories.

OPTIONS=()
PATHS=()
EXPR=()

while [[ $1 =~ ^-[HLP]+ ]]; do
    OPTIONS+=("$1")
    shift
done

while [[ $# -gt 0 ]] && ! [[ $1 =~ '^[-(),!]' ]]; do
    PATHS+=("$1")
    shift
done

# If user's expression contains no action then we'll add the normally-implied
# `-print'.
ACTION=-print

while [[ $# -gt 0 ]]; do
    case "$1" in
       -delete|-exec|-execdir|-fls|-fprint|-fprint0|-fprintf|-ok|-print|-okdir|-print0|-printf|-prune|-quit|-ls)
            ACTION=;;
    esac

    EXPR+=("$1")
    shift
done

if [[ ${#EXPR} -eq 0 ]]; then
    EXPR=(-true)
fi

exec -a "$(basename "$0")" find "${OPTIONS[@]}" "${PATHS[@]}" -name .svn -type d -prune -o '(' "${EXPR[@]}" ')' $ACTION

Esse script se comporta de maneira idêntica a um findcomando simples, mas remove os .svndiretórios. Caso contrário, o comportamento é idêntico.

Exemplo:

# svnfind -name 'messages.*' -exec grep -Iw uint {} +
./messages.cpp:            Log::verbose << "Discarding out of date message: id " << uint(olderMessage.id)
./messages.cpp:    Log::verbose << "Added to send queue: " << *message << ": id " << uint(preparedMessage->id)
./messages.cpp:                Log::error << "Received message with invalid SHA-1 hash: id " << uint(incomingMessage.id)
./messages.cpp:            Log::verbose << "Received " << *message << ": id " << uint(incomingMessage.id)
./messages.cpp:            Log::verbose << "Sent message: id " << uint(preparedMessage->id)
./messages.cpp:        Log::verbose << "Discarding unsent message: id " << uint(preparedMessage->id)
./messages.cpp:        for (uint i = 0; i < 10 && !_stopThreads; ++i) {
./virus/messages.cpp:void VsMessageProcessor::_progress(const string &fileName, uint scanCount)
./virus/messages.cpp:ProgressMessage::ProgressMessage(const string &fileName, uint scanCount)
./virus/messages.h:    void _progress(const std::string &fileName, uint scanCount);
./virus/messages.h:    ProgressMessage(const std::string &fileName, uint scanCount);
./virus/messages.h:    uint        _scanCount;

Este script não funciona como eu esperaria. Ao executá-lo com "svnfind do tipo f", que também imprime svn-diretórios e os arquivos no SVN-diretórios
Ingo Fischer

@ifischer Você pode adicionar um echoao comando find e me dizer qual comando é executado? svnfind -type ffunciona muito bem na minha máquina Red Hat.
John Kugelman

Ok, então parece ser dependente do sistema operacional. Estou executando o Debian Squeeze (é o mesmo no Ubuntu). Eu não entendo o que você quer dizer com "adicionar um eco"?
Ingo Fischer

@ifischer Altere a última linha para, echo find "${OPTIONS[@]}"...para que ele imprima o comando find em vez de executá-lo.
John Kugelman

Ok, alterei a última linha para echo find ${OPTIONS[@]} ${PATHS[@]} -name .svn -type d -prune -o ( ${EXPR[@]} ) $ACTION, Isso me dá a seguinte saída:find -type f -name .svn -type d -prune -o ( -true ) -print
Ingo Fischer

5

Apenas pensei em adicionar uma alternativa simples às postagens de Kaleb e de outras pessoas (que detalham o uso da find -pruneopção ack, repofindcomandos , etc.), que é particularmente aplicável ao uso que você descreveu na pergunta (e qualquer outro uso semelhante):

  1. Para desempenho, você deve sempre tentar usar find ... -exec grep ... +(obrigado Kenji por apontar isso) ou find ... | xargs egrep ...(portátil) ou find ... -print0 | xargs -0 egrep ...(GNU; funciona em nomes de arquivos contendo espaços) em vez de find ... -exec grep ... \;.

    O formulário find ... -exec ... +e find | xargsnão bifurca egreppara cada arquivo, mas para vários arquivos por vez, resultando em uma execução muito mais rápida .

  2. Ao utilizar o find | xargsformulário que você também pode usar grepa facilidade e rapidez de ameixa .svn(ou quaisquer diretórios ou expressão regular), ou seja, find ... -print0 | grep -v '/\.svn' | xargs -0 egrep ...(útil quando você precisa de algo rápido e não pode ser incomodado para lembrar como configurar find's -prunelógica.)

    A find | grep | xargsabordagem é semelhante GNU para find's -regexopção (ver ghostdog74' s post), mas é mais portátil (também funcionará em plataformas onde GNU findnão está disponível.)


1
@ Vlad: Observe que existem dois formulários para a -exectroca find: um está terminando com ;e o outro está terminando com +. O que termina com +substitui {}por uma lista de todos os arquivos correspondentes. Além disso, seu regex também '/\.svn'combina nomes de arquivos '.svn.txt'. Por favor, consulte meus comentários na pergunta para obter mais informações.
você precisa saber é o seguinte

2
@ Vlad: Aqui está o padrão POSIX para o findutilitário. Por favor, veja a -execparte :-).
você precisa saber é o seguinte

4

Em um repositório de código-fonte, geralmente quero fazer as coisas apenas com os arquivos de texto.

A primeira linha são todos os arquivos, excluindo os arquivos de repositório CVS, SVN e GIT.

A segunda linha exclui todos os arquivos binários.

find . -not \( -name .svn -prune -o -name .git -prune -o -name CVS -prune \) -type f -print0 | \
xargs -0 file -n | grep -v binary | cut -d ":" -f1

3

Eu uso find com as opções -not -path. Não tive boa sorte com ameixa.

find .  -name "*.groovy" -not -path "./target/*" -print

encontrará os arquivos groovy que não estão no caminho do diretório de destino.


3

Para resolver esse problema, você pode simplesmente usar esta condição de localização:

find \( -name 'messages.*' ! -path "*/.svn/*" \) -exec grep -Iw uint {} +

Você pode adicionar mais restrições como esta:

find \( -name 'messages.*' ! -path "*/.svn/*" ! -path "*/CVS/*" \) -exec grep -Iw uint {} +

Você pode encontrar mais informações sobre isso na seção "Operadores" da página de manual: http://unixhelp.ed.ac.uk/CGI/man-cgi?find


3

Observe que se você fizer

find . -type f -name 'messages.*'

então -printé implícito quando toda a expressão ( -type f -name 'messages.*') é verdadeira, porque não há 'ação' (como -exec).

Enquanto, para parar de descer para determinados diretórios, você deve usar qualquer coisa que corresponda a esses diretórios e segui-lo -prune(que se destina a parar de descer para diretórios); igual a:

find . -type d -name '.svn' -prune

Isso é avaliado como True para os diretórios .svn, e podemos usar um curto-circuito booleano seguindo isto por -o(OR), após o qual o que se segue após o -oé verificado apenas quando a primeira parte é False, portanto, não é um diretório .svn. Em outras palavras, o seguinte:

find . -type d -name '.svn' -prune -o -name 'message.*' -exec grep -Iw uint {}

só evalute o que é certo do -o, ou seja -name 'message.*' -exec grep -Iw uint {}, para arquivos não dentro diretórios .svn.

Observe que, como .svnprovavelmente sempre é um diretório (e não, por exemplo, um arquivo), e, nesse caso, certamente não corresponde ao nome 'message. *', Você também pode deixar de lado o seguinte -type dcomando:

find . -name '.svn' -prune -o -name 'message.*' -exec grep -Iw uint {}

Por fim, observe que, se você omitir qualquer ação ( -execé uma ação), diga o seguinte:

find . -name '.svn' -prune -o -name 'message.*'

a -printação é implícita, mas será aplicada à expressão WHOLE, incluindo a -name '.svn' -prune -oparte e, assim, imprima todos os diretórios .svn, bem como os arquivos 'message. *', o que provavelmente não é o que você deseja. Portanto, você sempre deve usar uma 'ação' no lado direito da expressão booleana ao usá -prune-lo dessa maneira. E quando essa ação está sendo impressa, você deve adicioná-la explicitamente, assim:

find . -name '.svn' -prune -o -name 'message.*' -print


2

Tente findrepo, que é um invólucro simples em torno de find / grep e muito mais rápido que o ack. Você usaria neste caso como:

findrepo uint 'messages.*'

2

wcfind é um script de wrapper de localização que eu uso para remover automaticamente diretórios .svn.


1

Isso funciona para mim no prompt do Unix

gfind. \ (-not -wholename '* \. svn *' \) -tipo f -name 'messages. *' -exec grep -Iw uint {} +

O comando acima listará FILES que não estão com .svn e executará o grep que você mencionou.


'gfind' é um erro de digitação? Eu não o tenho no Ubuntu 14.04.
9788 Jonathan Steinley

Supondo que você quis dizer 'encontrar', isso não funciona muito bem. Ele também filtra arquivos como xxx.svnxxx. Isso é importante - por exemplo, se você estiver usando git em vez de svn, geralmente desejará incluir arquivos como .gitignore (que não são metadados, é um arquivo comum incluído no repositório) nos resultados da localização.
9788 Jonathan Steinley

1

Eu normalmente canalizo a saída através do grep mais uma vez removendo .svn, no meu uso, não é muito mais lento. exemplo típico:

find -name 'messages.*' -exec grep -Iw uint {} + | grep -Ev '.svn|.git|.anythingElseIwannaIgnore'

OU

find . -type f -print0 | xargs -0 egrep messages. | grep -Ev '.svn|.git|.anythingElseIwannaIgnore'
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.