Si c'est juste l'adresse MAC :
MAC=$(cat /sys/class/net/<ifname>/address)
Tu peux regarder également /sys/class/net/<ifname>/operstate pour savoir
si l'interface est up ou down ; voir
<https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net>
pour d'autres informations disponibles.
Ok merci. Ce sont des manières de faire que je ne connaissais pas.
Personnellement je faisais ça :
mac=$(ip link show eth0 | awk '/link/ether/ {print $2}')
Mais du coup, est-ce que c'est mieux de passer par l'arborescence /sys/ ?
Par exemple, est-ce que je n'ai pas intérêt à rester sur du « haut » niveau
avec la commande "ip" plutôt que d'utiliser l'arbo /sys/ qui, peut-être,
pourra changer avec l'évolution du noyau Linux ? Je ne dis pas que c'est
le cas bien sûr, je me pose la question. Après la sortie de "ip" sera-t-elle
plus stable que l'arbo /sys/ pas sûr non plus...
Pour l'IP, il faut bricoler :
<http://unix.stackexchange.com/questions/119269/how-to-get-ip-address-using-shell-script>
Soit, par exemple, si tu n'as pas besoin de la longueur du préfixe :
ip addr | awk '/scope global/{split($2, a, "/"); print a[1]}'
Ok, au passage je découvre la fonction split() de awk.
Comme tu dis, faut bricoler un peu. Une option --json (ou n'importe quoi qui
puisse se parser facilement je me moque que ce soit du json en particulier)
aurait été commode je trouve. Et je constate que de telle option sont quand
même souvent présentes mais pas là.
Si c'est juste l'adresse MAC :
MAC=$(cat /sys/class/net/<ifname>/address)
Tu peux regarder également /sys/class/net/<ifname>/operstate pour savoir
si l'interface est up ou down ; voir
<https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net>
pour d'autres informations disponibles.
Ok merci. Ce sont des manières de faire que je ne connaissais pas.
Personnellement je faisais ça :
mac=$(ip link show eth0 | awk '/link/ether/ {print $2}')
Mais du coup, est-ce que c'est mieux de passer par l'arborescence /sys/ ?
Par exemple, est-ce que je n'ai pas intérêt à rester sur du « haut » niveau
avec la commande "ip" plutôt que d'utiliser l'arbo /sys/ qui, peut-être,
pourra changer avec l'évolution du noyau Linux ? Je ne dis pas que c'est
le cas bien sûr, je me pose la question. Après la sortie de "ip" sera-t-elle
plus stable que l'arbo /sys/ pas sûr non plus...
Pour l'IP, il faut bricoler :
<http://unix.stackexchange.com/questions/119269/how-to-get-ip-address-using-shell-script>
Soit, par exemple, si tu n'as pas besoin de la longueur du préfixe :
ip addr | awk '/scope global/{split($2, a, "/"); print a[1]}'
Ok, au passage je découvre la fonction split() de awk.
Comme tu dis, faut bricoler un peu. Une option --json (ou n'importe quoi qui
puisse se parser facilement je me moque que ce soit du json en particulier)
aurait été commode je trouve. Et je constate que de telle option sont quand
même souvent présentes mais pas là.
Si c'est juste l'adresse MAC :
MAC=$(cat /sys/class/net/<ifname>/address)
Tu peux regarder également /sys/class/net/<ifname>/operstate pour savoir
si l'interface est up ou down ; voir
<https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net>
pour d'autres informations disponibles.
Ok merci. Ce sont des manières de faire que je ne connaissais pas.
Personnellement je faisais ça :
mac=$(ip link show eth0 | awk '/link/ether/ {print $2}')
Mais du coup, est-ce que c'est mieux de passer par l'arborescence /sys/ ?
Par exemple, est-ce que je n'ai pas intérêt à rester sur du « haut » niveau
avec la commande "ip" plutôt que d'utiliser l'arbo /sys/ qui, peut-être,
pourra changer avec l'évolution du noyau Linux ? Je ne dis pas que c'est
le cas bien sûr, je me pose la question. Après la sortie de "ip" sera-t-elle
plus stable que l'arbo /sys/ pas sûr non plus...
Pour l'IP, il faut bricoler :
<http://unix.stackexchange.com/questions/119269/how-to-get-ip-address-using-shell-script>
Soit, par exemple, si tu n'as pas besoin de la longueur du préfixe :
ip addr | awk '/scope global/{split($2, a, "/"); print a[1]}'
Ok, au passage je découvre la fonction split() de awk.
Comme tu dis, faut bricoler un peu. Une option --json (ou n'importe quoi qui
puisse se parser facilement je me moque que ce soit du json en particulier)
aurait été commode je trouve. Et je constate que de telle option sont quand
même souvent présentes mais pas là.
Aucune idée, les deux ont à peu près le même âge ; soit un peu plus de
10 ans. Si tu veux vraiment du haut niveau, utilise Python avec
netifaces ou Perl avec Net::Interface (ou autre chose qui propose
l'équivalent).
Mais il te faut bien un langage de haut niveau pour analyser la sortie
json donc je ne vois pas trop l'intérêt.
Pour ma part, je n'ai jamais utilisé une commande qui me sort du json et,
d'ailleurs, ça ne court pas les rues :
% ls /usr/share/man/man8 | wc -l
1003
% for f in /usr/share/man/man8/*; do zgrep -il json "$f"; done | wc -l
11
% ls /usr/share/man/man1 | wc -l
3250
% for f in /usr/share/man/man1/*; do zgrep -il json "$f"; done | wc -l
23
Soit à peu près 0.8 % (je n'ai pas été vérifier si ce sont bien des
options).
Aucune idée, les deux ont à peu près le même âge ; soit un peu plus de
10 ans. Si tu veux vraiment du haut niveau, utilise Python avec
netifaces ou Perl avec Net::Interface (ou autre chose qui propose
l'équivalent).
Mais il te faut bien un langage de haut niveau pour analyser la sortie
json donc je ne vois pas trop l'intérêt.
Pour ma part, je n'ai jamais utilisé une commande qui me sort du json et,
d'ailleurs, ça ne court pas les rues :
% ls /usr/share/man/man8 | wc -l
1003
% for f in /usr/share/man/man8/*; do zgrep -il json "$f"; done | wc -l
11
% ls /usr/share/man/man1 | wc -l
3250
% for f in /usr/share/man/man1/*; do zgrep -il json "$f"; done | wc -l
23
Soit à peu près 0.8 % (je n'ai pas été vérifier si ce sont bien des
options).
Aucune idée, les deux ont à peu près le même âge ; soit un peu plus de
10 ans. Si tu veux vraiment du haut niveau, utilise Python avec
netifaces ou Perl avec Net::Interface (ou autre chose qui propose
l'équivalent).
Mais il te faut bien un langage de haut niveau pour analyser la sortie
json donc je ne vois pas trop l'intérêt.
Pour ma part, je n'ai jamais utilisé une commande qui me sort du json et,
d'ailleurs, ça ne court pas les rues :
% ls /usr/share/man/man8 | wc -l
1003
% for f in /usr/share/man/man8/*; do zgrep -il json "$f"; done | wc -l
11
% ls /usr/share/man/man1 | wc -l
3250
% for f in /usr/share/man/man1/*; do zgrep -il json "$f"; done | wc -l
23
Soit à peu près 0.8 % (je n'ai pas été vérifier si ce sont bien des
options).
Mais il te faut bien un langage de haut niveau pour analyser la sortie
json donc je ne vois pas trop l'intérêt.
Encore une fois, json, csv, xml ou n'importe quoi d'autre, je m'en moque.
J'ai dit json parce que c'est un peu le truc à la mode en ce moment mais
je voulais simplement signifier par là une option pour pouvoir parser la
sortie facilement et de manière robuste dans un script (il semblait pourtant
avoir bien précisé que le json en soi je me moque).
Par exemple, dans le cas du json, tu as la commande jq qui te permet de
récupérer facilement une donnée. Mais si c'est du csv et bien je dirais
que awk fait parfaitement l'affaire etc.
Ce que je veux dire par exemple, c'est qu'il me semble que quelque
chose comme :
ip addr show eth0 | awk '/scope global/{split($2, a, "/"); print a[1]}'
est plus fragile (et moins lisible aussi) qu'un truc (complètement fictif
donc) comme :
ip addr show eth0 --json | jq --raw-output '.["addresses"][0]'
Tiens par exemple, je suis tombé sur la commande nmcli (issue du paquet
network-manager). Ça tombe bien, ça tombe pile dans le sujet du fil
pour savoir si une interface est wireless ou non :
~$ nmcli --field device,type,state dev status
DEVICE TYPE STATE
wlan0 802-11-wireless unavailable
eth1 802-3-ethernet connected
eth0 802-3-ethernet connected
Bon, ok, là pour le coup c'est pas dur à parser vu qu'on a déjà un csv en
fait. Mais les développeurs de cette commande ont été sympas, ils ont prévu
l'option --terse :
-t, --terse
Output is terse. This mode is designed and suitable for
computer (script) processing.
Ce qui donne :
~$ nmcli --terse --field device,type,state dev status
wlan0:802-11-wireless:unavailable
eth1:802-3-ethernet:connected
eth0:802-3-ethernet:connected
Je me trompe peut-être mais il me semble que ce n'est pas rare d'avoir
une commande qui structure sa sortie pour la rendre plus facilement parsable
dans un script.
Mais il te faut bien un langage de haut niveau pour analyser la sortie
json donc je ne vois pas trop l'intérêt.
Encore une fois, json, csv, xml ou n'importe quoi d'autre, je m'en moque.
J'ai dit json parce que c'est un peu le truc à la mode en ce moment mais
je voulais simplement signifier par là une option pour pouvoir parser la
sortie facilement et de manière robuste dans un script (il semblait pourtant
avoir bien précisé que le json en soi je me moque).
Par exemple, dans le cas du json, tu as la commande jq qui te permet de
récupérer facilement une donnée. Mais si c'est du csv et bien je dirais
que awk fait parfaitement l'affaire etc.
Ce que je veux dire par exemple, c'est qu'il me semble que quelque
chose comme :
ip addr show eth0 | awk '/scope global/{split($2, a, "/"); print a[1]}'
est plus fragile (et moins lisible aussi) qu'un truc (complètement fictif
donc) comme :
ip addr show eth0 --json | jq --raw-output '.["addresses"][0]'
Tiens par exemple, je suis tombé sur la commande nmcli (issue du paquet
network-manager). Ça tombe bien, ça tombe pile dans le sujet du fil
pour savoir si une interface est wireless ou non :
~$ nmcli --field device,type,state dev status
DEVICE TYPE STATE
wlan0 802-11-wireless unavailable
eth1 802-3-ethernet connected
eth0 802-3-ethernet connected
Bon, ok, là pour le coup c'est pas dur à parser vu qu'on a déjà un csv en
fait. Mais les développeurs de cette commande ont été sympas, ils ont prévu
l'option --terse :
-t, --terse
Output is terse. This mode is designed and suitable for
computer (script) processing.
Ce qui donne :
~$ nmcli --terse --field device,type,state dev status
wlan0:802-11-wireless:unavailable
eth1:802-3-ethernet:connected
eth0:802-3-ethernet:connected
Je me trompe peut-être mais il me semble que ce n'est pas rare d'avoir
une commande qui structure sa sortie pour la rendre plus facilement parsable
dans un script.
Mais il te faut bien un langage de haut niveau pour analyser la sortie
json donc je ne vois pas trop l'intérêt.
Encore une fois, json, csv, xml ou n'importe quoi d'autre, je m'en moque.
J'ai dit json parce que c'est un peu le truc à la mode en ce moment mais
je voulais simplement signifier par là une option pour pouvoir parser la
sortie facilement et de manière robuste dans un script (il semblait pourtant
avoir bien précisé que le json en soi je me moque).
Par exemple, dans le cas du json, tu as la commande jq qui te permet de
récupérer facilement une donnée. Mais si c'est du csv et bien je dirais
que awk fait parfaitement l'affaire etc.
Ce que je veux dire par exemple, c'est qu'il me semble que quelque
chose comme :
ip addr show eth0 | awk '/scope global/{split($2, a, "/"); print a[1]}'
est plus fragile (et moins lisible aussi) qu'un truc (complètement fictif
donc) comme :
ip addr show eth0 --json | jq --raw-output '.["addresses"][0]'
Tiens par exemple, je suis tombé sur la commande nmcli (issue du paquet
network-manager). Ça tombe bien, ça tombe pile dans le sujet du fil
pour savoir si une interface est wireless ou non :
~$ nmcli --field device,type,state dev status
DEVICE TYPE STATE
wlan0 802-11-wireless unavailable
eth1 802-3-ethernet connected
eth0 802-3-ethernet connected
Bon, ok, là pour le coup c'est pas dur à parser vu qu'on a déjà un csv en
fait. Mais les développeurs de cette commande ont été sympas, ils ont prévu
l'option --terse :
-t, --terse
Output is terse. This mode is designed and suitable for
computer (script) processing.
Ce qui donne :
~$ nmcli --terse --field device,type,state dev status
wlan0:802-11-wireless:unavailable
eth1:802-3-ethernet:connected
eth0:802-3-ethernet:connected
Je me trompe peut-être mais il me semble que ce n'est pas rare d'avoir
une commande qui structure sa sortie pour la rendre plus facilement parsable
dans un script.
Détrompe-toi, il y a tellement de format dit CSV (ou plutôt DSV) :
séparateur « t », « , » pour les anglophone, « ; » pour la France car
« , » sert de séparateur décimal ; on peut vouloir échapper le
séparateur avec un « » ou entourer un champ avec des « '' » ou des
« "" » pour mettre le séparateur dedans.
Bref, ce n'est pas toujours simple et ça peut surtout partir en vrille
sévère si l'entrée diffère légèrement un beau jour. Il en va de même
pour XML qui nécessite une bibliothèque (un module dans un langage plus
au niveau) pour que ça fonctionne correctement et surtout que tu n'aies
pas à te prendre la tête car d'autre l'on fait pour toi.
Je préférerais un truc comme :
ip addr show dev eth0 -o address # renvoie l'adresse IP
ip link show dev eth0 -o address # renvoie l'adresse MAC
Comme ça il n'y a pas à bricoler derrière.
~$ nmcli --field device,type,state dev status
DEVICE TYPE STATE
wlan0 802-11-wireless unavailable
eth1 802-3-ethernet connected
eth0 802-3-ethernet connected
Bon, ok, là pour le coup c'est pas dur à parser vu qu'on a déjà un csv en
fait. Mais les développeurs de cette commande ont été sympas, ils ont prévu
l'option --terse :
-t, --terse
Output is terse. This mode is designed and suitable for
computer (script) processing.
Ce qui donne :
~$ nmcli --terse --field device,type,state dev status
wlan0:802-11-wireless:unavailable
eth1:802-3-ethernet:connected
eth0:802-3-ethernet:connected
Mauvais exemple. Imagine que je fasse de l'IP aliasing et que, par
conséquent, mes interfaces soient nommées « eth0 », « eth0:0 »,
« eth0:1 » ; il y a de forte chance que le script qui découpe sur « : »
se vautre lamentablement lorsqu'il va vouloir récupérer le type.
Je me trompe peut-être mais il me semble que ce n'est pas rare d'avoir
une commande qui structure sa sortie pour la rendre plus facilement parsable
dans un script.
C'est possible. J'ai surtout en tête l'option « -o » de ps(1) qui permet
effectivement d'extraire facilement les données que l'on souhaite.
Détrompe-toi, il y a tellement de format dit CSV (ou plutôt DSV) :
séparateur « t », « , » pour les anglophone, « ; » pour la France car
« , » sert de séparateur décimal ; on peut vouloir échapper le
séparateur avec un « » ou entourer un champ avec des « '' » ou des
« "" » pour mettre le séparateur dedans.
Bref, ce n'est pas toujours simple et ça peut surtout partir en vrille
sévère si l'entrée diffère légèrement un beau jour. Il en va de même
pour XML qui nécessite une bibliothèque (un module dans un langage plus
au niveau) pour que ça fonctionne correctement et surtout que tu n'aies
pas à te prendre la tête car d'autre l'on fait pour toi.
Je préférerais un truc comme :
ip addr show dev eth0 -o address # renvoie l'adresse IP
ip link show dev eth0 -o address # renvoie l'adresse MAC
Comme ça il n'y a pas à bricoler derrière.
~$ nmcli --field device,type,state dev status
DEVICE TYPE STATE
wlan0 802-11-wireless unavailable
eth1 802-3-ethernet connected
eth0 802-3-ethernet connected
Bon, ok, là pour le coup c'est pas dur à parser vu qu'on a déjà un csv en
fait. Mais les développeurs de cette commande ont été sympas, ils ont prévu
l'option --terse :
-t, --terse
Output is terse. This mode is designed and suitable for
computer (script) processing.
Ce qui donne :
~$ nmcli --terse --field device,type,state dev status
wlan0:802-11-wireless:unavailable
eth1:802-3-ethernet:connected
eth0:802-3-ethernet:connected
Mauvais exemple. Imagine que je fasse de l'IP aliasing et que, par
conséquent, mes interfaces soient nommées « eth0 », « eth0:0 »,
« eth0:1 » ; il y a de forte chance que le script qui découpe sur « : »
se vautre lamentablement lorsqu'il va vouloir récupérer le type.
Je me trompe peut-être mais il me semble que ce n'est pas rare d'avoir
une commande qui structure sa sortie pour la rendre plus facilement parsable
dans un script.
C'est possible. J'ai surtout en tête l'option « -o » de ps(1) qui permet
effectivement d'extraire facilement les données que l'on souhaite.
Détrompe-toi, il y a tellement de format dit CSV (ou plutôt DSV) :
séparateur « t », « , » pour les anglophone, « ; » pour la France car
« , » sert de séparateur décimal ; on peut vouloir échapper le
séparateur avec un « » ou entourer un champ avec des « '' » ou des
« "" » pour mettre le séparateur dedans.
Bref, ce n'est pas toujours simple et ça peut surtout partir en vrille
sévère si l'entrée diffère légèrement un beau jour. Il en va de même
pour XML qui nécessite une bibliothèque (un module dans un langage plus
au niveau) pour que ça fonctionne correctement et surtout que tu n'aies
pas à te prendre la tête car d'autre l'on fait pour toi.
Je préférerais un truc comme :
ip addr show dev eth0 -o address # renvoie l'adresse IP
ip link show dev eth0 -o address # renvoie l'adresse MAC
Comme ça il n'y a pas à bricoler derrière.
~$ nmcli --field device,type,state dev status
DEVICE TYPE STATE
wlan0 802-11-wireless unavailable
eth1 802-3-ethernet connected
eth0 802-3-ethernet connected
Bon, ok, là pour le coup c'est pas dur à parser vu qu'on a déjà un csv en
fait. Mais les développeurs de cette commande ont été sympas, ils ont prévu
l'option --terse :
-t, --terse
Output is terse. This mode is designed and suitable for
computer (script) processing.
Ce qui donne :
~$ nmcli --terse --field device,type,state dev status
wlan0:802-11-wireless:unavailable
eth1:802-3-ethernet:connected
eth0:802-3-ethernet:connected
Mauvais exemple. Imagine que je fasse de l'IP aliasing et que, par
conséquent, mes interfaces soient nommées « eth0 », « eth0:0 »,
« eth0:1 » ; il y a de forte chance que le script qui découpe sur « : »
se vautre lamentablement lorsqu'il va vouloir récupérer le type.
Je me trompe peut-être mais il me semble que ce n'est pas rare d'avoir
une commande qui structure sa sortie pour la rendre plus facilement parsable
dans un script.
C'est possible. J'ai surtout en tête l'option « -o » de ps(1) qui permet
effectivement d'extraire facilement les données que l'on souhaite.
On 12/05/2016 22:33, Benoit Izac wrote:Mauvais exemple. Imagine que je fasse de l'IP aliasing et que, par
conséquent, mes interfaces soient nommées « eth0 », « eth0:0 »,
« eth0:1 » ; il y a de forte chance que le script qui découpe sur « : »
se vautre lamentablement lorsqu'il va vouloir récupérer le type.
C'était juste un exemple de commande qui montrait un « effort »
(pas forcément efficace à 100%) fait pour fournir une option rendant
la sortie parsable facilement. Au passage, les aliases ne sont pas
énumérés dans la sortie sur ma Debian Wheezy (mais bon c'est un détail
ici).
On 12/05/2016 22:33, Benoit Izac wrote:
Mauvais exemple. Imagine que je fasse de l'IP aliasing et que, par
conséquent, mes interfaces soient nommées « eth0 », « eth0:0 »,
« eth0:1 » ; il y a de forte chance que le script qui découpe sur « : »
se vautre lamentablement lorsqu'il va vouloir récupérer le type.
C'était juste un exemple de commande qui montrait un « effort »
(pas forcément efficace à 100%) fait pour fournir une option rendant
la sortie parsable facilement. Au passage, les aliases ne sont pas
énumérés dans la sortie sur ma Debian Wheezy (mais bon c'est un détail
ici).
On 12/05/2016 22:33, Benoit Izac wrote:Mauvais exemple. Imagine que je fasse de l'IP aliasing et que, par
conséquent, mes interfaces soient nommées « eth0 », « eth0:0 »,
« eth0:1 » ; il y a de forte chance que le script qui découpe sur « : »
se vautre lamentablement lorsqu'il va vouloir récupérer le type.
C'était juste un exemple de commande qui montrait un « effort »
(pas forcément efficace à 100%) fait pour fournir une option rendant
la sortie parsable facilement. Au passage, les aliases ne sont pas
énumérés dans la sortie sur ma Debian Wheezy (mais bon c'est un détail
ici).
Mauvais exemple. Imagine que je fasse de l'IP aliasing et que, par
conséquent, mes interfaces soient nommées « eth0 », « eth0:0 »,
« eth0:1 » ; il y a de forte chance que le script qui découpe sur « : »
se vautre lamentablement lorsqu'il va vouloir récupérer le type.
C'était juste un exemple de commande qui montrait un « effort »
(pas forcément efficace à 100%) fait pour fournir une option rendant
la sortie parsable facilement. Au passage, les aliases ne sont pas
énumérés dans la sortie sur ma Debian Wheezy (mais bon c'est un détail
ici).
Les alias IP ne sont pas des interfaces mais des labels. Il n'y a guère
que l'antique ifconfig qui les considère comme de vraies interfaces.
Mauvais exemple. Imagine que je fasse de l'IP aliasing et que, par
conséquent, mes interfaces soient nommées « eth0 », « eth0:0 »,
« eth0:1 » ; il y a de forte chance que le script qui découpe sur « : »
se vautre lamentablement lorsqu'il va vouloir récupérer le type.
C'était juste un exemple de commande qui montrait un « effort »
(pas forcément efficace à 100%) fait pour fournir une option rendant
la sortie parsable facilement. Au passage, les aliases ne sont pas
énumérés dans la sortie sur ma Debian Wheezy (mais bon c'est un détail
ici).
Les alias IP ne sont pas des interfaces mais des labels. Il n'y a guère
que l'antique ifconfig qui les considère comme de vraies interfaces.
Mauvais exemple. Imagine que je fasse de l'IP aliasing et que, par
conséquent, mes interfaces soient nommées « eth0 », « eth0:0 »,
« eth0:1 » ; il y a de forte chance que le script qui découpe sur « : »
se vautre lamentablement lorsqu'il va vouloir récupérer le type.
C'était juste un exemple de commande qui montrait un « effort »
(pas forcément efficace à 100%) fait pour fournir une option rendant
la sortie parsable facilement. Au passage, les aliases ne sont pas
énumérés dans la sortie sur ma Debian Wheezy (mais bon c'est un détail
ici).
Les alias IP ne sont pas des interfaces mais des labels. Il n'y a guère
que l'antique ifconfig qui les considère comme de vraies interfaces.
