Grâce à la mise à jour d'anniversaire, BASH est désormais installé sur Ubuntu sous Windows 10. Auparavant, j'utilisais Cygwin et j'avais installé Maven dans Cygwin (et je l'ai complètement utilisé), qui consistait principalement à installer Maven, puis à modifier mon PATHenvironnement. variable (en ~/.bashrc)

Eh bien, j'essaie de faire la même chose en utilisant BUW, mais pour autant que je sache, la PATHvariable est ignorée (l'ajout du répertoire Maven bin à la PATH, puis l'exécution which mvnrenvoie des valeurs vides). Y a-t-il un truc qui me manque ou dois-je configurer mon système PATHdifféremment dans BUW?

MODIFIER:

Laissez-moi être spécifique. Que dois-je faire dans le "???" étape pour obtenir pathTestScript.sh sur le chemin?

mkdir -p ~/pathTest
touch ~/pathTest/pathTestScript.sh
echo '#!/bin/sh' >> ~/pathTest/pathTestScript.sh
echo 'echo "it works!"' >> ~/pathTest/pathTestScript.sh
bash ~/pathTest/pathTestScript.sh
    # Should output 'it works!'
# ?????????
pathTestScript.sh
    # Should output it works!'

EDIT 2:

Je veux être très clair avec mon objectif final. JDK et Apache Maven sont installés sur mon système aux endroits habituels. Les deux fonctionnaient parfaitement bien à Cygwin. Maintenant que BUW est sorti, je veux plutôt les utiliser là-dedans, mais je ne peux pas comprendre comment configurer mon environnement pour eux, car les modifications que je modifie dans PATH ne semblent pas avoir d'effet.

EDIT 3:

Ok, maintenant je suis inquiet, je suis sur une chasse à l'oie sauvage. Si je le fais echo $PATH, je reçois/mnt/c/Program\ Files/apache-maven-3.3.9/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

C'est ce que j'attends. C’est ce que j’ai mis dans mon ~/.bashrcdossier ... alors je le fais ls /mnt/c/Program\ Files/apache-maven-3.3.9/binet j’obtiens

m2.conf  mvn  mvn.cmd  mvnDebug  mvnDebug.cmd  mvnyjp

Mais quand je le fais which mvn, je suis vide et si j'appelle mvn, je suis redirigé pour l'utiliser apt-getpour l'installer.

Le problème n'est donc pas que le PATH n'est pas mis à jour, il est simplement ignoré. Y a-t-il un moyen de le faire prêter attention au PATH? Sinon, c'est une version assez faible de Linux (IMO)

EDIT 4:

Il a été évoqué à plusieurs reprises et, oui, mon exemple giflé a oublié de marquer le fichier comme étant exécutable. Dans mon scénario réel (avec Maven), les fichiers sont tous exécutables:

cd /mnt/c/Program\ Files/apache-maven-3.3.9/bin && ls -alt
total 36
dr-xr-xr-x 2 root root    0 Apr 19 11:56 ..
-r-xr-xr-x 1 root root 1843 Apr 19 11:56 mvnyjp
dr-xr-xr-x 2 root root    0 Apr 19 11:56 .
-r-xr-xr-x 1 root root 1815 Apr 19 11:56 mvnDebug
-r-xr-xr-x 1 root root 7383 Apr 19 11:56 mvn
-r-xr-xr-x 1 root root 1513 Apr 19 11:56 mvnDebug.cmd
-r-xr-xr-x 1 root root 6067 Apr 19 11:56 mvn.cmd
-r-xr-xr-x 1 root root  230 Apr 19 11:56 m2.conf

Résumé de la mise à jour

Les exécutables en question ne sont pas au format Linux natif (ELF), ils sont compilés pour Windows. Au cours de l’extension du chemin, bash vérifie le nombre magique du binaire; s’il ne correspond pas à ELF, il ne l’expose pas via l’extension du chemin. Cependant, bash pour Windows incluait la possibilité de lancer des applications Windows natives à partir de l'environnement bash, ce qui explique pourquoi l'exécution directe (sans extension de chemin et vérification binaire ultérieure) fonctionne correctement.

