Écrivant sur un clavier azerty à ce moment là mon doit a glissé et le O s'est transformé en P.
Il fallait donc comprendre : bash ou pas bash
et Gandalf m'a interdit de le modifier à posteriori
en faisant par exemple :
nb=$( echo "$var" | cut -d' ' -f1 )
C’est suffisamment peu trivial pour mériter d’être explicité à un débutant.
```C'est une solution fonctionnelle à charge de celui qui reçois l'information de faire des tests pour s'approprier ce fonctionnement.
Rappel : sont disponibles dans les distributions gnu/linux des outils comme man et info pour connaître les options des commandes et au pire pour cut par exemple cut --help.
Tu sembles avoir pris ma question pour une critique contre toi, mais c’était une vraie question. J’aurais pour louper un moyen simple d’obtenir le premier élément.
Non ce n'est pas ça, mais la question était clair et circonscrite et ta réponse longue un peu touffue avec des digressions et parfois du hors sujet. :) de plus le bash bashing :) tout le long de tes propos m'a un peu irrité.
J'ai toujours entendu dire : "il n'y a pas de mauvais langage, il n'y a que des mauvais développeurs" et je m'applique cette maxime chaque jours surtout quand j'écris un bug dans un programme.
S’il n’y en a pas (tu m’excuseras, j’espère, de ne pas considérer comme simple l’appel à des commandes tierces), c’est par contre encore une tare du shell POSIX.
J'aime beaucoup cette assertion mais elle est infondée le shell à justement été conçu comme un environnement permettant d'utiliser des commandes externes très performantes dans ce qu'elle font c'est la philosophie même du shell être la glu entre diverses commande Unix et c'est sa grande force.
Bash, lui, supporte de vrais tableaux ; malheureusement, il n’est pas partout (même s’il est sur la plupart des distributions Linux, hormis les mini-distributions basées sur Busybox).
c'est pour celà que quand on fait un script shell il faut tenir compte du contexte. De plus souvent une simple chaîne de caractères suffit pour les usages courants.
et pour un vieux système comme solaris ou hpux par exemple tu utilises des anti-quotes `.
Si on choisit /bin/sh pour la portabilité et qu’on n’est pas sûr de ne pas tomber sur un vieux shell, mieux vaut éviter autant que possible tous les « ajouts modernes », donc utiliser des anti-quotes.
Je ne suis pas d'accord avec cette analyse comme la personne qui pose une question est "débutante" elle a pu très bien lire des documentations ou on indique #!/bin/sh sans vraiment noter la signification réelle de cette ligne ou se poser la question.
J'ai croisé un administrateur système débutant deux années d'expérience qui n'écrivait pas de shebang dans ses scripts, et après discussion m'a avoué qu'il ignorait ce détail mais don't act maintenant il l'a appris et ses script n'en sont que meilleurs.
Et personnellement je suis favorable à l'utilisation des fonctionnalités plus récentes disponible que de garder les vielles habitudes ( ce n'ai que mon opinion ).
mais il est important de connaître les anciennes syntaxe pour ne pas être surpris lors de la relecture d'un script.
sur la fin ta réponse ( fin de second message )c'est : moi je le fait en perl
C'est un peu hors sujet non ?
Je n’ai pas dit le contraire ; c’est une digression qui ne s’adresse pas particulièrement à l’auteur de la question, dont je présume que le but est de se familiariser avec le shell. C’est pour ça que je n’ai pas développé.
Cette partie du site est un forum son but est de répondre aux questions.Mais pour les digressions pourquoi ne pas rédiger un journal pour s'adresser à un public plus large ?
Et je suis prêt et heureux d'en discuter avec toi pour une rédaction conjointe si tu le souhaites.
En shell, tu passes ton temps à essayer d’éviter des écueils (par exemple, les variables interprétées à chaque appel ; si elles peuvent contenir des espaces ou des caractères bizarres, tu as intérêt à les "quoter" correctement ; je connais un sysadmin pourtant expérimenté qui a effacé un tas de fichiers qu’il n’aurait pas dû à cause de ça) et à contourner les limitations (par exemple, les fonctions ne peuvent pas retourner de valeur hormis un code d’erreur).
en utilisant les bonnes pratiques en "quotant" systématiquement tes variables tu n'as pas de problème dans 99,9% des cas.
Tu avance ici un élément faux quand tu dis que les fonctions ne renvoient rien d'autre que des code retour.
tu peux très bien leur faire renvoyer ce que tu veux sur la sortie standard.
fais ce petit test ci-dessous.
mafonction () {
local var1="1ドル"
local var2="2ドル"
if [ ! -z "1ドル" -a ! -z "2ドル" ]
then
echo "vos variable : 1ドル et 2ドル "
return 0
fi
echo " erreur "
return 1
}
mafonction argument1 argument2
echo $?
mafonction argument1
echo $?
tu peux affecter ce retour à une variable comme ceci par exemple.
```
mavar=$( mafonction argument1 argument2 )
echo "$mavar"
```comme je te l'ai dit plus haut, je suis ouvert à toute suggestion pour l'écriture d'un journal ou d'une dépêche sur le sujet.
Et pour finir sur une note positive je trouve ta solution en shell fort élégante et robuste :D
Je regrette encore d'avoir été un peu sec dans ma réponse et j'espère que tu en comprendras la raison.
[^] # Re: modifie l'initialisation
Posté par Nodeus . En réponse au message Passer de paramètres à valeurs saisie par l'utilisateur... Évalué à 1.
Écrivant sur un clavier azerty à ce moment là mon doit a glissé et le O s'est transformé en P.
Il fallait donc comprendre : bash ou pas bash
et Gandalf m'a interdit de le modifier à posteriori
Rappel : sont disponibles dans les distributions gnu/linux des outils comme man et info pour connaître les options des commandes et au pire pour cut par exemple cut --help.
Non ce n'est pas ça, mais la question était clair et circonscrite et ta réponse longue un peu touffue avec des digressions et parfois du hors sujet. :) de plus le bash bashing :) tout le long de tes propos m'a un peu irrité.
J'ai toujours entendu dire : "il n'y a pas de mauvais langage, il n'y a que des mauvais développeurs" et je m'applique cette maxime chaque jours surtout quand j'écris un bug dans un programme.
J'aime beaucoup cette assertion mais elle est infondée le shell à justement été conçu comme un environnement permettant d'utiliser des commandes externes très performantes dans ce qu'elle font c'est la philosophie même du shell être la glu entre diverses commande Unix et c'est sa grande force.
petit article wikipedia https://fr.wikipedia.org/wiki/Shell_Unix
En lisant les livres de Christophe Blaess c'est une chose claire également :
Langages de scripts sous Linux https://www.blaess.fr/christophe/livres/scripts-sous-linux/ celui-ci est épuisé mais ce trouve en occasion.
Scripts shell Linux et Unix https://www.blaess.fr/christophe/livres/scripts-shell-linux-et-unix/
c'est pour celà que quand on fait un script shell il faut tenir compte du contexte. De plus souvent une simple chaîne de caractères suffit pour les usages courants.
Je ne suis pas d'accord avec cette analyse comme la personne qui pose une question est "débutante" elle a pu très bien lire des documentations ou on indique #!/bin/sh sans vraiment noter la signification réelle de cette ligne ou se poser la question.
J'ai croisé un administrateur système débutant deux années d'expérience qui n'écrivait pas de shebang dans ses scripts, et après discussion m'a avoué qu'il ignorait ce détail mais don't act maintenant il l'a appris et ses script n'en sont que meilleurs.
Et personnellement je suis favorable à l'utilisation des fonctionnalités plus récentes disponible que de garder les vielles habitudes ( ce n'ai que mon opinion ).
mais il est important de connaître les anciennes syntaxe pour ne pas être surpris lors de la relecture d'un script.
Cette partie du site est un forum son but est de répondre aux questions.Mais pour les digressions pourquoi ne pas rédiger un journal pour s'adresser à un public plus large ?
Et je suis prêt et heureux d'en discuter avec toi pour une rédaction conjointe si tu le souhaites.
en utilisant les bonnes pratiques en "quotant" systématiquement tes variables tu n'as pas de problème dans 99,9% des cas.
Tu avance ici un élément faux quand tu dis que les fonctions ne renvoient rien d'autre que des code retour.
tu peux très bien leur faire renvoyer ce que tu veux sur la sortie standard.
fais ce petit test ci-dessous.
tu peux affecter ce retour à une variable comme ceci par exemple.
```
mavar=$( mafonction argument1 argument2 )
echo "$mavar"
```comme je te l'ai dit plus haut, je suis ouvert à toute suggestion pour l'écriture d'un journal ou d'une dépêche sur le sujet.
Et pour finir sur une note positive je trouve ta solution en shell fort élégante et robuste :D
Je regrette encore d'avoir été un peu sec dans ma réponse et j'espère que tu en comprendras la raison.