Alternative à trouver? [fermé]

30

Existe-t-il un findprogramme alternatif avec une interface CLI plus conventionnelle? findfonctionne et attend les paramètres d'une manière douloureusement différente de la plupart des autres utilitaires.

Clarification: je recherche un programme qui a principalement les mêmes fonctionnalités que find avec une interface de ligne de commande qui fonctionne et ressemble aux recommandations de ligne de commande POSIX (ou au moins GNU).

— Tamás Szelei
source

7

GNU find ne respecte pas les directives POSIX (ou même GNU) pour la ligne de commande. Par exemple, l'ordre des paramètres, les options à plusieurs caractères avec un seul tiret, etc. sont différents de ceux des programmes conformes.

— Tamás Szelei

3

Je sais, et je peux toujours faire ce que je veux, d'une manière ou d'une autre. Récemment, j'ai appris à connaître acket je me demandais s'il y avait aussi un meilleur find.

— Tamás Szelei

2

Non. Vous voyez, je ne veux pas d'un petit langage de programmation, mais d'une recherche plus simple, plus intuitive et plus cohérente (même si cela signifie la perte de certaines fonctionnalités avancées). Quand je fais face à une tâche qui justifie l'écriture d'un programme, je le fais.

— Tamás Szelei

2

la recherche est à la fois cohérente (voir ma réponse) et intuitive. Ce n'est pas comme si les primaires étaient nommées bizarres. -exec signifie exécuter, -print signifie l'imprimer, -name signifie correspondre à un nom. En pratique, les anciens 3 et -types couvrent 95% des cas d'utilisation. Pour tous les autres cas, il y a l'homme à trouver.

— Mel

3

@tamas J'ai édité il y a une heure et je vous ai dit qu'il n'y avait pas d'autre choix que de localiser. Et peut-être que ls -R y pense. D'autres alternatives sont des programmes GUI qui émulent find. Sinon, vous devez spécifier ce que vous voulez que votre alternative de recherche fasse. Marcher dans les arbres? Filtrer les noms de fichiers? Dites-vous alors quels fichiers sont les plus récents?

— Mel

11

Il s'agit d'une idée fausse courante.

Find suit la syntaxe des options. Vous confondez simplement les expressions primaires avec des options:

 find [-H | -L | -P] [-EXdsx] [-f path] path ... [expression]
 [cmd][-->        options          <--] [--> arg0..argN  <--]

L'alternative est de localiser. Mais find implémente sa propre syntaxe d'expression car elle fournit un ensemble plus riche d'options de filtrage et d'action. Il n'y a pas d'alternative qui puisse faire la même chose, simplement parce que ce serait redondant.

— Mel
source

5

Même si c'est ma faute, cela ne répond pas à ma question.

— Tamás Szelei

Quelle est la différence entre l'expression (une seule autorisée?), Cmd (dito?), Les options et les arguments?

— utilisateur inconnu

@user unknown - la commande find implémente sa propre syntaxe d'expression. L'expression, lorsqu'elle est donnée, est le dernier argument de la ligne de commande. Lorsqu'elle est absente, l'expression se résout en -print.

— Mel

Ah - maintenant je vois, [cmd] ne suit pas [expression], mais c'est une description de la ligne précédente.

— utilisateur inconnu

2

OP affirme que find"attend les paramètres d'une manière douloureusement différente de la plupart des autres utilitaires". Vous indiquez que OP "confond les expressions primaires avec des options". La plupart des autres utils ont-ils même un concept de "primaires d'expression"? Sinon, cela ne démontre- t-il pas le point d'OP? Et ce n'est vraiment pas la partie la plus étrange de l'utilisation find. Quelles autres CLI impliquent {}(lesquelles doivent bien sûr être échappées d'une manière ou d'une autre)?

— Kyle Strand

10

Cela dépend de la fonctionnalité précise finddont vous dépendez. S'il s'agit (principalement) de la fonction de recherche, certains shells prennent en charge les globs récursifs. Par exemple, avec zsh:

% find . -name \*c
./a/b/foo.c
./a/bar.c
./baz.c
inoshiro% ls *.c
baz.c
% ls **/*.c 
a/bar.c  a/b/foo.c  baz.c

Zsh a beaucoup plus de possibilités de recherche grâce aux qualificatifs glob (regardez vers la fin de man zshexpn). Par exemple:

ls -l **/*(.) ≈ find -type f -ls
ls *(m-2u:$USER:) ≈ find -mtime -2 -user $USER

