Variables en bash

[invitea09e49c1]

Bonjour,
J'utilise le Bourne Shell et je ne comprend pas pourquoi cela ne marche pas.

J'explique :

Ce fichier PERL contient notamment cette fonction permettant de récupérer des données à partir d'un fichier (l'ID et la séquence)

sub lireFasta	{
					my $indexName = $_[0];
					my $in = Bio::SeqIO -> new(-file => $ARGV[0], -format => 'fasta'); 					
					 
					#Récupération des séquences
					my $i = 1;
					while ( my $seq = $in->next_seq() ) {
						my $id       = $seq->primary_id;
						my $sequence = $seq->seq;
					 
					  	#Passage d'arguments au script CURL associé
						system `./indexFasta.sh '$id' $sequence $indexName $i`;
					  	$i++;
					}
				}

Je souhaite passer ces arguments à un script

indexFasta.sh

qui ressemble à ça :

#!/bin/sh

#**
#
# Remplir l'index avec les paramètres
# 
# @param $1 : ID de la séquence en traitement
# @param $2 : séquence en traitement
# @param $3 : nom de l'index
# @param $4 : id du jeu de donnée traité
###
curl -XPUT localhost:9200/$3/fasta/$4 -d '{
	id : '$1',
	seq : '$2'
}'

 exit 0

Or lorsque je lance le script PERL, il me dit qu'il n'accepte pas la synthaxe dans le Shell et qu'il veut, à la place de mes variables un string or mes variables son belle et bien des String.

Je joint ci-dessous un exemple de Shell qui fonctionne et s'utilise de la même façon pour aider à comprendre (pas de variables dans celui-çi)

curl -XPUT localhost:9200/manuel/biologie/1 -d '{
	id : "livrebio",
	tag : "bookbiocell",
	nom : "biologie cellulaire, il était une fois la vie",
	pages : "2500",
	auteur : "maestro"
}'

Ce code est un outil d'indexation il fonctionne :

curl -XPUT localhost:n°de_port/nom_de_l'index/sous_catégorie/identifiant_dans_l'index -d '{
champ : "valeur du champ",
champ2 : "valeur de champ 2"
}'

J'espère avoir été clair, si ce n'est pas le cas n'hésitez pas, je préciserais ma pensée.


-----

[polo974]

il veut des strings, donnes lui des strings avec des pinces à linge (double quote) autour:

curl -XPUT localhost:9200/$3/fasta/$4 -d '{
    id : "'$1'",
    seq : "'$2'"
}'

[invitea09e49c1]

J'avais déjà essayé cette solution qui ne fonctionne pas.

J'ai trouvé la solution en revanche, il fallait modifier les simple quote initiales en double quotes afin de permettre la lecture du contenu des variables.

curl [...] -d "{
toto : $1,
tata : $2
}"

Merci quand même.

[polo974]

Attention, es-tu sûr que c'est bien bash qui est lancé par /bin/sh ? ? ?
sur ubuntu, par exemple, c'est:
/bin/sh -> dash
qui est beaucoup plus léger (avec le bon coté et le mauvais coté des choses...)

mais ce n'est pas ça qui change grand chose ici.

à mon avis, il faut des " " globales pour que tout tienne ensemble dans l'appel system

et si tes variables avaient eu des espaces ou des virgules comme dans ton exemple
(...
nom : "biologie cellulaire, il était une fois la vie",
...)

il faudrait mettre \"$1\" pour avoir ces accolades autour de la variable $1.

(les imbrications de shell sont une véritable plaie pour les accolades... )

[A voir en vidéo sur Futura]

[inviteb9f49292]

Je crois surtout que les simples guillemets empêche toute interprétation des caractères qu'ils entourent, notamment du "$". A l'inverse des guillemets doubles qui eux n'empêchent pas l'interprétation du "$" par le shell, et donc le remplacement par la valeur de la variable... A vérifier.

[invitea09e49c1]

Je crois surtout que les simples guillemets empêche toute interprétation des caractères qu'ils entourent, notamment du "$". A l'inverse des guillemets doubles qui eux n'empêchent pas l'interprétation du "$" par le shell, et donc le remplacement par la valeur de la variable... A vérifier.

Exactement, c'est de là que venais le problème, une vraie plaie ces quotes si on y fait pas gaffe.

Attention, es-tu sûr que c'est bien bash qui est lancé par /bin/sh ? ? ?

J'en suis quasiment sur vu que mon problème est résolu et que tout tourne parfaitement pour l'instant.

[polo974]

Je crois surtout que les simples guillemets empêche toute interprétation des caractères qu'ils entourent, notamment du "$". A l'inverse des guillemets doubles qui eux n'empêchent pas l'interprétation du "$" par le shell, et donc le remplacement par la valeur de la variable... A vérifier.

ben non, les single quote évitaient bien les $1 et $2...

c'est a mon avis un pb de double passage dans l'évaluateur du shell...

en plus, je viens de voir que le perl passe $id avec des single quote et pas les autres (mais j'y connais rien en perl...)

bref, quelque part, c'est la guerre des quotes...

pour bash/dash, c'est juste en info, car un jour ça tombe, et ça peu faire mal ...

[inviteb9f49292]

ben non, les single quote évitaient bien les $1 et $2...

Pourtant:

#!/bin/dash
FOO="bar"
echo $FOO
echo "$FOO"
echo '$FOO'

ou alors je n'ai pas compris ce que tu voulais dire par là. Ca marche de manière identique avec dash et bash

c'est a mon avis un pb de double passage dans l'évaluateur du shell...

C'est aussi souvent le genre de chose où j'essaye un peu toute les combinaisons jusqu'à ce que ça marche (j'exagère à peine)... Par exemple pour passer une variable du shell en numéro de champ pour awk:

