excellente suggestion, qu’il m’arrive d’utiliser presque sans y penser, mais sans en avoir fait un règle. (par exemple variable DirBkp ou fonction CreerDirBkp)
Si j’avais été plus rigoureux, j’aurais d’emblée appliqué cette règle, et cette discussion n’aurait pas eu lieu…
En conclusion, l’écrasement de la variable PATH rendait inaccessible toutes les commandes dont le chemin complet n’était pas donné.
donc
- il est préférable de ne pas écraser une variable système!
- il est préférable de donner le chemin complet des commandes et autres fichiers.
Merci à tous pour vos réponses, vos critiques et vos suggestions.
Ce ne sont pas des variables système, mais des variables d’environnement
Le chemin absolu d’un exécutable n’est pas nécessaire, puisqu’il dépends des variables d’environnement qui vont proposer le « bon » chemin en fonction de la configuration du système installé, et que le chemin absolu qui serait imposé dans un script pourrait ne pas correspondre à l’environnement dans lequel le script sera lancé.
En résumé, à moins d’avoir une raison personnelle bien particulière de vouloir utiliser une commande précise dont on connaît parfaitement le chemin absolu, il vaut mieux laisser les variables d’environnement (par exemple : PATH) décider de l’endroit où il faudra aller chercher les commandes à utiliser.
Pour les variables en majuscules, les risques sont extrêmement limités et se limitent essentiellement à « HOME, PATH, PWD, USER » qu’il ne faut pas réaffecter.
env |sort
En notant qu’il n’existe pas de variable environnement majuscule à une seule lettre « A, B …Z », ni aucune en langue française « CHEMIN, REPERTOIRE, DOSSIER etc… », tu n’as vraiment pas eu de chance parmi 1 sur des milliers de combinaisons possibles. Je pense que le sujet du choix des variables est définitivement clos…
Pour en revenir à ton script initial, je n’avais en fait pas vraiment compris pourquoi tu avais besoin de quelque-chose d’aussi compliqué avec 4 variables pour sortir une commande ‹ ls ›, je te propose une variante un peu plus sophistiquée qui contient quelques subtilités qui permettra de vérifier ta progression, en t’appuyant sur la « meilleure » documentation de bash, et non pas de sh à ne pas confondre.
#!/bin/bash
NOM=$1 ; DIR=${2:-.}
until ls ${DIR%/}/$NOM 2>/dev/null ; do
echo -e '\x1b[31m !! saisie <nom> <répertoire> incorrecte !!\x1b[m'
[[ -d $DIR ]] || read -p '-> nouveau répertoire ? ' DIR
[[ -d ${DIR%/}/$NOM ]] || read -p '-> nouveau NOM ? ' NOM
done
exit
il y ena quelqeus autres.
le meilleurs moyen de le savoir, c’est de faire la commende env dans l’environnement correspondant.
Il faut faire attention à IFS aussi.
… et aussi à :
COLORTERM
DBUS_SESSION_BUS_ADDRESS
DESKTOP_SESSION
DISPLAY
GDMSESSION
GTK_MODULES
LANG
LESS_TERMCAP_mb
LESS_TERMCAP_md
LESS_TERMCAP_me
LESS_TERMCAP_se
LESS_TERMCAP_so
LESS_TERMCAP_ue
LESS_TERMCAP_us
LOGNAME
LS_COLORS
PANEL_GDK_CORE_DEVICE_EVENTS
QT_ACCESSIBILITY
SESSION_MANAGER
SHELL
SHLVL
SSH_AGENT_PID
SSH_AUTH_SOCK
TERM
_
VTE_VERSION
WINDOWID
XAUTHORITY
XDG_CONFIG_DIRS
XDG_CURRENT_DESKTOP
XDG_DATA_DIRS
XDG_GREETER_DATA_DIR
XDG_MENU_PREFIX
XDG_RUNTIME_DIR
XDG_SEAT_PATH
XDG_SEAT
XDG_SESSION_CLASS
XDG_SESSION_DESKTOP
XDG_SESSION_ID
XDG_SESSION_PATH
XDG_SESSION_TYPE
XDG_VTNR
réponse générique.
Le mot ‹ essentiellement › ne signifie pas ‹ exclusivement ›, je ne vois aucune ambiguïté.
Les mots « HOME, PATH, PWD, USER » sont juste les plus à risque, intuitivement.
Il faut quand-même avoir un esprit extrêmement tordu pour nommer un répertoire ‹ PANEL_GDK_CORE_DEVICE_EVENTS › ou ‹ QT_ACCESSIBILITY ›, à moins de vraiment chercher volontairement les emmerdes (on a quand-même l’impression que c’est le cas de certains).
Et quand-bien même, il y aurait un bug: oulala.
Quand il y un bug, on cherche et on trouve, et on ne passe pas 1 semaine sur un forum pour comprendre au bout de 20 messages.
env |sort que j’ai cité n’enlève aucune variable.
‹ Sort › est juste un filtre pour trier la liste pour meilleure lisibilité.
Et pour les variables en minuscule, if faut faire :
ls /usr/bin /bin $HOME/bin
pour s’assurer de ne pas utliser un nom de commande comme variable.
Je n’aurais jamais imaginé de telles interrogations pour juste nommer une variable, qui n’est vraiment que le tout début de l’apprentissage du bash.
Si ce n’est pas encore suffisemment clair, je ne vois pas quoi rajouter sur un sujet ‹ variable › que je pensais définitivement clos.