¿Cómo puedo obtener 'find' para ignorar los directorios .svn?

227

A menudo uso el findcomando para buscar a través del código fuente, eliminar archivos, lo que sea. Molesto, debido a que Subversion almacena duplicados de cada archivo en sus .svn/text-base/directorios, mis búsquedas simples terminan obteniendo muchos resultados duplicados. Por ejemplo, quiero buscar recursivamente uinten múltiples messages.hy messages.cpparchivos:

# 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;

¿Cómo puedo decir findque ignore los .svndirectorios?


Actualización : si actualiza su cliente SVN a la versión 1.7, esto ya no es un problema.

Una característica clave de los cambios introducidos en Subversion 1.7 es la centralización del almacenamiento de metadatos de la copia de trabajo en una sola ubicación. En lugar de un .svndirectorio en cada directorio de la copia de trabajo, las copias de trabajo de Subversion 1.7 tienen un solo .svndirectorio, en la raíz de la copia de trabajo. Este directorio incluye (entre otras cosas) una base de datos respaldada por SQLite que contiene todas las necesidades de Subversion de metadatos para esa copia de trabajo.

John Kugelman
fuente
44
Para el rendimiento, intente usar en find ... -print0 | xargs -0 egrep ...lugar de find ... -exec grep ...(no se bifurca greppara cada archivo, sino para un montón de archivos a la vez). Con este formulario también puede podar .svndirectorios sin usar la -pruneopción de buscar, es decirfind ... -print0 | egrep -v '/\.svn' | xargs -0 egrep ...
vladr
3
@Vlad: Hasta donde yo sé, usar -execwith +no fork greppara cada archivo, mientras que usarlo con ;does. Usar -execes en realidad más correcto que usar xargs. Tenga en cuenta que los comandos como lshacer algo, incluso si la lista de argumentos está vacía, mientras que los comandos como chmoddan un error si no hay suficientes argumentos. Para ver lo que quiero decir, sólo tratar el siguiente comando en un directorio que no tiene ningún script de shell: find /path/to/dir -name '*.sh' -print0 | xargs -0 chmod 755. Comparar con éste: find /path/to/dir -name '*.sh' -exec chmod 755 '{}' '+'.
Siu Ching Pong -Asuka Kenji-
2
@Vlad: Además, grepsalir .svnno es una buena idea también. Si bien findestá especializado para manejar propiedades de archivos, grepno lo hace. En su ejemplo, su comando también filtrará un archivo llamado '.svn.txt'egrep . Aunque puede modificar su expresión regular a '^ / \. Svn $' , aún no es una buena práctica hacerlo. El -prunepredicado de findfunciona perfectamente para filtrar un archivo (por nombre de archivo, o marca de tiempo de creación, o cualquier condición que haya proporcionado). Es como si incluso pudieras matar una cucaracha usando una gran espada, no significa que sea la forma sugerida de hacerlo :-).
Siu Ching Pong -Asuka Kenji-
3
Cambiar a Git solucionó este problema (entre muchos otros). En solo hace una carpeta .git en la raíz de la copia de trabajo, no en todas las carpetas como SVN. Además, la carpeta .git no contiene archivos simples que podrían confundirse con sus archivos reales con los mismos nombres.
Tronic
3
2Dan Molding: svn 1.7 solo crea un único directorio .svn de nivel superior
ccpizza

Respuestas:

65

Para buscar, ¿puedo sugerirle que mire ack ? Es consciente del código fuente y find, como tal, ignorará automáticamente muchos tipos de archivos, incluida la información del repositorio de código fuente, como la anterior.

Brian Agnew
fuente
3
Me gusta ackmucho, pero he encontrado que es sustancialmente más lento que find -type f -name "*.[ch]" | xargs grepcuando se trata de una gran base de código.
John Ledbetter
63
John, soy el autor de ack, y si puedes darme detalles de los problemas de velocidad de ack vs. grep, te lo agradecería. Han sido completamente comparables en todos los casos que he encontrado. Hágamelo saber en github.com/petdance/ack/issues o envíeme un correo electrónico a andy en petdance.com. Thansk
Andy Lester
63
Chicos, eso es un consejo, ¡pero definitivamente no es una respuesta a la pregunta! :)
dolzenko
8
¿No se ackfactura como mejor grep, no como fuente consciente find? Algunos ejemplos de su uso para reemplazar findharían de esto una respuesta real.
michiakig
3
Es una respuesta a la pregunta que no sabía que estaba haciendo. =)
Frungi
293

por qué no solo

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

El predicado -not niega todo lo que tiene .svn en cualquier parte de la ruta.