A_LINE="A,B,C,D"
FIELD_NB=2
echo "$A_LINE" | awk -F"," '{print $'"$FIELD_NB"'}'

Je ne sais pas si c'est le plus optimal, mais ça marche...

[invitea09e49c1]

Je prend bonne pour bash/dash. Tu me conseille, si je comprend bien de changer mes lignes #!/bin/sh par #!/bin/dash ou #!/bin/bash

en plus, je viens de voir que le perl passe $id avec des single quote et pas les autres (mais j'y connais rien en perl...)

C'est pour prévenir les caractères spéciaux et les espaces éventuels dans ce string, en effet l'id peut être présenté sous cette forme :

AA 541255| 54487| 487 auquel cas la transmission au shell reviendrait à :

./monShell AA 541255| 54487| 487 etc

et non pas

./monShell "AA 541255| 54487| 487" etc

Les autres sont sans single quotes car il est impossible qu'il y ait des espaces au milieu (pour la sequence cela revient à avoir de mauvais fichiers de base donc inutile de les traiter et les 2 autres sont traités avant pour supprimer ces éventuels géneurs)

Je vous met le code qui fonctionne ci-dessous pour mieux comprendre :

#!/bin/sh
#**
#
# Remplir l'index avec les paramètres
# 
# @param $1 : ID de la séquence en traitement
# @param $2 : séquence en traitement
# @param $3 : nom de l'index
# @param $4 : id du jeu de donnée traité
###
curl -XPUT localhost:9200/$3/fasta/$4 -d "{ 
	id : $1,
	seq : $2
}"


 exit 0
 
#

J'ai mis en gras les différences avec le script initial. Laissez moi expliquer ou était le souci.
En réalité les single quote précédant et suivant les accolades signifiaient au shell "eh mon coco ! Ce que tu trouve entre nous 2 tu l'interprete comme une String ! Tu regarde juste leur position relative au ":" (ces quotes ne sont pas à lire^^) pour savoir qui fait quoi, avant ces des clefs après des valeurs"

Il suffisait donc de remplacer ces quotes par des doubles quotes qui elles autorisent l'interprétation de variables.
Simple comme bonjour me diriez-vous, en réalité j'ai du ruser, en effet la ligne de commande curl possède une petite particularité : les champs DOIVENT être encadré de double quotes.

curl -XPUT localhost:9200/toto/typetoto/1 -d "{
>  toto : stringtoto,
>  tata : tatastring
>  }"

Ne Fonctionne pas, il considère que stringtoto et tatastring ne sont pas des chaines de caractères.

J'ai donc du, trouver une solution pour intégrer les doubles quotes au code.

sub lireFasta	{
					my $indexName = $_[0];
					my $in = Bio::SeqIO -> new(-file => $ARGV[0], -format => 'fasta'); 					
					 
					#Récupération des séquences
					my $i = 1;
					while ( my $seq = $in->next_seq() ) {
						my $id       = $seq->primary_id;
						my $sequence = $seq->seq;
					 
					  	#Passage d'arguments au script CURL associé
					  	$id = "\"".$id."\"";
					  	$sequence = "\"".$sequence."\"";
					  	
						system `./indexFasta.sh '$id' '$sequence' $indexName $i`;
					  	$i++;					
					}
				}

#!/bin/sh
#**
#
# Remplir l'index avec les paramètres
# 
# @param $1 : ID de la séquence en traitement
# @param $2 : séquence en traitement
# @param $3 : nom de l'index
# @param $4 : id du jeu de donnée traité
###
curl -XPUT localhost:9200/$3/fasta/$4 -d "{ 
	id : $1,
	seq : $2
}"

 exit 0
 
#

Voilà la ça fonctionne ^^

PS : Si quelqu'un connait une méthode pour rajouter "" autour d'un string d'une façon plus élégante qu'il se manifeste

Vous savez que c'est long de colorer manuellement un si petit bout de code mais ça facilite la lisibilité donc...
Je vous remercie tous de votre aide et de vos conseils et espère que ma petite explication était claire sinon je peux réessayer d'expliquer.

[polo974]

Pourtant:

#!/bin/dash
FOO="bar"
echo $FOO
echo "$FOO"
echo '$FOO'

ou alors je n'ai pas compris ce que tu voulais dire par là. Ca marche de manière identique avec dash et bash

en fait, il était codé (adapté à l'exemple):

 echo 'blabla '$FOO' encore du blabla'

donc les zones single quotées évitaient la variable.
la différence entre bash et dash se trouve par exemple dans:

echo 'coucou \0105 (E) '
echo -e 'coucou \0105 (E) '

ce qui est une sorte de régression pour bash (à mon avis...)

...
C'est aussi souvent le genre de chose où j'essaye un peu toute les combinaisons jusqu'à ce que ça marche (j'exagère à peine)... Par exemple pour passer une variable du shell en numéro de champ pour awk:

A_LINE="A,B,C,D"
FIELD_NB=2
echo "$A_LINE" | awk -F"," '{print $'"$FIELD_NB"'}'

Je ne sais pas si c'est le plus optimal, mais ça marche...

Quand je dis que c'est la galère...

# la façon awk:
echo "$A_LINE" | awk -F, "{print \$$FIELD_NB}"
# la façon cut:
echo "$A_LINE" | cut -d, -f$FIELD_NB
# et pour le Nème champ en partant de la fin (eh oui, il y a des vicieux...):
echo "$A_LINE" | rev |cut -d, -f$FIELD_NB |rev

et pour revenir au sujet (emballer $1 et $2 de pinces à linges), on peut le faire dans le sh si pas dans perl:

curl -XPUT localhost:9200/$3/fasta/$4 -d "{ 
    id : \"$1\",
    seq : \"$2\"
}"