Question bash. Ptéte Complètement HS

Bonjour,
ça n'a pas grand chose à voir avec manjaro, cependant... Je me demandais.
Pourquoi dans bash, une affectation en "fond de tâche" n'est pas affectif ?

Exemple :

[otyugh@manjaro bash]$ a=5
[otyugh@manjaro bash]$ a=6 &
[1] 28122
[otyugh@manjaro bash]$ echo $a
5
[1]+ Fini a=6
[otyugh@manjaro bash]$ echo $a
5

Je... Suis pas sûr de comprendre ce qu'il se passe. J'ai postulé que 28122 était le processus mis en fond de "affecter 6 à $a". Cependant "fg 28122" ne donne rien !
Que s'est-il donc passé ? :rougir:

juste pour te dire que Bash faisant partie de Manjaro, ce n'est pas HS du tout

par contre, je t'avoue ne pas avoir de réponse et être aussi surpris que toi de ce résultat...

Loubrix a écrit :juste pour te dire que Bash faisant partie de Manjaro, ce n'est pas HS du tout

De fait c'est plus de l'Unix que du manjaro, dans l'idée ^^

Apparemment, si j'en crois un forum, le "&" ne veut pas dire "en background", mais "dans un sous-shell non relié au parent".

According to the Bash manual here,

If a command is terminated by the control operator ‘&’, the shell executes the command asynchronously in a subshell.

Du coup... Mhm. Une idée de comment faire pour lancer deux opérations à la fois ? Ça se nomme un "fork", ce me semble.

Je pense que dans ton exemple n'est pas le mieux choisi, puisqu'on utilise "a" des deux côtés. "a" change bien de valeur pendant l'éxécution dans le sous shell puis reprend sa valeur dans le shell.

[tutut@linuxette ~]$ a=5
[tutut@linuxette ~]$ echo $a
5
[tutut@linuxette ~]$ a=6 && echo $a &
[1] 1564
6
[tutut@linuxette ~]$ echo $a
5
[1]+  Fini                    a=6 && echo $a
[tutut@linuxette ~]$

Edit : le fork ne permet pas aux deux processus de tourner en même temps, le shell principal attend que le processus dans le sous-shell soit fini.

When the program being executed is a shell script, bash will create a new bash process using a fork. This subshell reads the lines from the shell script one line at a time. Commands on each line are read, interpreted and executed as if they would have come directly from the keyboard.

While the subshell processes each line of the script, the parent shell waits for its child process to finish. When there are no more lines in the shell script to read, the subshell terminates. The parent shell awakes and displays a new prompt.

http://www.linuxtopia.org/online_books/bash_guide_for_beginners/sect_01_03.html

Oui, et pas certain d'avoir compris ce que tu cherches.

:~$ a=5 ; b=6
:~$ expr $a + $b
11

Le besoin pratique ? Je l'ai réglé.
De fait il s'agissait d'avoir un moyen de "tuer" un processus qui dure plus de X temps.
Donc il s'agissait de lancer deux processus en même temps ; l'un fait son truc (imaginez "un sleep 12 ans" )pendant que l'autre lance un chrono, et s'il arrive en fin du décompte, interrompt le premier (on attendra donc pas 12 ans).

La commande timeout le permet.

