Vous n'êtes pas identifié(e).
j'aimerais pouvoir faire une alias ou un script ou je ne sais quoi qui ferait que taper:
me donne le même résultat.
Comment m'y prendre ?
Merci d'avance pour vos lumières et bonne journée
Dernière modification par Blacksad (25-08-2012 16:43:43)
Hors ligne
et ajoutes y la ligne suivante :
ou $1 sera le mot recherché
Alors là j'ai répondu à ta question (je pense )
Maintenant, pourquoi ne fais tu pas plus simple ET plus rapide à l'exécution ?
(sachant que le i permet d'ignorer la casse)
J'espère t'avoir aidé...
Dernière modification par twigg (24-08-2012 09:55:11)
Hors ligne
À mettre par exemple dans un fichier ~/.local/bin/cherche rendu exécutable, avec « ~/.local/bin » dans ton PATH.
L'avantage de cette méthode est que la syntaxe n'est pas dépendante du shell utilisateur, de plus, ça marche aussi pour des scripts écrits dans d'autres langages comme le python ou le perl. Par contre, c'est un peu plus lourd à mettre en place.
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Dans le cas du find, pourquoi ajouter -name "*" ?
Il me semble que ne rien mettre va aussi bien.
Hors ligne
Hors ligne
grep --color -nri $1 ../*
ne trouvera jamais rien dans un fichier caché ( commençant par un . , exemple : .vimrc ) parce que l'étoile ne remplace jamais le "."
Oui :
Dans le cas du find, pourquoi ajouter -name "*" ?
C'est vrai, name en l'occurence ne sert à rien, et parfois il faudra écrire :
pour atteindre les fichiers pointés par les liens symboliques, parce que ce n'est pas le comportement par défaut de find que de suivre les liens symboliques ...
C'est pourquoi, perso je préfère find, mais je suis peut-être moins flemmard que Blacksad ?
Edit : @ Blacksad
Sinon tu a Ctrl+r dans un terminal habituel qui te donne :
(reverse-i-search)`':
Tu écris les premiers mots de find et il te trouve vite fait la dernière cde find que tu as utilisé, si tu veux aller plus loin dans l'historique, tu refais Ctrl+r, et tu as l'occurence suivante de find en (reverse-i-search)`':
C'est circulaire.
r du Ctrl-r, c'est pour "reverse"
C'est bien commode Ctrl+r !
Dernière modification par tinux (29-08-2012 07:34:49)
tinux
------------------
Tour: Stretch Gnu / Linux / CM : Gygabite B75M-D3V Rev2 / Intel i5-3570 @ 3.40GHz Socket 1155 / 8 Gib RAM / HD 1Tib + HD sauvegarde 1Tib / VGA Intel Corp. Xeon E3-1200 / Portable: Acer Aspire One 725 / Jessie / AMD C-60 APU CG Radeon
Hors ligne
Hors ligne
Hors ligne
Ok, ça marche, maintenant je cache le fichier :
Impec, ça marche toujours, maintenant je déplace le fichier dans le rep suivant, et je crée un lien symbolique caché vers ce fichié lui même caché dans /home/seb ( j'ai tous les droits d'accés et tout et tout )
Enfin je demande une recherche de ce texte 'un trés grand secret'
Ben il ne le trouve plus ! Bon faut dire que c'est un peu compliqué !
Find trouve encore, à condition de limiter la recherche à un niveau de rep : ( sinon je pense qu'il finirait par trouver, mais dans trois plombes )
Bon c'est compliqué, ça n'enlève rien à l'intérêt de ack-grep bien sûr ! merci pour la commande que je ne connaissais pas du tout,
Salut :-)
tinux
------------------
Tour: Stretch Gnu / Linux / CM : Gygabite B75M-D3V Rev2 / Intel i5-3570 @ 3.40GHz Socket 1155 / 8 Gib RAM / HD 1Tib + HD sauvegarde 1Tib / VGA Intel Corp. Xeon E3-1200 / Portable: Acer Aspire One 725 / Jessie / AMD C-60 APU CG Radeon
Hors ligne
Hors ligne
Un vrai perfectionniste le Tinux
Le perfectionnisme : autant un défaut qu'une qualité ...
Pour ack-grep, peut-etre que les développeurs utilisent pas trop de fichiers cachés ou de liens dans des dossiers de code source ?
Et du coup un outil pour eux ne cherche pas ça ? (je n'y connais rien)
Moi non plus j'y connais rien, apparemment ça ne les intéresse pas, il doivent savoir où sont planqués certains fichiers bizaroïdes ( oui, un lien caché vers un fichier lui même caché qui se trouve dans un rep qui est lui même un lien symbolique qui se trouve dans un rep chiffré avec eCryptfs, c'est chelou comme truc, mais j'aime bien tout trouver, et en plus j'y arrive pas tjours ... ...
Pour find ca marche comment ?
Dans le man je crois que ton -L dit de suivre les liens, et maxdepth 1ca ne fouille que le dossier courant. Du coup si il voit un lien il va quand même aller voir le fichier pointé alors qu'il est pas dans le dossier courant ?
Oui, c'est ça, il considère que le fichier pointé par le lien fait parti du dossier courant ( -maxdepth 1 ), ce qui me parait normal en fait . Bon find est usine à gaz : on es d'accord là dessus je suis loin de la maîtriser cette cde mais je voulais juste souligner que ack-grep laisse passer des choses et il vaut mieux le savoir !!! : en l'occurrence il a laissé passer 'un trés grand secret', ce qui est con !
Mais ack-grep a beaucoup d'options, alors mef ...
De toute façon comme je compte me mettre à Perl, /usr/bin/ack-grep m'intéresse, même si c'est pas le premier que je vais étudier pour débuter ( dirvish avant tout )
Bon je vais souffrir ! c'est clair !!!
J'ai pas trop le temps d'interagir sur le forum, mais c'est tjs un plaisir d'approfondir la connaissance des cdes avec vous
tinux
------------------
Tour: Stretch Gnu / Linux / CM : Gygabite B75M-D3V Rev2 / Intel i5-3570 @ 3.40GHz Socket 1155 / 8 Gib RAM / HD 1Tib + HD sauvegarde 1Tib / VGA Intel Corp. Xeon E3-1200 / Portable: Acer Aspire One 725 / Jessie / AMD C-60 APU CG Radeon
Hors ligne
Hors ligne
Ça doit-être un pb de FuxBB, la barbe ! Pastebin ne fonctione pas chez moi, on dirait un pb python, je lâche l'affaire, autre choses à faire justement que d'attendre 3 plombes, pas envie de me prendre le choux avec ça ce soir !
tinux
------------------
Tour: Stretch Gnu / Linux / CM : Gygabite B75M-D3V Rev2 / Intel i5-3570 @ 3.40GHz Socket 1155 / 8 Gib RAM / HD 1Tib + HD sauvegarde 1Tib / VGA Intel Corp. Xeon E3-1200 / Portable: Acer Aspire One 725 / Jessie / AMD C-60 APU CG Radeon
Hors ligne
Effectivement, ack-grep est un outil basé sur perl, et sa puissance n'est plus à démontrer.
De plus, la connaissance des REGEX est quasi indispensable.
@+
Zoroastre.
Hors ligne
Yep!
Essayes :ack-grep -a --follow 'un trés grand'
Effectivement, ack-grep est un outil basé sur perl, et sa puissance n'est plus à démontrer.
De plus, la connaissance des REGEX est quasi indispensable.
@+
Zoroastre.
J'avais déjà essayé ça mais ça cherche pendant trois plombes pour un fichier qui se trouve seulement dans ~/seb/.fichier.txt, alors ...
j'avais même essayé
pareil ..., bon j'ai pas que ça à faire, sérieux !
C'est pas grave, l'essentiel est de s'en sortir !
tinux
------------------
Tour: Stretch Gnu / Linux / CM : Gygabite B75M-D3V Rev2 / Intel i5-3570 @ 3.40GHz Socket 1155 / 8 Gib RAM / HD 1Tib + HD sauvegarde 1Tib / VGA Intel Corp. Xeon E3-1200 / Portable: Acer Aspire One 725 / Jessie / AMD C-60 APU CG Radeon
Hors ligne
Hors ligne
Yep!
Certes, ack-grep est parfois long, trés long, bien plus qu'un simple grep par exemple.
C'est un outil qui a certains avantages.
Pourquoi tu ne passes pas à perl directement alors ?
@+
Zoroastre.
Ben c'est ce que je disais, il me faut passer à Perl, mais pour le moment quand je cherche des trucs j'utilise find, Perl c'est pour comprendre pourquoi chez moi drivish ne fonctionne pas entièrement ( dirvish-runall par exemple, et je fais plein de trucs en manuel (heureusement dirvish tout court fonctionne, mais c'est galère, j'ai été obligé de modifier le script dirvish-cronjob de /etc/cron.daily, pour le moment ça va c'est sur mon propre sys, mais sur un sys de production, non, ça pas question de me passer de runall et de faire l'amateur du Dimanche surtout pour les sauvegardes ! ...)
Alors à l'attaque de Perl ( j'ai du job !!!!! ) sniff
tinux
------------------
Tour: Stretch Gnu / Linux / CM : Gygabite B75M-D3V Rev2 / Intel i5-3570 @ 3.40GHz Socket 1155 / 8 Gib RAM / HD 1Tib + HD sauvegarde 1Tib / VGA Intel Corp. Xeon E3-1200 / Portable: Acer Aspire One 725 / Jessie / AMD C-60 APU CG Radeon
Hors ligne
Vide ta messagerie Tinux, je peux même pas t'envoyer des messages pour t'embeter.
Misère !
http://images.debian-facile.org/file-Rf … cac8622678
tinux
------------------
Tour: Stretch Gnu / Linux / CM : Gygabite B75M-D3V Rev2 / Intel i5-3570 @ 3.40GHz Socket 1155 / 8 Gib RAM / HD 1Tib + HD sauvegarde 1Tib / VGA Intel Corp. Xeon E3-1200 / Portable: Acer Aspire One 725 / Jessie / AMD C-60 APU CG Radeon
Hors ligne
Hors ligne
Salut,
Ce que j'ai lu plus haut est juste, par contregrep --color -nri $1 ../*
ne trouvera jamais rien dans un fichier caché ( commençant par un . , exemple : .vimrc ) parce que l'étoile ne remplace jamais le "."
Mais finalement, je crois que même avec l'*, grep fouille bien les fichiers cachés.
Hors ligne
C'est ce qui a été dit au début du sujet; mais il y a eu un doute sur les fichiers cachés au post #6.
tinux a écrit :Salut,
Ce que j'ai lu plus haut est juste, par contregrep --color -nri $1 ../*
ne trouvera jamais rien dans un fichier caché ( commençant par un . , exemple : .vimrc ) parce que l'étoile ne remplace jamais le "."
Mais finalement, je crois que même avec l'*, grep fouille bien les fichiers cachés.
Non ! en fait grep n'est pas le problème, c'est le motif de recherche qui ne va pas. Exemple :
Je suis dans mon rep d'accueil, je crée un rep essais pour faire des essais justement :
Le rep essais est bien vide, je crée des fichiers normaux et des fichiers cachés :
tu peux voir que dans le 1er cas le shell a substitué * par fichier1 fichier2 fichier3 puis a exécuté la commande echo, tout bêtement, alors que dans le second il a d'abord cherché tout ce qui commençait par '.' et a trouvé les fichiers cachés puis a bêtement exécuté la cde echo, ce que je trouve bizarre c'est qu'il trouve '..' dans ce cas ?, alors que find n'aurai jamais trouvé '..' ce que je trouve normal :
Voilà, il faut toujours faire des essais pour vérifier par l'expérience ... héhéhé
Bon ça suffit avec ça hein ?
tinux
------------------
Tour: Stretch Gnu / Linux / CM : Gygabite B75M-D3V Rev2 / Intel i5-3570 @ 3.40GHz Socket 1155 / 8 Gib RAM / HD 1Tib + HD sauvegarde 1Tib / VGA Intel Corp. Xeon E3-1200 / Portable: Acer Aspire One 725 / Jessie / AMD C-60 APU CG Radeon
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
En tout cas, c'est un post plein de richesses sur l'execution de diverses commandes, la solution passe après, merci à vous.
Oui faut jouer avec les cdes, tiens, par exemples :
tout est dans le motif:P
tinux
------------------
Tour: Stretch Gnu / Linux / CM : Gygabite B75M-D3V Rev2 / Intel i5-3570 @ 3.40GHz Socket 1155 / 8 Gib RAM / HD 1Tib + HD sauvegarde 1Tib / VGA Intel Corp. Xeon E3-1200 / Portable: Acer Aspire One 725 / Jessie / AMD C-60 APU CG Radeon
Hors ligne
Oui Twigg, grep seul semble plus simple.
-H est inutile.
../* pour chercher dans le dossier parent.
--color en bonus.
#!/bin/sh
grep --color -nri $1 ../*
Dans le cas du find, pourquoi ajouter -name "*" ?
Il me semble que ne rien mettre va aussi bien.
Je plussoie, c'est ce que je fais depuis qqs temps pour chercher des occurences dans plusieurs fichier ; c'est très efficace :
Je me place dans le repertoire où je veux commencer cette recherche :
et lance cette simple ligne de commande
Qui fera exactement le même boulot demandé en introduction de ce sujet
En fait grep -nri c'est pas beaucoup plus compliqué que "cherche" donc faire un script a pas trop d'utilité pour le coup.
Sur ce coup, oui, je le pense aussi
Dernière modification par Invité-2 (07-09-2013 22:46:09)