Manipulation de fichiers dans un terminal

Support Debian
#41

[quote=“lroy”]c’est effectivement un peu tarabiscoté, mais il peut y avoir une raison de l’écrire comme ça, notamment si plusieurs versions de l’interpréteur sont installées sur le système, par exemple une version plus récente dans /usr/local/bin ou une version beta dans ~/.local/bin. en utilisant /usr/bin/env on s’assure de prendre la même version que celle résolue par le path.
pour les shells ce n’est pas forcément très utile, mais pour des langages comme python ou ruby par exemple il n’est pas rare de vouloir utiliser des versions plus récentes que celles installées dans le système, c’est pour cela qu’on évite de hard-coder le shebang #!.

sinon dash est l’exécutable /bin/dash et /bin/sh est l’un de ses liens symboliques.

tu peux d’ailleurs taper simplement sh dans ton shell pour te retrouver sous dash, tu vas voir que c’est roots :slightly_smiling:[/quote]

Pourtant [mono]sh[/mono] est censé être l’allias de l’ancien [mono]bourne shell[/mono] qui a remplacé le [mono]Thompson shell[/mono] appelé aussi [mono]sh[/mono] il y a… très longtemps, non ? :017

#42

env dans ce cas là ne fait pas vraiment de “bascule”, il exécute le script avec le premier interpréteur “bash” qu’il trouve dans les diverses variables d’environnement présentes lors de son appel (pour faire court, il cherche principalement dans PATH).

dash fait aussi partie de la famille des bourne shells, mais il est beaucoup plus léger que bash car il se résume principalement au respect global de la norme POSIX et pas grand chose de plus. d’ailleurs tu peux voir qu’il est quasiment 10x plus petit (120ko contre 1Mo).

#43

Daccord, je viens de piger dash est totalement portable avec le bash donc l’idée de bascule n’a effectivement pas de sens, et dash est en quelque sorte un bash optimisé exécution (si le terme n’est pas abusif).
Tous les jours j’apprends quelque chose :laughing:

#44

voilà c’est pour ça que la grande majorité des scripts shells installés dans ta Debian sont “purs”, ils sont déclarés en #!/bin/sh et s’exécutent avec dash, ils respectent les standards et sont portables (voir dans /etc/init.d/ par exemple).

c’est pour ça que de mon point de vue, il faut garder cette bonne pratique et ne pas utiliser les bashisms dans ses propres scripts, mais ce n’est bien sûr qu’une recommandation, rien ne t’empêche de faire des scripts spécifiques bash :wink:

par expérience, lorsqu’on commence à se sentir limité par la syntaxe shell standard, il vaut mieux réfléchir à utiliser un vrai langage de scripting comme perl ou python, plutôt que de rajouter une couche de syntaxe imbitable comme les bashisms.

#45

[quote=“lroy”]voilà c’est pour ça que la grande majorité des scripts shells installés dans ta Debian sont “purs”, ils sont déclarés en #!/bin/sh et s’exécutent avec dash, ils respectent les standards et sont portables (voir dans /etc/init.d/ par exemple).

c’est pour ça que de mon point de vue, il faut garder cette bonne pratique et ne pas utiliser les bashisms dans ses propres scripts, mais ce n’est bien sûr qu’une recommandation, rien ne t’empêche de faire des scripts spécifiques bash :wink:

par expérience, lorsqu’on commence à se sentir limité par la syntaxe shell standard, il vaut mieux réfléchir à utiliser un vrai langage de scripting comme perl ou python, plutôt que de rajouter une couche de syntaxe imbitable comme les bashisms.[/quote]

Proscrire les bashisms car ils ne son pas POSIX, c’est ça ?
Je débute en script et c’est le genre d’info intéressante a connaître pour ne pas se disperser, il y a tellement de littérature a intégrer c’est bien de se concentrer sur l’essentiel. :038

#46

Salut a tous, petite question sur la syntaxe générale des options longues.
Une option longue doit être précédée de deux tirets “–” mais si l’on veux chaîner deux options longues ???
Quel modèle est correct ?

1- $ commande --option1 --option2
2- $ commande -option1 -option2

Selon moi dans le 2éme modèle -option2 est ambigu car il pourrait être interprété comme un argument de -option1, donc j’aurais tendance a utiliser le premier modèle

#47

Formulation correcte.

Formulation incorrecte, équivalent (selon les programmes) à : [mono]$ commande -o -p -t -i -n -1 -2[/mono] ou à : [mono]$ commande -o “ption1” -o “ption2”[/mono]

#48

Formulation correcte.

Formulation incorrecte, équivalent (selon les programmes) à : [mono]$ commande -o -p -t -i -n -1 -2[/mono] ou à : [mono]$ commande -o “ption1” -o “ption2”[/mono][/quote]

Ok, merci c’est bien ce que je pensais, je me prend trop la tête :open_mouth:

#49

Salut à tous, petite question sur le manuel, comment peut-on savoir si une commande possède plusieurs occurrences dans 2 ou plusieurs des 9 sections du manuel ?

#50

michel@debG53SW:~$ whatis printf printf (1) - Formater et afficher des données printf (3) - formatted output conversion michel@debG53SW:~$

#51

[quote=“MicP”]michel@debG53SW:~$ whatis printf printf (1) - Formater et afficher des données printf (3) - formatted output conversion michel@debG53SW:~$ [/quote]

Merci beaucoup :041

#52

Avec plaisir.

Il y avait aussi, plus simplement :

michel@debG53SW:~$ man -f printf printf (1) - Formater et afficher des données printf (3) - formatted output conversion michel@debG53SW:~$