Honnêtement, j'ai voté pour le bash.exe réponse après l'avoir parcouru trop rapidement, avant de réaliser qu'il recommandait (l'obsolète) bash.exe . Je vais donc fournir ce que j'espère être une "meilleure réponse".
Notez que bash.exe est répertorié par Microsoft comme un "commandement historique" ce qui, à mon avis, est juste un cran au-dessus de "déprécié".
Actuellement, le la manière recommandée de lancer une instance WSL est avec le wsl.exe (ou simplement wsl lorsqu'il est appelé depuis PowerShell, CMD, ou scripts sous l'un ou l'autre des interpréteurs). Par exemple (en utilisant l'option bash.exe exemples de la question précédente) :
Étant donné un fichier /mnt/c/Temp/your_script.sh (défini comme exécutable, bien sûr) contenant :
#!/usr/bin/env bash
echo Hello
cd /home
pwd
Puis wsl -e "/mnt/c/Temp/your_script.sh" (dans PowerShell) exécuterait ce fichier et aurait pour résultat :
Hello
/home
El -e (également --exec ) à wsl exécute la commande qui suit. comme le Shell par défaut. S wsl -e ls ferait une liste de répertoire sans jamais invoquer bash (ou même sh ).
La méthode shebang-in-a-script est une façon d'exécuter les commandes sur bash mais vous pouvez également invoquer une commande (ou des commandes) comme :
wsl -e bash -c "echo Hello; cd /home; pwd"
Notez, cependant, que :
echo "echo Hello; cd /home; pwd" | wsl
Will no fonctionnent, du moins dans PowerShell, puisque PowerShell a la fâcheuse "fonctionnalité" d'ajouter un retour chariot ( \r ) à toute sortie canalisée vers un exécutable de la console tel que wsl.exe .
Parmi les autres caractéristiques, wsl.exe peut aussi :
- Lancer ou exécuter une commande dans une instance WSL différente, si vous avez installé plus d'une distribution ou instance (par ex.
wsl -d kali )
- Lancez ou exécutez une commande en tant qu'utilisateur différent sans mot de passe (par ex.
wsl -u root visudo )