La résolution est soit un ajout .bashrc basé sur un alias (soit un nombre quelconque de méthodes alternatives pour imiter l’extension de chemin, évitant ainsi l’évaluation du fichier bash) ou l’installation de la version linux.

Réponse originale

Autorisations de fichier

C'est peut-être un problème d'autorisations de fichiers croisés. Si vous cd /mnt/c/Program\ Files/apache-maven-3.3.9/binet essayez de courir mvn comme ça, ./mvnque se passe-t-il?

Quelle est la sortie de ls -altdans ce répertoire?

Si le fichier n'est pas correctement marqué comme exécutable, il n'apparaîtra pas comme un «programme» sur votre chemin. S'il s'agit d'un fichier binaire et non au format 'linux' (ELF), il ne s'affichera pas non plus comme un chemin exécutable.

Si l'exécution directe de mvn ne fonctionne pas (veuillez poster les résultats de ls), essayez d'ajouter des autorisations d'exécution. chmod ug+x mvn

Mauvaise version installée

Etes-vous sûr d'avoir la version native de linux installée - la même version que celle que vous avez utilisée avec cygwin ne fonctionnera presque certainement pas.

Vous pouvez vérifier la compatibilité binaire avec sudo apt-get install elf-binutils ensuite sur le fichier mvn, utilisez la commande readelf -a mvn Si vous obtenez une erreur telle que "Ce n'est pas un fichier ELF ...", alors vous avez votre réponse.

Je viens de remarquer que vous n'avez pas ajouté d'autorisations d'exécution au script de shell de test dans votre exemple, ce qui (sauf si vous avez simplement oublié de répertorier l'étape) explique complètement cet échec.

Sommaire:

1. Assurez-vous que les exécutables du répertoire maven bin sont correctement définis comme exécutables à l'aide de chmod. Affichez la sortie de ls -alt dans votre réponse.
2. Assurez-vous d'avoir un binaire Linux - utilisez l'utilitaire readty pour vérifier.
3. Exécutez votre test de script shell à nouveau, mais cette fois marque le fichier exécutable.

Mise à jour

Le problème de la voie était un hareng rouge; vous essayez simplement d'exécuter un format binaire incompatible avec l'environnement Linux sous Windows.

En surface, les deux environnements (cygwin et bash sur Windows) offrent une expérience utilisateur quelque peu similaire, mais la mise en œuvre et la compatibilité binaire qui en résulte sont très différentes.

Conclusion: les formats binaires Cygwin et Linux ne sont pas compatibles. Vous devez installer la version native de Linux pour l'exécuter à partir de bash sous Windows. Vous pouvez également le compiler à partir des sources dans l'environnement bash sous Windows; mais en raison de la nature «précoce» de l'environnement, je m'inquiétais de la recherche de dépendances.

Brève description des deux environnements:

Cygwin est en réalité une couche de traduction qui fournit une API pour les appels système qui ne sont généralement pas disponibles sur des systèmes non POSIX, ce qui vous permet de compiler de nombreux programmes conçus pour être exécutés sous Linux dans l’environnement Windows. Cependant, il fonctionne toujours dans un environnement "Windows" - ce binaire ne fonctionnera plus que dans l'environnement cygwin sous Windows. Cette couche de traduction et les bibliothèques associées permettent au code source écrit avec l'API Linux d'être compilé dans l'environnement cygwin et exécuté sur Windows. Les binaires construits de cette manière ne fonctionneront pas sous Linux ou Windows de manière native. uniquement dans l'environnement cygwin.

L'environnement bash sur les fenêtres fournies par canonique est très différent de celui de cygwin. En fait, il "recrée" un environnement pour un programme qui semble être réellement Linux - c'est-à-dire que les bibliothèques standard sont disponibles avec les appels système POSIX - sans nécessiter de modification des fichiers binaires. Dans de nombreux cas, un fichier binaire construit contre Ubuntu peut être copié directement sur l'environnement bash sous Windows et s'exécuter sans problème.