Bash 4 a également **/(vous devez l'activer avec shopt -s globstar), mais rien de tel que les qualificatifs glob.

— jmtd
source

10

Je voudrais jeter un oeil à locate. Il parcourra sa base de données de fichiers et imprimera rapidement les noms de chemin correspondant à ce que vous donnez.

kevin@box:~$ locate odg
/home/kevin/Documents/final.odg
/usr/share/doc/packages/sysconfig/netconfig.odg
/usr/share/gimp/2.0/help/en/gimp-tool-dodge-burn.html
....
kevin@box:~$ locate .odg
/home/kevin/Documents/final.odg
/usr/share/doc/packages/sysconfig/netconfig.odg
kevin@box:~$

Comme vous pouvez le voir, c'est une correspondance de sous-texte: si vous la donnez odg, alors elle correspondra à d odg e. Mais si vous le donnez .odg, ce ne sera pas le cas.

Il y a cependant un inconvénient: il a besoin d'une base de données. Cette base de données doit être mise à jour lorsque les choses changent. Mon installation de Fedora 13 a cependant mis cela dans une crontab quotidienne.

— Kevin M
source

J'adorelocate

— Andrew Lambert

1

De plus, Locate accepte également les modèles (je l'ai appris récemment).

— Adam Byrtek

5

Qu'essayez-vous de trouver? Si vous recherchez généralement des fichiers de code source, jetez un œil à ack. Il s'agit essentiellement d'un outil de recherche de code source, mais le -fcommutateur ack trouvera les fichiers correspondant à un type de fichier donné.

Donc, si vous voulez trouver tous les fichiers Perl dans un répertoire, par exemple, juste:

ack -f --perl

Si vous n'aimez pas les types de fichiers reconnus par ack, vous pouvez ajouter les vôtres dans votre ~/.ackrc.

ack n'est pas un outil de recherche de fichiers à usage général find, mais si vous travaillez avec du code source, cela peut être très pratique.

— Andy Lester
source

1

Ce n'est pas ce que l'utilisateur a demandé, mais les gens pourraient trouver très utile de trouver dans le code source (comme grep) The Silver Searcher , silversearcher-agpackage sur les principales distributions.

— Pablo A

-1

Une des grandes choses que chaque programmeur doit apprendre est: si vous ne trouvez pas d'outil, construisez le vôtre!

#!/usr/bin/bash
find -name $<

Je pourrais en écrire un meilleur, avec -tdes types de filtres, etc.

Edit : Ce qui précède est un script Bash. Il prend l'argument de ligne de commande et le transmet pour rechercher la valeur de l'option -name. Juste un exemple simple. Depuis que j'ai mis cette réponse, j'ai trouvé ce script python:

https://github.com/sjl/friendly-find/

L'interface a l'air sympa, mais je n'ai pas testé ses performances. Ça vaut peut-être la peine de vérifier.

— xixixao
source

1

Vrai pour construire sa propre déclaration d'outil. Mais expliquez au moins comment votre petit script est censé fonctionner.

— jippie

1

$<ne fait rien d'utile dans mon Bash. Qu'attendez-vous qu'il fasse? Tu veux dire en "$@"fait? Ou "$1"(ce qui est essentiellement ce que cela signifie dans un Makefile)?

— tripleee

1

@tripleee - $<est l' cshéquivalent de read- je suppose qu'il voulait dire cela.

— DarkHeart

-2

La façon la plus standard de trouver des choses dans Unix.

du -a <directory>|grep <pattern>| awk  '{print $2}'

— johny smith
source

1

grep | awkest un contre-modèle. Voir utilisation inutile degrep . Si vous voulez paramétrer le motif, peutdu -a | awk -v "pat=<pattern>" '$0 ~ pat { print $2 }'

— tripleee

@tripleee Ce sont des informations très utiles awk, mais l'un des grands avantages de la philosophie UNIX est qu'il n'est pas nécessaire de comprendre toutes les fonctionnalités des outils les plus complexes (tels que awket find) pour construire des pipelines capables de réaliser les performances souhaitées. tâche. grep | awkpeut ne pas être optimal (ou, sur un système multithread performant avec un système hautement optimisé grep, ce serait peut-être le cas!), mais c'est simple .

— Kyle Strand