Discussion :

[Invité]

Bonjour

Je me tourne vers la communauté après beaucoup de recherches sans succès

Quand je fais un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cat /dev/ttyUSB0

je reçois ( d'un capteur)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Courant = xx,yyA
Puissance= xx,yyW

Je souhaiterais mettre ces deux valeurs dans deux variables pour les traiter par la suite.
J'ai voulu faire un cat puis grep .. je me suis fait tuer par Google ...


Si vous avez des idées ou conseil je suis preneur, je pensais faire un petit programme en 10 minutes
J'y suis depuis 2 jours sans succès ...

Merci par avance

Arnaud

[Sve@r]

Bonjour

Je souhaiterais mettre ces deux valeurs dans deux variables pour les traiter par la suite.

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
exec 3</dev/ttyUSB0
read courant 0<&3
read puissance 0<&3

J'ai voulu faire un cat puis grep .. je me suis fait tuer par Google ...

Pas que Google. Ose écrire un truc style cat fic |grep motif dans ce forum et tu te feras tuer par tout le monde (grep motif fic)...

[N_BaH]

Tremblez mécréants !
si vous ne savez pas ce qu'est un UUOC, je vous exécuterai en ligne de commandes.


`même pas vrai.

[jack-ft]

Bonjour

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
exec 3</dev/ttyUSB0
read courant 0<&3
read puissance 0<&3

Est-il nécessaire de passer par un 3< ?

Peut-on faire ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
read courant </dev/ttyUSB0
read puissance </dev/ttyUSB0

En tout cas, chez moi, ça semble marcher:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$ read a < /dev/ttys001
coucou    # <- tapé par moi
$ echo $a
coucou    # <- affiché par echo

[N_BaH]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
$ exec 3< <(printf '%s\n' abc def\ ghi)
$ read -d '' -u 3 d e #un seul read
$ echo "$e"; echo "$d"
def ghi
abc

?

[Christophe]

UUOC : Useless Use Of Cat

Tu pourras arriver à tes fins avec cat et autres commandes, mais le code donné par Sver/NbaH sera plus efficace.

Alors pourquoi on parle de UUOC ?

cat signifie catenate, synonyme de concatenate. La commande sert à concaténer (mettre bout à bout) les fichiers passés en paramètre et d'afficher le résultat sur la sortie standard.
L'usage le plus connu de cat est d'afficher le contenu d'un fichier, mais ce n'est pas l'usage pour lequel la commande est prévue.

[Invité]

Merci de vos réponse aussi rapide


voici mon entrée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
pi@PI2:~ $ cat /dev/ttyUSB0
 
Courant : 3.32 A
 
Puissance : 764.15 W
 
 
Courant : 1.41 A
 
Puissance : 323.67 W
 
 
 
Courant : 1.42 A
 
Puissance : 326.10 W
 
^C
pi@PI2:~ $

voici mon code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
#!/bin/bash
exec 3</dev/ttyUSB0
read Courant 0<&3
read Puissance  0<&3
 
 
echo courant = "${Courant}"

j’obtiens courant = XX,YY

Merci beaucoup

[Invité]

Est-il nécessaire de passer par un 3< ?

Peut-on faire ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
read courant </dev/ttyUSB0
read puissance </dev/ttyUSB0

En tout cas, chez moi, ça semble marcher:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$ read a < /dev/ttys001
coucou    # <- tapé par moi
$ echo $a
coucou    # <- affiché par echo

il faut forcement ajouter 0<&3 sinon sa ne fonctionne pas

[Sve@r]

Est-il nécessaire de passer par un 3< ?

Oui, afin d'avoir un canal spécial dont la particularité est qu'il se vide au fur et à mesure que tu le lis. Son fichier contient 2 infos, il faut que chaque read lise chaque info.

Après tu peux aussi regrouper les read...

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
{
	read courant
	read puissance
} </dev/ttyUSB0

Dans ce cas, l'important c'est que tu ne peux pas t'arrêter de lire entre temps sinon à la lecture suivante tu repars du début du fichier.

Sinon tu peux faire du grep en rafale...

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
courant="$(grep "^Courant=" /dev/ttyUSB0)"
puissance="$(grep "^Puissance=" /dev/ttyUSB0)"

... mais ça c'est franchement ce qu'il y a de pire (tu lis tout le fichier à chaque fois, et si le fichier contient n répétitions d'infos tu obtiens au final le tout en vrac)

En tout cas, chez moi, ça semble marcher:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$ read a < /dev/ttys001
coucou    # <- tapé par moi
$ echo $a
coucou    # <- affiché par echo

Ben oui, mais ton fichier ne contient qu'une ligne

il faut forcement ajouter 0<&3 sinon ça ne fonctionne pas

Voyez-moi ce pseudo-professeur. Il cherche pendant 2 jours un truc qui prend 2 mn puis il vient faire le mec blasé. Et tu peux expliquer pourquoi cela (si tu ne sais pas écrire "ça" tu remplaces par "cela") ne fonctionne pas sans 0<&3?
Il ne suffit pas de dire les choses, encore faut-il dire pourquoi.

[Flodelarab]

Bonjour

Le pourquoi, on ne le connaît pas. On ne sait pas ce qu'il veut faire de son flux. Je vais faire le rabat-joie : le flux est déjà bien formaté. Récupérer dans une variable ne sert à rien. Surtout si c'est pour faire un fichier de mesures. Un bon vieux sed est suffisant.

[Sve@r]

Le pourquoi, on ne le connaît pas. On ne sait pas ce qu'il veut faire de son flux.

Tu n'as pas bien suivi. jack-ft dit "on peut faire sans 3<". Il lui répond "non il faut forcément cette syntaxe sinon ça ne fonctionne pas" sans dire pourquoi il le faut ou pourquoi ça ne fonctionne pas sans ; ce qui en réalité n'est donc ni une réponse ni une explication.
Donc le pourquoi ça ne fonctionne pas sans cette instruction on le connait (et je l'ai expliqué): si tu lis simplement le flux via read v 0<fic tu lis et relis à chaque fois la même première ligne du fichier. D'où nécessité de créer un canal spécifique (ici 3) contenant au départ tout le fichier puis qui se vide au fur et à mesure que tu le lis.

[disedorgue]

Sinon tu peux faire du grep en rafale...

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
courant="$(grep "^Courant=" /dev/ttyUSB0)"
puissance="$(grep "^Puissance=" /dev/ttyUSB0)"

Si le format est vraiment comme ça, je ne peux pas vérifier la sortie, au lieu de la création d'un flux, on pourrait peut-être juste sourcer le fichier et les variables Courant et Puissance serait configurées, non ?

PS: de toute façon, le format a changé et donc la version grep tel quel ne fonctionne plus non plus...

[Sve@r]

on pourrait peut-être juste sourcer le fichier et les variables Courant et Puissance serait configurées, non ?

Ah super bien vu
Malheureusement ça ne fonctionnera pas car la syntaxe n'est pas correcte pour le shell (interdit de mettre un espace avant le "=" dans une affectation de variable et son fichier est écrit Courant = xx,yyA) mais je salue l'idée

[jack-ft]

Oui, afin d'avoir un canal spécial dont la particularité est qu'il se vide au fur et à mesure que tu le lis. Son fichier contient 2 infos, il faut que chaque read lise chaque info.

Après tu peux aussi regrouper les read...

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
{
	read courant
	read puissance
} </dev/ttyUSB0

Dans ce cas, l'important c'est que tu ne peux pas t'arrêter de lire entre temps sinon à la lecture suivante tu repars du début du fichier.

Je pense que je comprends.

En fait, je croyais que tous les /dev/tty* (du moins, ceux dont les droits commencent par un "c", comme "crw-rw-rw") étaient des "canaux spéciaux", comme le tty courant:
si je fais un read sur le tty courant, par exemple, et qu'il n'y a pas de "production" de données, le read se met en attente jusqu'à ce que je tape une ligne suivie d'un return.
Cette ligne est "vidée" du buffer du tty et le prochain read lit la suite, il ne relit pas la ligne précédente.

Évidemment, si on ne me dit pas tout et que /dev/ttyUSB0 est un fichier "normal" qui "n'avance pas" quand on lit dedans, forcément, à moins de lire en séquence continue avec les accolades, ça va beaucoup moins bien marcher...

Du coup, s'il y a plusieurs groupes d'infos à lire, comme cela semble être le cas dans le post #7, il serait peut-être judicieux soit de parser le fichier avec un awk, soit de faire une boucle en shell, avec quelque chose comme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
while read courant && read puissance; do
    # faire ce qu'on veut avec $courant et $puissance
    courant=${courant#*:}
    puissance=${puissance#*:}
    echo "courant: $courant puissance: $puissance"
done < /dev/ttyUSB0

Et là, si je ne m'abuse, le "3<" n'est plus aussi indispensable...

[Sve@r]

Je pense que je comprends.

Whaou

Évidemment, si on ne me dit pas tout et que /dev/ttyUSB0 est un fichier "normal" qui "n'avance pas" quand on lit dedans, forcément, à moins de lire en séquence continue avec les accolades, ça va beaucoup moins bien marcher...

Pour tout te dire, je pense aussi comme toi. En effet, /dev/ttyUSB0 n'est pas un fichier "normal" (le terme exact est "régulier") car les fichiers de /dev ne sont que des références à des drivers IO. Donc il y a fort à parier que /dev/ttyUSB0 se comportera comme tu le décris.
Toutefois, "et si" ce n'était pas le cas, alors ma méthode (ainsi que la tienne que tu viens de poster) fonctionnera. Et si c'est quand-même le cas, ben... elle fonctionnera tout autant.
Donc...

Et là, si je ne m'abuse, le "3<" n'est plus aussi indispensable...

Ben là non puisque tu boucles en lecture directe sur /dev/ttyUSB0. Il y a souvent plusieurs façons d'y arriver sous Unix. Perso j'aime bien cette technique de "canal relié à un fichier" car elle permet de lire et écrire sur le même fichier sans passer par un fichier temporaire
Exemple

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
echo "Hello" >toto				# Pour créer un fichier d'exemple
exec 3<toto
rm -f toto					# Malheureusement obligatoire (et donc pas sans danger !!!)
tr '[:lower:]' '[:upper:]' 0<&3 >toto		# Réécrit un fichier neuf à partir des datas de ce même fichier

Le seul danger, c'est la phase "rm -f" qui est obligatoire sinon la redirection vide le fichier (et par ricochet le canal qui lui est relié). Donc la suppression "détache" le fichier du canal qui reste alors la seule mémoire du fichier d'origine. Hélas si le code crashe à ce moment là...