Que fait-il exactement si je clique dans la fenêtre de cmd?

Supposons que j'exécute cmd.exe et envoie un ping à l'hôte local. Après cela, je cogne à nouveau localhost mais je clique dans la fenêtre et le ping s’arrête jusqu’à ce que j’appuie sur entrée .

Que se passe-t-il exactement quand je clique dans la fenêtre? Est-ce qu'il suspend le processus ou quelque chose d'autre? J'ai joint une capture d'écran pour clarifier ce problème.

Remarque: je ne clique pas, mais glisse en utilisant la souris, ce qui crée une zone blanche dans la fenêtre, comme vous pouvez le voir sur la capture d'écran.

Edit: plus de précision: Ce que je veux vraiment savoir, c'est si le fait de faire glisser la fenêtre interrompt le processus cmd ou non?

Éditer: encore plus de précisions: je sais que j'utilise Édition rapide et que vous appuyez sur Entrée pour copier le contenu que j'ai sélectionné. Ce que je ne sais pas, c'est ce qui se passe en arrière-plan.

Lorsque vous sélectionnez du texte dans la fenêtre cmd.exe, le processus se poursuit en arrière-plan jusqu'à la prochaine fois qu'il écrit dans la sortie standard (ou STDOUT, le flux de données affiché dans la fenêtre cmd.exe).

Lorsque vous quittez le mode de sélection, le processus reprend normalement.

Vous pouvez tester cela en tapant ping www.google.com -tdans votre fenêtre cmd.exe et en sélectionnant une zone de la sortie. Vous verrez une pause et lorsque vous désélectionnez, la sortie reprendra.

Edit: Selon le commentaire de Fran, vous pouvez utiliser un outil tel que Wireshark pour voir que l'activité se produit toujours après le point où vous avez effectué la sélection, puis s'arrête.

Une fois que vous avez cliqué dans la fenêtre d'invite de commande, l'hôte de la console n'autorisera plus l'écriture de la sortie. L’application elle-même continue de fonctionner, mais rien n’est écrit à l’écran.

Bien sûr, tant qu’il n’ya qu’un seul thread, c’est fondamentalement la même chose que de voir votre processus gelé. Comme le thread unique essaie d'écrire une sortie avant de faire plus de travail.

Si je lance ping -t localhostet clique dans la fenêtre d'invite de commande, je peux alors inspecter la pile d'appels du ping.exethread principal avec Process Explorer .

Nous pouvons voir que ping.exeessayé d’écrire une sortie. Il a appelé write()dans la bibliothèque d'exécution C. Cette fonction, à un moment donné, appelle GetConsoleMode . Il semble que cette fonction vérifie si l'utilisateur est actuellement en mode marque et bloque l'exécution si nécessaire.

Analyse plus approfondie

Nous pouvons prouver davantage ce comportement en examinant le comportement de pingavec Wireshark

Lors de l'exécution, ping -t superuser.comnous voyons la sortie suivante dans Wireshark:

Maintenant, marquons une case dans l'invite de commande.

Soudain, plus de pings ne sont enregistrés dans Wireshark. pingn'envoie plus de paquets.

Mais nous savions déjà que ...

Bon, voyons si le résultat est réellement le problème ici! Dirigeons la sortie vers le NULpériphérique:

Maintenant, il n'y a plus de sortie. Nous pouvons maintenant marquer du texte dans la boîte toute la journée, les paquets seront enregistrés dans Wireshark.

C'est parce que la fenêtre est entrée en mode Marque. Lorsque vous appuyez sur Entrée, le texte sélectionné est copié dans le Presse-papiers. À ma connaissance, il n'y a pas de paramètre pour cela, donc je ne suis pas sûr de savoir pourquoi cela se produit lorsque vous cliquez simplement dans la fenêtre. Normalement, vous devez faire un clic droit et cliquer sur "Mark". Assurez-vous qu'aucune touche n'est bloquée sur votre clavier.

Votre fenêtre CMD est en mode d'édition rapide qui entre automatiquement en mode d'édition lorsque vous cliquez sur l'écran. L'entrée sert à copier le texte dans la case blanche et à quitter le mode édition.