Pour être reconnu comme un exécutable valide dans bash sous Windows, il doit être au format binaire linux natif ou dans un fichier de script marqué avec le programme permettant de l’interpréter (pour un script bash, #! / Bin / bash). Un binaire linux natif aura été construit contre les bibliothèques Linux et les appels système. Bash confirme que quelque chose est un exécutable valide en vérifiant les bits d'autorisation de l'exécutable et en vérifiant que le format du fichier binaire est compatible (vérification du «nombre magique»). S'il s'agit d'un fichier binaire et qu'il n'est pas au format ELF, il n'est pas exposé au shell via une extension de chemin.

Pour rendre ce problème plus difficile à clarifier, ils ont ajouté une possibilité partielle de lancer des applications Windows natives à partir de bash sur Windows, mais ils ne se sont clairement pas occupés de la vérification du format de fichier binaire du chemin d’expansion de Bash - ou ils l’ont fait et c’est un bogue.

Deuxième édition:

Clarification sur votre question:

Lorsque vous le lancez directement (./mvn), il contourne l'évaluation Bash et ne l'exécute que. Le bash sur l’environnement Windows est suffisamment intelligent pour lancer les exécutables natifs de Windows, ce qui doit être. Je ne crois pas qu'un binaire cygwin se lancerait correctement à partir de bash, mais je peux me tromper - la documentation est insuffisante à ce stade et je ne dispose pas d'un environnement de test accessible pour le moment.

Solution de contournement offrant une capacité équivalente à la prise en charge de «chemin»:

Si vous êtes entièrement satisfait de l’installation de maven (pas d’autres problèmes de compatibilité, tout marche bien), mais l’avoir sur le chemin est important, vous pouvez utiliser une solution de contournement simple qui fournira une capacité équivalente.

Dans votre fichier .bashrc, ajoutez l'alias suivant:

alias mvn='/mnt/c/Program\ Files/apache-maven-3.3.9/bin/mvn'

Répétez l'équivalent pour tous les autres exécutables de ce répertoire auxquels vous souhaitez accéder, où que vous soyez dans l'environnement bash sous Windows.

redémarrez bash ou le fichier source, puis mvnfonctionnera à partir de n’importe quel répertoire (en fonction de votre déclaration indiquant que l’exécution directe depuis le répertoire bin, ./mvn, fonctionnait).

Essayez echo 'PATH="~/pathTest/:$PATH"' > ~/.bash_path(n'importe quel nom que vous voulez)

source ~/.bash_path

echo $PATH pour voir si quelque chose change

chmod +x ~/pathTest/pathTestScript.sh Pour l'exécuter directement, vous devez ajouter le droit d'exécution au fichier.

pathTestScript.sh

Si cela fonctionne, ajoutez simplement la ligne source ~/.bash_pathen vous ~/.bashrc.

Pouvez-vous invoquer par /mnt/c/Program\ Files/apache-maven-3.3.9/bin/mvn?

Comme il est basé sur Ubuntu, le fichier PATH réel est " /etc/environment" (ne montre pas le type de fichier).

$ nano /etc/environmentest le moyen le plus simple de modifier le fichier. Vous verrez quelque chose comme ça:

PATH = "/ usr / local / sbin: / usr / local / bin: / usr / sbin: / usr / bin: / sbin: / bin: / usr / games: / usr / local / games"

Vous pouvez ajouter le répertoire que vous avez choisi avant les guillemets de fin, après le dernier répertoire, avec un :(deux-points) supplémentaire à délimiter du répertoire précédent.

Enfin, vous devez exécuter le fichier " /etc/environment"; ceci peut être accompli en tapant:

$ . /etc/environment

J'ai couru ces dans $ sudo -set vérifié avec $ env. Je suis un peu confiant que la commande env devrait afficher les modifications immédiates, et un redémarrage devrait le compléter une fois les modifications sélectionnées effectuées.