Pas de problème. Je ne trouve pas ma syntaxe si difficile à lire à partir du moment où 1. on n'a pas de coloration déconnante, et 2. on considère bien que toute la commande à substituer entre les parenthèse est interprétée à part. Au contraire, je trouve ça plus lisible qu'avec des échappements, dont j'ai d'ailleurs peur qu'ils ne fonctionnent pas du tout (le shell verra une commande avec des \", c'est quoi ça ?).
Et pour ce qui est d'encadrer de guillemets inutilement, je pars du principe que l'utilisateur, ou celui qui modifiera mon script, pourra mettre les pires conneries dans mes variables, donc je blinde. Une bonne habitude à prendre d'ailleurs, consiste à forcer l'arrêt des options avant de donner un argument variable à une commande histoire de se prémunir des variables commençant par un tiret, genre :
[^] # Re: Intéressant tes critiques sur le shell
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 5. Dernière modification le 04 septembre 2014 à 22:50.
Pas de problème. Je ne trouve pas ma syntaxe si difficile à lire à partir du moment où 1. on n'a pas de coloration déconnante, et 2. on considère bien que toute la commande à substituer entre les parenthèse est interprétée à part. Au contraire, je trouve ça plus lisible qu'avec des échappements, dont j'ai d'ailleurs peur qu'ils ne fonctionnent pas du tout (le shell verra une commande avec des \", c'est quoi ça ?).
Et pour ce qui est d'encadrer de guillemets inutilement, je pars du principe que l'utilisateur, ou celui qui modifiera mon script, pourra mettre les pires conneries dans mes variables, donc je blinde. Une bonne habitude à prendre d'ailleurs, consiste à forcer l'arrêt des options avant de donner un argument variable à une commande histoire de se prémunir des variables commençant par un tiret, genre :