Pourquoi utiliser "Cmd/c Powershell" au lieu de "Powershell"?
J'ai ajouté mon premier menu contextuel à l'aide du registre, conformément aux instructions données dans cette question (yay me).
A l'origine, je l'utilisais comme commande à exécuter, c'est-à-dire la valeur de la touche "commande":
Cmd /C Powershell "imageSeqView --% \"%1\""
ImageSeqView est le nom de ma fonction powershell, je l'importe dans mon profil powershell. Cela fonctionne bien, mais je me demande: pourquoi utiliser cmd pour ouvrir Powershell pour exécuter la fonction? Ne serait-il pas plus simple de simplement faire
Powershell "imageSeqView --% \"%1\""
Cette commande semble bien fonctionner, mais comme il semble canonique d'utiliser cmd, je me demande s'il s'agit de tuer secrètement des chiots ou quelque chose du genre.
Il n'y a pas de bonne raison de faire ça. En fait, le seul effet réel qui se produise est de ralentir les choses.
Les gens pourraient penser qu'il y a une bonne raison de le faire. L'utilisation de CMD a les effets suivants, qui peuvent généralement être bons dans certains cas:
- Active les commandes internes, telles que "
DIR" - Définit les variables d'environnement, telles que la variable PATH
Cependant, dans ce cas, aucun de ces avantages n’est acquis. Regardons ces deux scénarios:
Ainsi, il peut parfois arriver que l’utilisation de "CMD /C" soit utile. Par exemple, si j'utilise la commande externe PSEXEC (téléchargée à partir de SysInternals) et que j'essaie d'exécuter "DIR" sur un ordinateur distant, Windows tentera alors d'exécuter la commande "DIR". Windows ne pourra pas exécuter cette commande car il n'y a pas de fichier "DIR.EXE", "DIR.BAT" ou "DIR" se terminant par une autre extension prise en charge. (Les extensions prises en charge sont visibles en exécutant "ECHO %PATHEXT%".)
Toutefois, dans ce scénario, si j'essaie d'exécuter "CMD /C DIR", cela fonctionnera, car Windows recherchera un exécutable nommé "CMD" et le trouvera. CMD finira par exécuter la commande "DIR". qui est une partie interne de la commande "CMD".
Dans ce cas, vous pouvez simplement exécuter powershell aussi facilement que "CMD /C powershell", afin de ne tirer aucun avantage du "CMD /C" inutile. Le seul avantage que je vois à franchir l'étape supplémentaire consistant à taper "CMD /C" est de fournir un exemple qui sera utile si quelqu'un décide d'essayer de modifier un exemple pour exécuter une ligne de commande "DIR" ou "COPY". Avoir un exemple plus flexible peut être utile pour certaines personnes. Ce n'est vraiment pas nécessaire quand les gens savent ce qu'ils font.
En ce qui concerne le deuxième point que j'ai fourni, qui consiste à définir les variables d'environnement, vous ne le faites pas activement dans ce cas particulier. Certaines personnes pensent peut-être qu'elles aident les choses en provoquant la définition de la variable d'environnement PATH. Toutefois, lorsque vous exécutez des commandes directement (par exemple, à partir de l'option de menu "Exécuter" du menu Démarrer), le système d'exploitation Windows peut rechercher des commandes à des emplacements supplémentaires. Par exemple, sous Windows XP/newer, vous pouvez exécuter:
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths"
Si la commande que vous souhaitez exécuter est répertoriée sous "Chemins de l'application", Windows peut trouver le programme même s'il ne se trouve pas dans le chemin. Ainsi, Windows est susceptible de trouver encore plus que ce que CMD trouverait dans le PATH utilisé par CMD.
Un avantage possible est que si vous souhaitez exécuter CMD de manière à pouvoir faire référence à une variable d’environnement telle que% USERPROFILE% ou% LOGONSERVER% ou% TEMP% /% TMP%, mais comme vous ne le faites pas, vous ne le faites pas. avoir besoin d'exécuter "CMD /C".
Donc, pour votre cas particulier: Il n'y a aucune bonne raison de le faire. Les effets que vous obtenez sont de faire en sorte que votre ordinateur travaille plus, ralentissant le processus et utilisant plus de mémoire (ce que vous faites avec des quantités négligeables sur un équipement moderne).
Parce qu'il se débarrasse de la coloration.
Peut-être pensent-ils que les gens trouvent le fond bleu dérangeant.
Avec cmd powershell, vous demandez au shell actuel, Explorer, d’appeler cmd avec les paramètres powershell, "imageSeqView ..." avec la valeur analysée de% 1 à cmd.
Dans ce cas, cmd s'attend à ce que "powershell" soit une commande cmd, un fichier exe ou l'un des scripts pris en charge par cmd, par exemple. chauve souris.
Avec powershell "imageSeqView ...", vous demandez au shell en cours, Explorer, d’appeler powershell avec les paramètres imageSeqView ... avec la valeur analysée de% 1 dans powershell.
Dans ce cas, PowerShell s'attend à ce que "imageSeqView" soit une applet de commande, un script exe ou un script PowerShell.
À condition que "imageSeqView" soit une fonction powershell, la 1ère voie est totalement inutile et réduit légèrement les performances.
Pour les options de la fenêtre de commande, il existe des options similaires dans powershell, telles que -NoExit, qui devraient être identiques à/K dans cmd.
PowerShell peut faire de même.