Pourquoi ne fonctionne pas?

J'ai donc exécuté la commande find / .bash_profilepour voir s'il existait n'importe où sur mon Mac avant d'en créer un. La recherche sur l’ensemble de l’ordinateur prend évidemment une minute, je voulais donc l’exécuter en arrière-plan (quelque chose que je n’ai jamais essayé de faire auparavant) et j’en ai ajouté un &à la fin, comme suit:find / .bash_profile &

Cependant, au lieu de l'exécuter en arrière-plan et de me laisser faire d'autres tâches, cela a simplement rendu le processus ininterruptible! Il continuait à courir au premier plan mais Ctrl+ Cn'avait plus d'effet; il ne pouvait être arrêté qu'en fermant entièrement l'instance de terminal.

Qu'est-ce que j'oublie ici?

macos bash find

— nom_utilisateur_temporel
source

Ctl-c n'a eu aucun effet car il fonctionnait en arrière-plan. Les interruptions du clavier n'affectent que le travail de premier plan.

— Barmar le

Si vous utilisez un Mac, pourquoi utilisez-vous à la findplace de Spotlight?

— Barmar

@Barmar - parce que la ligne de commande est l'interface utilisateur

— PROPER

Si vous vouliez le mettre en pause ou le casser alors qu'il fonctionnait en arrière-plan (ce qui a été le cas, malgré l'envoi de sortie au terminal), envoyez un kill (-1 HUP pour arrêter ou suspendre / reprendre. Voir kill -l). Vous pouvez également le ramener au premier plan avec fgou fg %jobnumber(voir jobs), puis Control-C ou Control-Z.

— Hennes

Si vous souhaitez effectuer cette opération fréquemment et que vous ne souhaitez pas utiliser Spotlight, vous pouvez activer cette fonctionnalité locate, puis l'utiliser locate .bash_profile. Si vous essayez cette commande maintenant, elle vous dira comment l'activer de manière permanente.

— Barmar

Réponses:

En effet, il fonctionne en arrière-plan et vous pouvez faire d'autres choses, mais chaque fois qu'il émet quelque chose, il émet vers votre terminal actuel.

Suggestion: find / -name .bash_profile >my_result.txt 2>/dev/null &

Cela enregistre la sortie dans un fichier et supprime toutes les erreurs (telles que l'erreur d'autorisation refusée). Vous pouvez vérifier l'état en jetant un coup d'œil dans le fichier de sortie tail my_result.txtou en le saisissant jobs.

Si vous devez supprimer le travail, tapez kill %1où 1 est le numéro du travail jobs.

— Alex
source

Deux autres choses intéressantes à ajouter éventuellement au message: 1) queue - option f) 2) le ramener au premier plan et le tuer à cet endroit ( fg control-c). +1 pour mentionner également stderr.

— Hennes

C'est quoi 2>? Je ne sais pas comment ça s'appelle, donc je ne sais pas comment le rechercher sur Google.

— temporary_user_name

@Aerovistae: 2est stderr, abréviation d'erreur standard. 2>/dev/nullsignifie que les erreurs sont redirigées vers/dev/null

— Alex

Merci! Logique. J'ai aussi trouvé un moyen de regarder. Je ne sais pas ce que 0>ferait bien .... réoriente apparemment stdin .... que je croyais à utiliser<

— temporary_user_name

@Aerovistae: Voir TLDP sur la redirection des entrées / sorties

— Alex

Êtes-vous sûr que le processus était au premier plan? Ce n’est pas parce qu’il écrit en sortie que le terminal est au premier plan.

Si vous avez une commande qui produit une sortie et que vous voulez l'exécuter en arrière-plan, vous devez rediriger la sortie comme suit:

find / -name .bash_profile > find_results &

Il est normal que le processus d'arrière-plan soit immunisé contre les interruptions ( Ctrl+ C). Vous pouvez donc interrompre votre travail de premier plan sans interférer avec le ou les travaux d'arrière-plan. (Notez, BTW, que vous avez mal compris la commande.)

— G-Man
source

Vous avez trébuché sur une bête noire avec find. Essayez d'utiliser l' -printoption comme ça

find / -name '.bash_profile' -print > some_file

Vous pouvez également être confronté à un problème en évitant d’échapper ou de ne citer que le point dans le nom du fichier. findprend en charge la syntaxe RegEx afin que point dans le nom du fichier puisse être mal interprété. L’un des exemples ci-dessous devrait résoudre ce problème.

find / -name 'some_file.txt' ...

find / -name some_file\.txt ...

Les guillemets simples sont plus souples car vous n’avez pas à échapper à chaque caractère de contrôle et vous pouvez plus facilement envelopper des caractères comme @ ou /

— SaxDaddy
source

(2) Bien qu'il soit judicieux de citer des chaînes constantes et essentiel de citer des chaînes contenant des caractères spéciaux (ou d'échapper aux caractères spéciaux), le point (c'est-à-dire un point, c'est-à-dire .) n'est pas un caractère spécial dans ce contexte. find … -namene traite pas son argument comme un RegEx à part entière (voir -regex) et ne traite donc pas .comme spécial. Même si elle a fait (par exemple, si nous avons parlé -regex), citant la chaîne ou échapper le caractère ne serait pas question; vous auriez besoin d'échapper au caractère et de citer la chaîne. Et de quoi parles-tu @et /?

— G-Man le

(1) Quelle est la bête noire? Pourquoi croyez-vous que dire -printexplicitement fait une différence? C'est l'action par défaut ("expression").

— G-Man

Je suppose que c’est une bête noire parce que j’aurais écrit cela pour que "imprimer" soit le comportement implicite par défaut. Et bien que la recherche ne traite pas un point dans le contexte d'expression régulière, il peut être interprété de manière erronée comme étant le répertoire actuel. J'ai également eu des problèmes avec le besoin d'être échappé bien qu'un exemple m'échappe ironiquement.

— SaxDaddy