Entonces en tu caso sería

find -not -iwholename '*.svn*' -name 'messages.*' -exec grep -Iw uint {} + \;
Whaley
fuente
55
Súper grande +1 para "-not" y "-iwholename". Ack es maravilloso y lo uso, pero find / exec todavía tiene sus usos.
David Blevins
99
La única respuesta que realmente respondió la pregunta original.
Brendon Crawford
14
Estoy fuera de mi elemento y estoy seguro de que me criticarán por este comentario, pero aparentemente -no y -nombre completo no son compatibles con POSIX. Solía ​​! en lugar de -not y -path en lugar de -iwholename y obtuve los mismos resultados. Según mis páginas de manual (Ubuntu 12.04), esta sintaxis es compatible con POSIX.
John
1
@whaley Dijiste '*.svn*'al principio pero luego '*.svn'. ¿Lo cual está bien? ¿Ambos funcionan? Creo que probablemente debería ser '*.svn*'?
Keith M
1
@KeithM gran captura en realidad. Esta respuesta ha estado aquí durante años y no creo que nadie haya captado eso hasta ahora.
Whaley
141

Como sigue:

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

O, alternativamente, basado en un directorio y no en un prefijo de ruta:

find . -name .svn -a -type d -prune -o -print
Kaleb Pederson
fuente
14
@Kaleb: Hola. Sugiero find . -type d -name .svn -prune -o -printporque es un poco más rápido. Según el estándar POSIX , las expresiones se evalúan una por una, en el orden especificado. Si la primera expresión en -aes false, la segunda expresión no será evaluada (también llamada cortocircuito y evaluación ).
Siu Ching Pong -Asuka Kenji-
2
@Kaleb: como comparar el tipo de archivo (equivalente a probar si un bit está configurado en un entero) es más rápido que comparar el nombre de archivo (equivalente a una comparación de cadena, que es O (n)), poner -type dantes -name .svnes teóricamente más eficiente. Sin embargo, generalmente es insignificante, excepto si tiene un árbol de directorios muy grande.
Siu Ching Pong -Asuka Kenji-
55
@ SiuChingPong-AsukaKenji- no, comparar solo el nombre del archivo es más rápido porque -type requiere una llamada stat (2) en cada archivo. El nombre de archivo, sin embargo, es parte de la respuesta readdir (3).
hraban
3
@ JonathanHartley Te estás perdiendo el -printcomo parte de la última expresión. Algo así find . -name .git -prune -o \( -type f -name LICENSE -print \)funciona como se esperaba.
sschuberth
1
Si desea ignorar tanto .git y .svn y simplemente enumerar los otros directorios, find . -name .svn -prune -o -name .git -prune -o -type d -print. Puede ser unos pocos milisegundos más rápido -type dantes de los dos -name, pero no vale la pena escribir más.
JPaget
34

Para ignorar .svn, .gity otros directorios ocultos (comenzando con un punto), intente:

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

Sin embargo, si el propósito de usar findes buscar dentro de los archivos, puede intentar usar estos comandos:

  • git grep - comando especialmente diseñado para buscar patrones dentro del repositorio de Git.
  • ripgrep- que por defecto ignora los archivos ocultos y los archivos especificados en .gitignore.

Relacionado: ¿Cómo encuentro todos los archivos que contienen texto específico en Linux?

kenorb
fuente
La mejor respuesta imo. Los otros tratan de explicar cosas que no responden a la simple pregunta.
Anthony
19

Esto es lo que haría en su caso:

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

El rgrepcomando incorporado de Emacs ignora el .svndirectorio, y muchos más archivos que probablemente no le interesen al realizar un find | grep. Esto es lo que usa por defecto:

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

Ignora los directorios creados por la mayoría de los sistemas de control de versiones, así como los archivos generados para muchos lenguajes de programación. Puede crear un alias que invoque este comando y reemplazar findy greppatrones para sus problemas específicos.

Antoine
fuente
12

GNU encontrar

find .  ! -regex ".*[/]\.svn[/]?.*"
ghostdog74
fuente
Estaba cargando las rutas del directorio en una matriz para que PHP las procesara. Las otras respuestas más arriba (por cualquier razón) no filtraron los archivos en el hallazgo (a pesar de -type d), esta respuesta sí. +1
be hollenbeck
11

Yo uso grep para este propósito. Pon esto en tu ~ / .bashrc

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

grep usa automáticamente estas opciones en la invocación

