Ceci n'est pas une tartine
☟
Pour ajouter aux remarques de Jean
quelques petites gloses touffues (destinées à enduire de confiture rhétorique ses austères canapés linuxiens
) =>
- a) il y a un inconvénient à lancer un processus de copie via le
Finder (par un glisser-déposer d'un élément du volume de l'OS dans l'espace d'un disque externe, par exemple) : c'est que cette tâche déterminée ne donne pas lieu à un processus indépendant de celui du
Finder, mais se trouve "enveloppée" (
wrapped) dans le processus générique du
Finder.
Il est facile de s'en apercevoir en lançant une copie via le
Finder, puis en allant à :
Applications/Utilitaires pour lancer le «
Moniteur d'Activité», qui est une interface graphique permettant d'inspecter les différents processus en cours d'activité et de récupérer les informations afférantes, comme par exemple le
% de processeur (
CPU) consommé ou le fameux
PID (
Process_IDentifier :
IDentifiant numérique de
Processus). On s'aperçoit tout de suite que le processus de copie en cours n'est pas identifié comme un processus spécifique & isolé (par exemple un
cp), mais reste englobé dans le processus enveloppant du
Finder dont le
% de consommation du
CPU se montre accru.
Ce constat a une conséquence sur la problématique de la suspension éventuelle de ce processus de copie. En effet, s'il s'était agi d'un processus absolument spécifique indépendant du processus enveloppant du
Finder (comme de lancer l'utilitaire
cp dans l'interface du «
Terminal), alors il aurait été aisé de geler momentanément l'activité de se processus (suspension), quitte à le reprendre ensuite - ce par l'intermédiaire de commandes supplémentaires dans le «
Terminal». Mais, dès lors qu'il s'agit d'un processus de copie "enveloppé" (
wrapped) dans le processus générique du
Finder et pas exporté isolément hors de lui (comme un
cp local), alors il n'est pas possible de suspendre ce processus autrement qu'en suspendant... le processus global du
Finder. Ce qui n'a rien de commode pour l'utilisateur, car le
Finder se trouve alors gelé, ce qui stoppe la capacité de navigation graphique. Ou, sinon, dans le panneau de progression de la tâche de copie en cours affiché par le
Finder, la seule possibilité offerte étant de supprimer l'opération en cours.
En conséquence de ces considérations : un utilisateur qui envisage une tâche de copie très lourde, qu'il serait opportun de suspendre à un point donné histoire de laisser refroidir la machine par exemple, aurait dans ce cas avantage à lancer l'opération en ligne de commande dans le «
Terminal», afin qu'il s'agisse d'un processus isolé spécifique susceptible d'être manipulé par une commande de suspension, et pas d'une opération enveloppée dans le processus générique du
Finder.
--------------------
- b) pour ce qui est d'une tâche lancée via l'interface textuelle du «
Terminal», si aucune précaution n'a été prise d'entrée (genre passation simple d'une commande
cp sans l'esperluette
& en bout de commande), alors le processus lancé bloque dans la fenêtre ouverte du «
Terminal» le ré-affichage de l'invite de commande, ce qui ne permet pas de passer directement une commande
kill -STOP PID telle que préconisée par
Jean.
Il est bien sûr possible d'ouvrir en parallèle un nouvel onglet permettant de récupérer le
prompt, afin de passer la commande, mais je trouve qu'afin de ne pas disperser un même traitement entre plusieurs espaces d'affichage, il serait plus direct de faire simplement un
ctrl Z au clavier, ce qui a un effet triple : renvoi de l'opération (
cp ici) en tâche de fond (
background), suspension concomitante du processus, et récupération du
prompt. La mention automatique :
[x]+ Stopped indiquant l'état suspendu de la tâche, ainsi que son n° spécifique de processus de tâche de fond (le
[x] qui n'est pas son
PID, mais son n° de rang dans les tâches d'arrière-plan, genre
[1] si c'est là la première tâche renvoyée en coulisses).
À partir de là, un simple :
bg %x (comme
background où
x est le n° précité de rang dans les tâches d'arrière-plan) relance le processus tout en le laissant en arrière-plan, ce qui permet de récupérer le
prompt ; sinon, un
fg %x (comme
foreground) permettrait de relancer le processus en le ramenant à l'avant-plan, avec l'inconvénient de revoler le
prompt, mais l'intérêt pratique de savoir à coup sûr que le processus est toujours en train de s'effectuer (
running) tant que l'invite de commande ne s'est pas réaffichée en signal de complétion. Sinon, à laisser la tâche en arrière-plan (
background) pour permettre la récupération du
prompt, il faut par exemple s'informer par un
jobs occasionnel de l'état des lieux...
--------------------
Note personnelle : j'ai fini par délaisser totalement le Finder d'OS X au profit de «PathFinder» que j'utilise en lieu et place de Finder. L'avantage procuré dans le cas qui fait l'objet de ce fil (une opération de recopie lancée en mode graphique) est que le panneau de «PathFinder» affichant la progression de la tâche comporte non le seul bouton de suppression (comme dans le panneau du Finder), mais aussi un bouton de suspension - ce qui évite de passer a priori par le «Terminal» quand on anticipe la nécessité d'une suspension de tâche de copie en cours d'exécution...