C'est pour troller parce que ca fait plaisir. Et c'est pour eduquer parce que bon, le shell ca n'a pas non plus a etre crado tout le temps, surtout quand on veut donner du code.
La commande ls est prevue pour un usage interactif, pas pour etre parsee. Son output n'est pas fiable. De plus utiliser le resultat d'expansion de commandes comme noms de fichier c'est plutot hasardeux et souvent inutile... De plus, si tu ne declares pas tes variables de fonction "local", tu pourris l'environnement de l'appelant, fais attention.
En built-in, tu peux faire plus rapide et plus secure comme ca :
cd_up(){local opt_saving=$(shopt -p failglob nullglob)shopt -s nullglob
shopt -u failglob
local -a dirs=( */ )eval"$opt_saving"[[${#dirs[@]} -ne 0]]||return 0
cd"${dirs[0]}" 2>/dev/null && ls
}
# ok, corrigeons. :p
Posté par Dams Nadé (site web personnel) . En réponse au journal Faire de la magie avec son .inputrc. Évalué à 10. Dernière modification le 28 mars 2015 à 21:50.
C'est pour troller parce que ca fait plaisir. Et c'est pour eduquer parce que bon, le shell ca n'a pas non plus a etre crado tout le temps, surtout quand on veut donner du code.
La commande ls est prevue pour un usage interactif, pas pour etre parsee. Son output n'est pas fiable. De plus utiliser le resultat d'expansion de commandes comme noms de fichier c'est plutot hasardeux et souvent inutile... De plus, si tu ne declares pas tes variables de fonction "local", tu pourris l'environnement de l'appelant, fais attention.
En built-in, tu peux faire plus rapide et plus secure comme ca :