(en pratique c'était pour conky qui bugguait quand une commande ping ne répondait pas assez vite, avec cette interruption manuelle, plus de problème)

Cependant, je me demandais comment le faire "à la main". Question de curiosité ! En C je suis quasiment sûr d'avoir vu cette commande "fork", et en java je me souviens des threads... Et, en bash ?
Cela dit ce n'est pas très important, le besoin est comblé. Mais si vous avez une idée d'une autre manière... Je suis curieux.

Pas tout compris, mais tu as la commande : jobs -p qui te donne le PID des processus lancés en background, wait qui permet de les attendre, etc...

Dans le cas du début, ta commande s'est arrêtée instantanément, car trop brève.

Fais un truc du genre sleep 100 &, si tu veux en choper une, par exemple.
Et ce ne sont pas vraiment des forks, ce sont plutôt des system().

(edit)

Un exemple simple ICI.

Dans mon cas de conky c'était : "je veux faire un ping sur google, mais s'il prend plus de 2 secondes à le faire, renvoyer tout de même une valeur". Seulement le ping, j'ai pas la main dessus s'il est lancé en foreground. Et s'il est lancé en background, je n'ai pas accès à ses valeur (qui sont dans un sous-shell).

C'est mieux avec un cas concret, hein x)

Edit : en fait ton exemple est peut être très bien. Jeeee pense. Merci.
Oui, mettre le timer en fond est pas con, je ne comprends juste pas comment il sait quel processus il doit tuer. C'est écrit "kill -s 14", mais je ne comprends pas trop le "14" ; si encore le PID était envoyé au début, pourquoi pas, mais là...

Pour le ping, tu as l'option -w, quand même ? Qui arrête, que le nb de paquets demandé soit atteint ou non.

Sinon, après le lancement d'un process, tu peux attendre, puis le tuer au bout de x secondes si pas fini.

Je ne vois pas par contre la fiabilité des réponses d'un process que tu auras tué comme ça.

Pour la communication entre un processus père et son fils, par contre, il faut passer par la messagerie, et c'est un peu plus coton, car dans le cas standard, ce sont deux processus distincts et ils ne partagent pas la même zone de donnée.

Esclapion a écrit :Pour le ping, tu as l'option -w, quand même ? Qui arrête, que le nb de paquets demandé soit atteint ou non.

Ne fonctionne pas. C'est un temps pour le le packet, en fait. Pas du ping lui-même. Et y a une différence assez conséquente, si j'en crois des pings qui prennent 5-6 secondes à me dire que le packet à pris 300ms. Pourquoi ? C'est un mystère pour moi. Mais les faits prouvent que -W marche pas dans ce cas-là (et de beaucoup).

Ou bien j'ai pas pigé le fonctionnement de -W ><
Ce qui est sûr c'est que "ping -W 1" prend plus de 3 secondes à répondre à conky, ce qui m'a rendu perplexe.

(Illustration : un timer primaire & les output d'un "ping google.fr -W 1"

SECONDE : 1
SECONDE : 2
64 bytes from par03s03-in-f24.1e100.net (173.194.34.56): icmp_seq=47 ttl=53 time=326 ms
SECONDE : 3
SECONDE : 4
SECONDE : 5
64 bytes from par03s03-in-f24.1e100.net (173.194.34.56): icmp_seq=50 ttl=53 time=297 ms
SECONDE : 6
64 bytes from par03s03-in-f24.1e100.net (173.194.34.56): icmp_seq=51 ttl=53 time=314 ms
SECONDE : 7
64 bytes from par03s03-in-f24.1e100.net (173.194.34.56): icmp_seq=52 ttl=53 time=301 ms
SECONDE : 8
64 bytes from par03s03-in-f24.1e100.net (173.194.34.56): icmp_seq=54 ttl=53 time=314 ms
SECONDE : 9
SECONDE : 10
SECONDE : 11
SECONDE : 12
SECONDE : 13
SECONDE : 14
SECONDE : 15
64 bytes from par03s03-in-f24.1e100.net (173.194.34.56): icmp_seq=55 ttl=53 time=398 ms
64 bytes from par03s03-in-f24.1e100.net (173.194.34.56): icmp_seq=56 ttl=53 time=319 ms
SECONDE : 16
SECONDE : 17
SECONDE : 18
SECONDE : 19
SECONDE : 20
SECONDE : 21
64 bytes from par03s03-in-f24.1e100.net (173.194.34.56): icmp_seq=57 ttl=53 time=246 ms
SECONDE : 22
SECONDE : 23
SECONDE : 24
SECONDE : 25

Attention, j'ai parlé de -w, pas -W. Le time-out par défaut est de 4", je crois.

Essaie :

ping google.fr
ping -w 1 google.fr
ping -w 2 google.fr

Un "ha le fail" s'impose. :rigole:

J'aurais pu genre, gagner quelques heures sur un putain de une satanée majsucule. Comme quoi le réflexe "man" est pas suffisant. Faut bien lire, en plus ~

http://i.imgur.com/snknD.gif

Edit : pardonnez mon langage, c'est l'émotion !

y a aussi un autre truc: quand tu fais "ping google.fr", Ping indique le temps mis par la requête, mais (à mon avis) ne tient pas compte du temps pris par la résolution de nom (l'interrogation du serveur DNS).
refait le test du timer avec "ping 173.194.34.56", j'ai tendance à croire que tu auras un résultat identique au niveau du "time=xxx ms", mais que tu auras bien plus de requêtes dans un délai donné.
je peux me tromper bien sûr...

Une fois la première résolution DNS faite, ça devrait être pareil, non ? Parce que la correspondance va aller dans le cache.

pas sûr ça, et je vois pas bien comment vérifier; d'ailleurs, fais un ping vers ton serveur DNS, tu vas voir que c'est assez long...

edit: après vérification, il n'y a pas de cache DNS sur nos système par défaut; d'ailleurs, si je fais une requête DNS:

[david@asusx50vl ~]$ dig google.fr

; <<>> DiG 9.9.2-P2 <<>> google.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51502
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.fr.                     IN      A

;; ANSWER SECTION:
google.fr.              209     IN      A       74.125.132.94

;; Query time: 51 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Mon Aug 19 20:27:12 2013
;; MSG SIZE  rcvd: 43

et si j'en fais une deuxième, sur le même nom (je mets que la fin, le reste change pas):

;; Query time: 4 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Mon Aug 19 20:27:38 2013
;; MSG SIZE  rcvd: 43

on voit bien que l'adresse a été demandé à chaque fois au 192.168.1.1 port 53, ce qui correspond à ma Neufbox qui fournit un relai DNS et l'indique à mon système au moment de la transaction DHCP: mon système n'a donc aucun cache où il stocke ça et est donc obligé de demander à chaque fois.

mais on voit quand même que la première fois ça a mis 51 ms, alors qu'à la deuxième (et les suivantes si on recommence) ça a mis seulement 4 ms; c'est parce que ma Neufbox, elle, crée un cache (Dnsmask); la première fois, elle a du elle-même demander aux serveurs DNS du FAI, mais la deuxième elle a pas eu besoin puisqu'elle l'avait en cache, d'où le gain de temps.
évidemment, le cache de la box ne garde pas ça bien longtemps (et comme je vais rarement chez Google) donc la première fois a été longue...
et d'ailleurs, elle garde vraiment pas longtemps, car le temps d'écrire ceci, je refais une demande et j'ai 82 ms.
un moyen de s'affranchir de ce temps de latence est d'installer Dnsmask en local sur sa machine.