j'essaie -- encore -- de traduire un *.bat en *.zsh et j'avais qqc du
genre :
export CLASSPATH=/path/to/*.jar:$CLASSPATH
java ne trouve pas une classe, ce que j'ai du faire (donc sans la
wildcard "*") :
export
CLASSPATH=/path/to/fichier1.jar[...]:/path/to/fichierN.jar:$CLASSPATH
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
guillaume.outters
Yvon Thoraval wrote:
export CLASSPATH=/path/to/*.jar:$CLASSPATH java ne trouve pas une classe, ce que j'ai du faire (donc sans la wildcard "*") : export CLASSPATH=/path/to/fichier1.jar[...]:/path/to/fichierN.jar:$CLASSPATH
Ce que ça fait: un ls sur tous les .jar, qui (man ls) s'il est pipé, sort un nom par ligne. On récupère donc ça et on remplace (tr) chaque fin de ligne (caractère 12 en octal) par deux points. On en récupère le résultat pour préfixer le CLASSPATH actuel.
Sous DOS, j'ai l'impression que chaque commande gère son * comme il veut. Peut-être l'affectation de CLASSPATH se débrouille-t-elle pour que les fichiers correspondants à *.jar soient séparés par un point-virgule. Mais sous Unix, la philosophie étant "chacun fait peu, mais bien", c'est le shell qui fait l'expansion sans se soucier de qui va en recevoir le résultat: il mettra toujours des espaces entre les résultats. Mais la philosophie aidant, on finira toujours par trouver un outil faisant (bien) ce qu'on a à faire.
La solution n'est pas optimale, car notre 'tr' ne distingue pas un retour à la ligne envoyé par ls pour séparer deux entrée, de celui contenu dans un nom de fichier. Le cas est cependant assez rare (je crois que les fichier Icon affectant un icone à un dossier en ont un au départ, mais il s'agit d'un 15 octal (CR, caractère retour sur Mac classique)). En utilisant un 'find' ayant les options nécessaires (je l'ai ici sous 10.2.8), on peut faire plus blindé: export CLASSPATH=`find /path/to -name *.jar -maxdepth 1 -print0 | tr ' 00' :`"$CLASSPATH" On a ainsi les résultats de la recherche séparés par un caractère nul, sans interférence possible avec le nom des fichiers puisque le caractère nul, avec le slash, est interdit des noms de fichier. Reste le problème des deux points dans le nom des fichiers, problèmes que l'on peut "échapper" en insérant un "sed -e 's/:/\:/g'", qui remplace tout deux-points par un antislash-deux-points (plus exactement deux, pour que l'affectation ai la forme "export CLASSPATH=/il/est/14:47", sinon avec un seul l'antislash disparaît) entre le find et le tr, mais je ne suis pas sûr que Java sache s'en sortir avec un PATH aussi biscornu (bash n'a pas l'air avec un tel PATH).
Cela dit, la première solution devrait être suffisante. Le reste n'est que pour la culture (nul doute que ça servira à d'autres occasions).
export CLASSPATH=/path/to/*.jar:$CLASSPATH
java ne trouve pas une classe, ce que j'ai du faire (donc sans la
wildcard "*") :
export
CLASSPATH=/path/to/fichier1.jar[...]:/path/to/fichierN.jar:$CLASSPATH
Ce que ça fait:
un ls sur tous les .jar, qui (man ls) s'il est pipé, sort un nom par
ligne. On récupère donc ça et on remplace (tr) chaque fin de ligne
(caractère 12 en octal) par deux points. On en récupère le résultat pour
préfixer le CLASSPATH actuel.
Sous DOS, j'ai l'impression que chaque commande gère son * comme il
veut. Peut-être l'affectation de CLASSPATH se débrouille-t-elle pour que
les fichiers correspondants à *.jar soient séparés par un point-virgule.
Mais sous Unix, la philosophie étant "chacun fait peu, mais bien", c'est
le shell qui fait l'expansion sans se soucier de qui va en recevoir le
résultat: il mettra toujours des espaces entre les résultats. Mais la
philosophie aidant, on finira toujours par trouver un outil faisant
(bien) ce qu'on a à faire.
La solution n'est pas optimale, car notre 'tr' ne distingue pas un
retour à la ligne envoyé par ls pour séparer deux entrée, de celui
contenu dans un nom de fichier. Le cas est cependant assez rare (je
crois que les fichier Icon affectant un icone à un dossier en ont un au
départ, mais il s'agit d'un 15 octal (CR, caractère retour sur Mac
classique)).
En utilisant un 'find' ayant les options nécessaires (je l'ai ici sous
10.2.8), on peut faire plus blindé:
export CLASSPATH=`find /path/to -name *.jar -maxdepth 1 -print0 | tr
' 00' :`"$CLASSPATH"
On a ainsi les résultats de la recherche séparés par un caractère nul,
sans interférence possible avec le nom des fichiers puisque le caractère
nul, avec le slash, est interdit des noms de fichier. Reste le problème
des deux points dans le nom des fichiers, problèmes que l'on peut
"échapper" en insérant un "sed -e 's/:/\\:/g'", qui remplace tout
deux-points par un antislash-deux-points (plus exactement deux, pour que
l'affectation ai la forme "export CLASSPATH=/il/est/14\:47", sinon avec
un seul l'antislash disparaît) entre le find et le tr, mais je ne suis
pas sûr que Java sache s'en sortir avec un PATH aussi biscornu (bash n'a
pas l'air avec un tel PATH).
Cela dit, la première solution devrait être suffisante. Le reste n'est
que pour la culture (nul doute que ça servira à d'autres occasions).
export CLASSPATH=/path/to/*.jar:$CLASSPATH java ne trouve pas une classe, ce que j'ai du faire (donc sans la wildcard "*") : export CLASSPATH=/path/to/fichier1.jar[...]:/path/to/fichierN.jar:$CLASSPATH
Ce que ça fait: un ls sur tous les .jar, qui (man ls) s'il est pipé, sort un nom par ligne. On récupère donc ça et on remplace (tr) chaque fin de ligne (caractère 12 en octal) par deux points. On en récupère le résultat pour préfixer le CLASSPATH actuel.
Sous DOS, j'ai l'impression que chaque commande gère son * comme il veut. Peut-être l'affectation de CLASSPATH se débrouille-t-elle pour que les fichiers correspondants à *.jar soient séparés par un point-virgule. Mais sous Unix, la philosophie étant "chacun fait peu, mais bien", c'est le shell qui fait l'expansion sans se soucier de qui va en recevoir le résultat: il mettra toujours des espaces entre les résultats. Mais la philosophie aidant, on finira toujours par trouver un outil faisant (bien) ce qu'on a à faire.
La solution n'est pas optimale, car notre 'tr' ne distingue pas un retour à la ligne envoyé par ls pour séparer deux entrée, de celui contenu dans un nom de fichier. Le cas est cependant assez rare (je crois que les fichier Icon affectant un icone à un dossier en ont un au départ, mais il s'agit d'un 15 octal (CR, caractère retour sur Mac classique)). En utilisant un 'find' ayant les options nécessaires (je l'ai ici sous 10.2.8), on peut faire plus blindé: export CLASSPATH=`find /path/to -name *.jar -maxdepth 1 -print0 | tr ' 00' :`"$CLASSPATH" On a ainsi les résultats de la recherche séparés par un caractère nul, sans interférence possible avec le nom des fichiers puisque le caractère nul, avec le slash, est interdit des noms de fichier. Reste le problème des deux points dans le nom des fichiers, problèmes que l'on peut "échapper" en insérant un "sed -e 's/:/\:/g'", qui remplace tout deux-points par un antislash-deux-points (plus exactement deux, pour que l'affectation ai la forme "export CLASSPATH=/il/est/14:47", sinon avec un seul l'antislash disparaît) entre le find et le tr, mais je ne suis pas sûr que Java sache s'en sortir avec un PATH aussi biscornu (bash n'a pas l'air avec un tel PATH).
Cela dit, la première solution devrait être suffisante. Le reste n'est que pour la culture (nul doute que ça servira à d'autres occasions).
