Shell - utilisation des quotes ""
Résolu/Fermé
jax54000
Messages postés
44
Date d'inscription
mercredi 8 septembre 2004
Statut
Membre
Dernière intervention
24 mai 2008
-
30 mars 2007 à 22:46
jax54000 Messages postés 44 Date d'inscription mercredi 8 septembre 2004 Statut Membre Dernière intervention 24 mai 2008 - 4 avril 2007 à 22:34
jax54000 Messages postés 44 Date d'inscription mercredi 8 septembre 2004 Statut Membre Dernière intervention 24 mai 2008 - 4 avril 2007 à 22:34
A voir également:
- Shell - utilisation des quotes ""
- Notice d'utilisation - Guide
- Utilisation chromecast - Guide
- Classic shell windows 11 - Télécharger - Personnalisation
- Efi shell version 2.50 - Forum Windows 10
- La ressource demandée est en cours d'utilisation - Forum Téléphones & tablettes Android
3 réponses
jipicy
Messages postés
40842
Date d'inscription
jeudi 28 août 2003
Statut
Modérateur
Dernière intervention
10 août 2020
4 897
31 mars 2007 à 00:31
31 mars 2007 à 00:31
Re-
La meilleure façon d'essayer de comprendre c'est de faire des tests. Si on reprend par exemple le script de ton post :
Et puis c'est très aléatoire en fonction des shells, de leur version, des systèmes (dixit "jpzuate" ici même)...
Plutôt que de me lancer dans de grands discours...
Introduction aux variables et aux paramètres
Guillemets et apostrophes
Substitution de paramètres
Et puis surtout : Guide avancé d'écriture des scripts Bash.
;-))
La meilleure façon d'essayer de comprendre c'est de faire des tests. Si on reprend par exemple le script de ton post :
Sentence="Hello boys I want to display *"
for Word in ${Sentence}
do
echo "${Word}"
done Essayes-le tel quel et puis mets des doubles-quotes autour de "$Sentence" :Sentence="Hello boys I want to display *"
for Word in "${Sentence}"
do
echo "${Word}"
done Alors ???
Et puis c'est très aléatoire en fonction des shells, de leur version, des systèmes (dixit "jpzuate" ici même)...
Plutôt que de me lancer dans de grands discours...
Introduction aux variables et aux paramètres
Guillemets et apostrophes
Substitution de paramètres
Et puis surtout : Guide avancé d'écriture des scripts Bash.
;-))
jax54000
Messages postés
44
Date d'inscription
mercredi 8 septembre 2004
Statut
Membre
Dernière intervention
24 mai 2008
1
31 mars 2007 à 12:42
31 mars 2007 à 12:42
Hello,
Merci pour tous ces liens que je met de côté soigneusement et que je prendrai le temps de lire tranquillement.
Je pensais que le shell était très portable et c'est pour ça que j'avais décidé de l'apprendre et de l'utiliser (je me fabrique une petite boîte à outils pour des tâches relativement répétitives que je fais au travail).
Si effectivement le shell n'est pas ci portable que ça....je suis un peu déçu car je développe chez moi et je ne sais pas comment les scripts vont être interprétés à mon bureau...)
A+
Merci pour tous ces liens que je met de côté soigneusement et que je prendrai le temps de lire tranquillement.
Je pensais que le shell était très portable et c'est pour ça que j'avais décidé de l'apprendre et de l'utiliser (je me fabrique une petite boîte à outils pour des tâches relativement répétitives que je fais au travail).
Si effectivement le shell n'est pas ci portable que ça....je suis un peu déçu car je développe chez moi et je ne sais pas comment les scripts vont être interprétés à mon bureau...)
A+
jpzuate
Messages postés
56
Date d'inscription
dimanche 4 mars 2007
Statut
Contributeur
Dernière intervention
9 juin 2008
51
1 avril 2007 à 00:53
1 avril 2007 à 00:53
Salut,
La question de portabilité est un vaste sujet en soit ...
Le shell, comme le SQL, comme probablement beaucoup de choses, sont réputées portables. A condition toutefois, en général, de respecter certains standarts, tels que la norme POSIX pour le shell par exemple. En autre, on recommande par exemple d'utiliser
au lieu de
ou
au lieu de
Mais le comportement du shell est une chose, la liste, la version et les options des commandes utilisables dans un tel contexte en est une autre ! Voir UnixGuide qui dresse un panorama des équivalents de certaines informations ou commandes de niveau système pour AIX, HP-UX, Solaris, FreeBSD, Linux et Tru64 ...
Nonobstant, si j'en crois ma propre expérience d'outils DBA Ingres en shell que je porte chez mes clients, qui ont tous non seulement des Unix différents mais aussi des utilisations du shell par défaut différent (csh, ksh, etc), il faut s'attendre à quelques modifications mineures selon la manière dont les programmes sont écrits. De même, j'ai beaucoup appris le shell à étudier ceux des autres. Par exemple le SGBD Ingres est multi plateforme : tous les Unix, Linux, Windows, et même VMS. C'est intéressant de voir, quand on connait un peu une technologie, comme le même problème est traité d'un OS à l'autre.
Pour le shell chez Ingres ils ont adopté, en gros, 3 principes :
1/ pour les commandes trop spécifiques, on passe par une variable dans le shell au lieu d'utiliser la variable elle même. Par exemple, on peut lire çà et là dans les scripts shell de Ingres
au lieu de
Un exemple intéressant sur ce point est la commande grep et l'option -E, qui n'existe pas de la même manière d'un OS à l'autre. Sur HP, le -E est implémenté "naturellement". Sur Sun, il faut appeler le grep qui se trouve dans un répertoire xpg4 quelque chose, sur d'autres il faut utiliser la commande egrep (comme extended grep), et enfin sur pas mal d'OS le lien entre grep et egrep est fait naturellement (c'est le cas de HP je crois). Il en va de même avec awk, qui selon la version (awk ou nawk) n'accepte pas forcément le positionnement de variables à l'appel de awk ou n'implémente pas la même liste de fonctions ...
2/ Le point 1 oblige donc a gérer un fichier de dépendance système (dans Ingres il se nomme iisysdep comme Ingres Installation System Dependencies), qui va tester la nature de l'OS, via une variable maintenue dans le logiciel (dans mon exemple Ingres. Par ce que bien entendu je ne pense pas qu'il existe 1 méthode unique pour déterminer à coup sûr le type de l'OS, ses capacités en terme de shell, etc)
3/ Enfin, je pense que la méthode la plus sûre pour garantir une vraie interopérabilité d'un OS à l'autre n'est pas d'écrire le shell mais de le fabriquer. En gros tu as un canevas qui décrit la logique du programme, un fichier de référence qui indique quoi faire dans quel contexte, et on fabrique les shells qui vont bien à chaque fois. Un dernier mot enfin, il faut aussi s'entendre sur les versions d'OS sur lesquels les shells sont susceptible de fonctionner, et s'entendre sur une liste serrée d'options utilisables à ISO service sur ces environnements ...
Voili voilà ;-)
La question de portabilité est un vaste sujet en soit ...
Le shell, comme le SQL, comme probablement beaucoup de choses, sont réputées portables. A condition toutefois, en général, de respecter certains standarts, tels que la norme POSIX pour le shell par exemple. En autre, on recommande par exemple d'utiliser
chmod uog+rwx fichier
au lieu de
chmod 777 fichier
ou
echo ${VARIABLE}
au lieu de
echo $VARIABLE
Mais le comportement du shell est une chose, la liste, la version et les options des commandes utilisables dans un tel contexte en est une autre ! Voir UnixGuide qui dresse un panorama des équivalents de certaines informations ou commandes de niveau système pour AIX, HP-UX, Solaris, FreeBSD, Linux et Tru64 ...
Nonobstant, si j'en crois ma propre expérience d'outils DBA Ingres en shell que je porte chez mes clients, qui ont tous non seulement des Unix différents mais aussi des utilisations du shell par défaut différent (csh, ksh, etc), il faut s'attendre à quelques modifications mineures selon la manière dont les programmes sont écrits. De même, j'ai beaucoup appris le shell à étudier ceux des autres. Par exemple le SGBD Ingres est multi plateforme : tous les Unix, Linux, Windows, et même VMS. C'est intéressant de voir, quand on connait un peu une technologie, comme le même problème est traité d'un OS à l'autre.
Pour le shell chez Ingres ils ont adopté, en gros, 3 principes :
1/ pour les commandes trop spécifiques, on passe par une variable dans le shell au lieu d'utiliser la variable elle même. Par exemple, on peut lire çà et là dans les scripts shell de Ingres
${PSCMD} | commande
au lieu de
ps -eaf | commande
Un exemple intéressant sur ce point est la commande grep et l'option -E, qui n'existe pas de la même manière d'un OS à l'autre. Sur HP, le -E est implémenté "naturellement". Sur Sun, il faut appeler le grep qui se trouve dans un répertoire xpg4 quelque chose, sur d'autres il faut utiliser la commande egrep (comme extended grep), et enfin sur pas mal d'OS le lien entre grep et egrep est fait naturellement (c'est le cas de HP je crois). Il en va de même avec awk, qui selon la version (awk ou nawk) n'accepte pas forcément le positionnement de variables à l'appel de awk ou n'implémente pas la même liste de fonctions ...
2/ Le point 1 oblige donc a gérer un fichier de dépendance système (dans Ingres il se nomme iisysdep comme Ingres Installation System Dependencies), qui va tester la nature de l'OS, via une variable maintenue dans le logiciel (dans mon exemple Ingres. Par ce que bien entendu je ne pense pas qu'il existe 1 méthode unique pour déterminer à coup sûr le type de l'OS, ses capacités en terme de shell, etc)
3/ Enfin, je pense que la méthode la plus sûre pour garantir une vraie interopérabilité d'un OS à l'autre n'est pas d'écrire le shell mais de le fabriquer. En gros tu as un canevas qui décrit la logique du programme, un fichier de référence qui indique quoi faire dans quel contexte, et on fabrique les shells qui vont bien à chaque fois. Un dernier mot enfin, il faut aussi s'entendre sur les versions d'OS sur lesquels les shells sont susceptible de fonctionner, et s'entendre sur une liste serrée d'options utilisables à ISO service sur ces environnements ...
Voili voilà ;-)
jipicy
Messages postés
40842
Date d'inscription
jeudi 28 août 2003
Statut
Modérateur
Dernière intervention
10 août 2020
4 897
>
jpzuate
Messages postés
56
Date d'inscription
dimanche 4 mars 2007
Statut
Contributeur
Dernière intervention
9 juin 2008
1 avril 2007 à 00:57
1 avril 2007 à 00:57
Merci. Très intéressant et très instructif.
;-)
;-)
jax54000
Messages postés
44
Date d'inscription
mercredi 8 septembre 2004
Statut
Membre
Dernière intervention
24 mai 2008
1
4 avril 2007 à 22:34
4 avril 2007 à 22:34
Merci pour toutes ces précisions.
A+
A+