Ronny Brendel
fuente
1
Vale la pena señalar que 'grep' solo obtuvo la opción '--exclude-dir' hace uno o dos años. Las distribuciones recientes de Linux lo incluyen, pero si recuerdo correctamente, tuve que compilar mi propio grep (o pedirle a homebrew que lo haga) en OSX.
Jonathan Hartley
Yo uso una variante menor de esto. Mi .bashrc crea una función Bash 'grp', que se define como GREP_OPTIONS=xxx grep "$@". Esto significa que la variable GREP_OPTIONS solo se establece para instancias de grep que ejecuto manualmente usando 'grp'. Esto significa que nunca tengo una situación en la que ejecuto una herramienta, e internamente se llama grep, pero la herramienta se confunde porque grep no se comporta como esperaba. Además, tengo una segunda función 'grpy', que llama 'grp', pero agrega --include=*.py, solo para buscar archivos de Python.
Jonathan Hartley
En realidad, al reflexionar, hacerlo a mi manera ya no necesita usar GREP_OPTIONS. Ahora solo tengo una función de shell 'grp' que llama grep --exclude=tags --exclude_dir=.git ...etc... "$@". Me gusta que esto funcione como 'ack', pero conservo conciencia y control sobre lo que está haciendo.
Jonathan Hartley
9

find . | grep -v \.svn

yo.
fuente
Tienes que escapar .en la .svnexpresión regular.
vladr
44
Use --fixed-strings con grep: | fgrep -v /.svn/o `| grep -F -v / .svn / `para excluir exactamente el directorio y no los archivos con" .svn "como parte de su nombre.
Stephen P
8

¿Por qué no canaliza su comando con grep, que es fácilmente comprensible?

your find command| grep -v '\.svn'
Vijay
fuente
Tienes que escapar .en la .svnexpresión regular.
vladr
@Yclian sin la menor duda; si no lo hace, los directorios llamados 'tsvn', '1svn', 'asvn', etc., también serán ignorados desde '.' es un comodín regexp: 'coincide con cualquier personaje'.
vladr
Muy bien, pensé que solo sucedería para el caso de -E y -G. Acabo de probar, mi mal. :(
yclian
2
Me gusta esta respuesta porque es conceptualmente más simple que todas las demás. No puedo recordar la sintaxis ridícula para el uso de 'encontrar', pero definitivamente puedo recordar cómo usar grep -v ya que se usa en muchas situaciones.
mattismyname
8

Crea un script llamado ~/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

Este script se comporta de manera idéntica a un findcomando simple pero elimina .svndirectorios. De lo contrario, el comportamiento es idéntico.

Ejemplo:

# 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;
John Kugelman
fuente
Este script no funciona como lo esperaría. Al ejecutarlo con "svnfind -type f", también imprime directorios svn y los archivos en los directorios svn
Ingo Fischer
@ifischer ¿Puede agregar un echocomando de búsqueda y decirme qué comando se ejecuta? svnfind -type ffunciona muy bien en mi máquina Red Hat.
John Kugelman
Ok, entonces parece ser dependiente del sistema operativo. Estoy ejecutando Debian Squeeze (es lo mismo en Ubuntu). No entiendo lo que quieres decir con "agregar un eco"?
Ingo Fischer
@ifischer Cambie la última línea para echo find "${OPTIONS[@]}"...que imprima el comando de búsqueda en lugar de ejecutarlo realmente.
John Kugelman
Ok cambió la última línea a echo find ${OPTIONS[@]} ${PATHS[@]} -name .svn -type d -prune -o ( ${EXPR[@]} ) $ACTION, Esto me da el siguiente resultado:find -type f -name .svn -type d -prune -o ( -true ) -print
Ingo Fischer
5

Solo pensé que agregaría una alternativa simple a las publicaciones de Kaleb y de otros (que detalla el uso de la find -pruneopción ack, repofindcomandos , etc.) que es particularmente aplicable al uso que ha descrito en la pregunta (y cualquier otro uso similar):

  1. Para el rendimiento, siempre debe intentar usar find ... -exec grep ... +(gracias Kenji por señalar esto) o find ... | xargs egrep ...(portátil) o find ... -print0 | xargs -0 egrep ...(GNU; funciona en nombres de archivos que contienen espacios) en lugar de find ... -exec grep ... \;.

    El formulario find ... -exec ... +y find | xargsno se bifurca egreppara cada archivo, sino para un montón de archivos a la vez, lo que resulta en una ejecución mucho más rápida .

  2. Al usar el find | xargsformulario, también puede usarlo greppara podar fácil y rápidamente .svn(o cualquier directorio o expresión regular), es decir find ... -print0 | grep -v '/\.svn' | xargs -0 egrep ...(útil cuando necesita algo rápido y no puede molestarse en recordar cómo configurar findla -prunelógica).

    El find | grep | xargsenfoque es similar a findla -regexopción de GNU (vea ghostdog74la publicación de), pero es más portátil (también funcionará en plataformas donde GNU findno está disponible).

vladr
fuente
1
@Vlad: Tenga en cuenta que hay dos formas para el -execcambio find: una termina con ;y la otra termina con +. El que termina con +reemplaza {}por una lista de todos los archivos coincidentes. Además, tu expresión regular también '/\.svn'coincide con los nombres de los archivos '.svn.txt'. Consulte mis comentarios a la pregunta para obtener más información.
Siu Ching Pong -Asuka Kenji-
2
@Vlad: Aquí está el estándar POSIX para la findutilidad. Por favor vea la -execparte :-).
Siu Ching Pong -Asuka Kenji-
4

