Ce que je crois comprendre c’est que lorsque que l’utilisateur envoie son BREAK (avec Ctrl+c) c’est d’abord la redirection qui se termine, puis le cat
Cela ne se passe pas ainsi.
Quand on a tapé une commande sans redirection et qu'on presse entrée, le shell effectue d'abord un appel système fork() (man 2 fork), ce qui clone le processus du shell, sa mémoire, ses descripteurs de fichiers (dont stdin, stdout et stderr) et l'endroit où il en est dans le programme.
Ensuite, le shell original se contente d'attendre la fin du nouveau processus.
Pendant ce temps, le sous processus (qui est encore un shell) effectue l'appel système execve (man 2 execve) qui charge un nouveau programme et remplace tout le processus par ce nouveau programme (en l'occurence, la commande tapée par l'utilisateur). Le nouveau programme va alors utiliser les mêmes stdin, stdout et stderr que son parent, à savoir, le terminal.
Une fois l'appel execve fait, le sous-processus n'exécute plus du tout un shell et ses entrées sorties ne sont donc plus contrôlées par le shell. À moins que cat lui-même ne décide de changer ses entrées/sorties standard, il écrira vers le terminal.
Si la commande tapée contenait une redirection, la séquence est à peu près la même, à part qu'après le fork(), le sous-processus (qui est encore un shell), va rediriger sa propre sortie standard (et seulement la sienne) vers un fichier avant de faire le execve : le sous-processus du shell va ouvrir le fichier demandé (et quitter si le fichier ne peut être ouvert, sans faire execve), puis faire la redirection avec l'appel dup2 (man 2 dup2). Ainsi, quand il appellera execve, cat écrira vers le fichier quand il écrira vers sa sortie standard, au lieu du terminal.
Aussi, comme pour le cas précédent, après execve, le shell n'aura plus la main sur le processus cat.
En bref, il n'est pas possible pour le shell de "stopper la redirection" d'un autre processus.
Je pense que nous n'avons pas la commande exacte tapée par DaVi, comme le dit le fil précédent.
[^] # Re: Séquence d'échappement
Posté par BFG . En réponse au message J'adore Debian et autres ; bug rigolo. Évalué à 2.
Cela ne se passe pas ainsi.
Quand on a tapé une commande sans redirection et qu'on presse entrée, le shell effectue d'abord un appel système
fork()(man 2 fork), ce qui clone le processus du shell, sa mémoire, ses descripteurs de fichiers (dontstdin,stdoutetstderr) et l'endroit où il en est dans le programme.Ensuite, le shell original se contente d'attendre la fin du nouveau processus.
Pendant ce temps, le sous processus (qui est encore un shell) effectue l'appel système
execve(man 2 execve) qui charge un nouveau programme et remplace tout le processus par ce nouveau programme (en l'occurence, la commande tapée par l'utilisateur). Le nouveau programme va alors utiliser les mêmesstdin,stdoutetstderrque son parent, à savoir, le terminal.Une fois l'appel
execvefait, le sous-processus n'exécute plus du tout un shell et ses entrées sorties ne sont donc plus contrôlées par le shell. À moins quecatlui-même ne décide de changer ses entrées/sorties standard, il écrira vers le terminal.Si la commande tapée contenait une redirection, la séquence est à peu près la même, à part qu'après le
fork(), le sous-processus (qui est encore un shell), va rediriger sa propre sortie standard (et seulement la sienne) vers un fichier avant de faire leexecve: le sous-processus du shell va ouvrir le fichier demandé (et quitter si le fichier ne peut être ouvert, sans faireexecve), puis faire la redirection avec l'appeldup2(man 2 dup2). Ainsi, quand il appelleraexecve,catécrira vers le fichier quand il écrira vers sa sortie standard, au lieu du terminal.Aussi, comme pour le cas précédent, après
execve, le shell n'aura plus la main sur le processuscat.En bref, il n'est pas possible pour le shell de "stopper la redirection" d'un autre processus.
Je pense que nous n'avons pas la commande exacte tapée par DaVi, comme le dit le fil précédent.