Normalement, CMD n’entre en mode édition que lorsque vous cliquez avec le bouton droit de la souris sur l’écran noir et choisissez Marquer.

Pour revenir à la normale, cliquez avec le bouton droit sur la barre de titre des fenêtres et choisissez Propriétés, sélectionnez l'onglet Options et désélectionnez "Mode d'édition rapide", puis cliquez sur OK.

Lorsque vous sélectionnez le texte à copier à partir de la fenêtre (en Markmode), le système suspend le processus en cours dans cette fenêtre.

Exemple de fichier batch:

:test
echo %0
goto test

lorsque cela est exécuté, dès que je marque la zone à copier, l'écran cesse de défiler

Comme tout le monde l’a si bien fait remarquer, la progression de la sortie supplémentaire est bloquée pendant l’opération de marquage. De plus, vous pouvez quitter le mode Marquer et copier la sélection marquée dans le tampon de collage de Windows, soit en cliquant avec le bouton gauche de la souris (clic droit par défaut) ou en appuyant sur la touche Entrée. Une autre solution consiste à appuyer sur la touche Échap pour abandonner le marquage d'une zone d'écran et libérer le bloc en sortie. Cela suppose que le mode QuickEdit est sélectionné dans les propriétés de cette fenêtre de commande. Vous pouvez également entrer plus délibérément dans cette situation en indiquant à la fenêtre de commande que vous souhaitez sélectionner du texte.

Pour corroborer davantage l'affirmation selon laquelle le processus est suspendu en "mode Marque", par exemple lors d'un clic de souris ou d'un glissement à l'intérieur des bordures de la fenêtre cmd.exe, mais arrête toute opération uniquement après avoir complètement terminé l'instance en cours, j'offre une preuve indirecte:

[1378:000f][2018-10-08T13:26:20] END: Verifying package "AndroidEmulator,version=26.0.0.2"
[1378:000f][2018-10-08T13:26:20] BEGIN: Verifying package "AndroidImage_ARM_API23,version=20.0.0.3"
[1378:000f][2018-10-08T13:26:20] Verifying package 'AndroidImage_ARM_API23,version=20.0.0.3'
[1378:000c][2018-10-08T13:26:26] SHA256 verification for 'AndroidImage_x86_API23,version=20.0.0.3\x86-23_r20.zip' succeeded. Hash: X
[1378:0025][2018-10-08T14:09:03] BEGIN: Verifying "AndroidImage_ARM_API23,version=20.0.0.3\AndroidSDKPrivateInstall.ps1"
[1378:0012][2018-10-08T14:09:03] BEGIN: Verifying "AndroidImage_ARM_API23,version=20.0.0.3\armeabi-v7a-23_r20.zip"
[1378:0012][2018-10-08T14:09:03] Authenticode verification returned 0x800b0003 for path: AndroidImage_ARM_API23,version=20.0.0.3\armeabi-v7a-23_r20.zip.
[1378:0012][2018-10-08T14:09:03] Retrying validation for: AndroidImage_ARM_API23,version=20.0.0.3\armeabi-v7a-23_r20.zip
[1378:000c][2018-10-08T14:09:03] Authenticode verification returned 0x800b0003 for path: AndroidImage_x86_API23,version=20.0.0.3\x86-23_r20.zip.

Vous consultez le flux de journalisation d'une installation Visual Studio où l'utilitaire de ligne de commande de l'installation de Visual Studio vérifie tous les workloads installés.

À 13:26:26, j'ai cliqué sur l'intérieur de la fenêtre d'invite de commande. La sortie vers l’écran s’arrête jusqu’à 14:09:03 quand j’aurai appuyé sur Entrée pour quitter le "Mode marque".

Maintenant, remarquez qu'après 13:26:26, le processus termine pour vérifier le hachage x86-23_r20.zip, le message "a réussi. Hachage: X " et redémarre avec un autre fichier à 14:09:03, le message " DEBUT: Vérification" [..] AndroidSDKPrivateInstall.ps1 "

Au cours de la pause, l'utilitaire de ligne de commande de Visual Studio Setup a terminé la vérification du fichier en cours de traitement et, au moment exact où le contrôle devait être renvoyé à la console, a démarré une nouvelle tâche de vérification du hachage.