En un repositorio de código fuente, generalmente quiero hacer cosas solo con los archivos de texto.

La primera línea son todos los archivos, excepto los archivos de repositorio CVS, SVN y GIT.

La segunda línea excluye todos los archivos binarios.

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
rickfoosusa
fuente
3

Yo uso find con las opciones -not -path. No he tenido buena suerte con la ciruela pasa.

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

encontrará los archivos geniales que no están en la ruta del directorio de destino.

scott m gardner
fuente
3

Para resolver este problema, simplemente puede usar esta condición de búsqueda:

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

Puede agregar más restricciones como esta:

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

Puede encontrar más información sobre esto en la sección de la página de manual "Operadores": http://unixhelp.ed.ac.uk/CGI/man-cgi?find

Código fuente
fuente
3

Tenga en cuenta que si lo hace

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

entonces -printestá implícito cuando toda la expresión ( -type f -name 'messages.*') es verdadera, porque no hay 'acción' (como -exec).

Mientras que, para dejar de descender a ciertos directorios, debe usar cualquier cosa que coincida con esos directorios y seguirlo -prune(que tiene la intención de dejar de descender a directorios); al igual que:

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

Esto se evalúa como Verdadero para los directorios .svn, y podemos usar un cortocircuito booleano siguiendo esto por -o(OR), después de lo cual lo que sigue después de -oque solo se verifica cuando la primera parte es Falso, por lo tanto, no es un directorio .svn. En otras palabras, lo siguiente:

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

solo evaluará lo que es correcto de -o, es decir -name 'message.*' -exec grep -Iw uint {}, para archivos que NO estén dentro de directorios .svn.

Tenga en cuenta que debido a que .svnes probable que siempre sea un directorio (y no, por ejemplo, un archivo), y en este caso ciertamente no coincide con el nombre 'mensaje. *', También podría omitir el -type dy hacer:

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

Finalmente, tenga en cuenta que si omite alguna acción ( -execes una acción), diga así:

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

entonces la -printacción está implícita pero se aplicará a la expresión ENTERA, incluida la -name '.svn' -prune -oparte, y así imprimirá todos los directorios .svn, así como los archivos 'mensaje. *', que probablemente no sea lo que desea. Por lo tanto, siempre debe usar una 'acción' en el lado derecho de la expresión booleana cuando se usa -prunede esta manera. Y cuando se imprime esa acción, debe agregarla explícitamente, así:

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

Carlo Wood
fuente
2

Pruebe findrepo, que es un contenedor simple alrededor de find / grep y mucho más rápido que ack. Lo usaría en este caso como:

findrepo uint 'messages.*'
pixelbeat
fuente
2

wcfind es un script de derivador de búsqueda que uso para eliminar automáticamente directorios .svn.

leedm777
fuente
1

Esto funciona para mí en el indicador de Unix

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

El comando anterior enumerará ARCHIVOS que no están con .svn y hará el grep que mencionó.

Felix
fuente
¿Es 'gfind' un error tipográfico? No lo tengo en Ubuntu 14.04.
Jonathan Hartley
Suponiendo que quisieras decir 'encontrar', esto no funciona del todo. También filtra archivos como xxx.svnxxx. Esto es importante: por ejemplo, si está usando git en lugar de svn, a menudo querrá incluir archivos como .gitignore (que no son metadatos, es un archivo normal que se incluye en el repositorio) en los resultados de find.
Jonathan Hartley
1

Por lo general, canalizo la salida a través de grep una vez más eliminando .svn, en mi uso no es mucho más lento. ejemplo típico:

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

O

find . -type f -print0 | xargs -0 egrep messages. | grep -Ev '.svn|.git|.anythingElseIwannaIgnore'
geminiimatt
fuente