script : savoir si c'est la première exécution depuis le dernier démarrage
22 réponses
Francois Lafont
Bonjour à tous,
J'ai un script sur une Debian Squeeze qui s'exécute de temps en temps de
manière automatique (en fait à chaque fois que la fenêtre de connexion
apparaît, c'est-à-dire à chaque démarrage mais aussi après chaque
fermeture de session). L'exécution se fait via le compte root.
Je voudrais affiner le script pour qu'il se comporte légèrement
différemment suivant que l'exécution est la première depuis le dernier
démarrage ou non. Comment faire cela de manière fiable ?
J'avais pensé écrire un fichier « pipeau » dans /tmp, profitant du fait
que /tmp est vidé à chaque démarrage il me semble. Du coup, dans le
script, ça donnerait un truc dans le genre ça :
if [ -e /tmp/pipeau ]; then
# Alors ce n'est pas la première exécution
# depuis le dernier démarrage de la machine.
else
# Alors c'est la première exécution
# depuis le dernier démarrage de la machine.
# Du coup on crée le fichier.
touch /tmp/pipeau
fi
Mais je ne sais pas si c'est une bonne façon de faire :
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors
qu'il n'y a pas eu encore redémarrage ?
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà
dans /tmp après tout (même si c'est hautement non probable) ?
Du coup, je me dis qu'on peut peut-être s'y prendre mieux que ça. :-)
L'idée c'est que lorsqu'il y a tentative d'écriture dans un fichier, il ne peut avoir simultanéité car le noyau ne le permet pas, c'est ça ?
Non, contrairement à windows, linux ne permet pas vraiment ça. Par contre, il permet de lui demander "crée moi ce fichier si il n'existe pas, et jette moi sinon", ce que fait > lorsqu'on a fait un set -C.
Que veux-tu dire par « panique » ? Si on a un code d'erreur en retour, c'est suffisant pour le test, non ? Pourquoi vouloir faire en sorte qu'il y ait « panique » ?
Je ne veux pas faire en sorte, mais c'est juste comme ça que ça se passe.
if : > blah; then ploum; else plim; fi
n'exécute ni ploum ni plim si la redirection échoue.
Ah, monter un tmpfs peut être une bonne chose car là je suis sûr qu'à chaque redémarrage, je repars sur un répertoire vide.
Avec l'inconvénient que si le script a été appellé avant le montage, boum.
if ! mountpoint "$rep"; then mount -t tmpfs -o size=1M tmpfs "$rep" fi
Toujours une race-condition.
Francois Lafont :
L'idée c'est que lorsqu'il y a tentative d'écriture dans un fichier, il ne
peut avoir simultanéité car le noyau ne le permet pas, c'est ça ?
Non, contrairement à windows, linux ne permet pas vraiment ça. Par contre,
il permet de lui demander "crée moi ce fichier si il n'existe pas, et jette
moi sinon", ce que fait > lorsqu'on a fait un set -C.
Que veux-tu dire par « panique » ? Si on a un code d'erreur en retour,
c'est suffisant pour le test, non ? Pourquoi vouloir faire en sorte
qu'il y ait « panique » ?
Je ne veux pas faire en sorte, mais c'est juste comme ça que ça se passe.
if : > blah; then ploum; else plim; fi
n'exécute ni ploum ni plim si la redirection échoue.
Ah, monter un tmpfs peut être une bonne chose car là je suis sûr qu'à
chaque redémarrage, je repars sur un répertoire vide.
Avec l'inconvénient que si le script a été appellé avant le montage, boum.
if ! mountpoint "$rep"; then
mount -t tmpfs -o size=1M tmpfs "$rep"
fi
L'idée c'est que lorsqu'il y a tentative d'écriture dans un fichier, il ne peut avoir simultanéité car le noyau ne le permet pas, c'est ça ?
Non, contrairement à windows, linux ne permet pas vraiment ça. Par contre, il permet de lui demander "crée moi ce fichier si il n'existe pas, et jette moi sinon", ce que fait > lorsqu'on a fait un set -C.
Que veux-tu dire par « panique » ? Si on a un code d'erreur en retour, c'est suffisant pour le test, non ? Pourquoi vouloir faire en sorte qu'il y ait « panique » ?
Je ne veux pas faire en sorte, mais c'est juste comme ça que ça se passe.
if : > blah; then ploum; else plim; fi
n'exécute ni ploum ni plim si la redirection échoue.
Ah, monter un tmpfs peut être une bonne chose car là je suis sûr qu'à chaque redémarrage, je repars sur un répertoire vide.
Avec l'inconvénient que si le script a été appellé avant le montage, boum.
if ! mountpoint "$rep"; then mount -t tmpfs -o size=1M tmpfs "$rep" fi
Toujours une race-condition.
Nicolas George
Luc Habert, dans le message <jog8jk$pla$, a écrit :
if : > blah; then ploum; else plim; fi n'exécute ni ploum ni plim si la redirection échoue.
Mais on peut ramener au comportement habituel en mettant la redirection dans un sous-shell avec des parenthèses.
Luc Habert, dans le message <jog8jk$pla$1@news.ens.fr>, a écrit :
if : > blah; then ploum; else plim; fi
n'exécute ni ploum ni plim si la redirection échoue.
Mais on peut ramener au comportement habituel en mettant la redirection dans
un sous-shell avec des parenthèses.
Luc Habert, dans le message <jog8jk$pla$, a écrit :
if : > blah; then ploum; else plim; fi n'exécute ni ploum ni plim si la redirection échoue.
Mais on peut ramener au comportement habituel en mettant la redirection dans un sous-shell avec des parenthèses.
Francois Lafont
Le 10/05/2012 13:25, Luc Habert a écrit :
L'idée c'est que lorsqu'il y a tentative d'écriture dans un fichier, il ne peut avoir simultanéité car le noyau ne le permet pas, c'est ça ?
Non, contrairement à windows, linux ne permet pas vraiment ça.
Pas sûr d'avoir compris cette double négation. Le noyau ne permet pas l'écriture simultanée sur un même fichier : c'est juste ou faux ? :-)
Par contre, il permet de lui demander "crée moi ce fichier si il n'existe pas, et jette moi sinon", ce que fait > lorsqu'on a fait un set -C.
Ok.
Que veux-tu dire par « panique » ? Si on a un code d'erreur en retour, c'est suffisant pour le test, non ? Pourquoi vouloir faire en sorte qu'il y ait « panique » ?
Je ne veux pas faire en sorte, mais c'est juste comme ça que ça se passe.
if : > blah; then ploum; else plim; fi
n'exécute ni ploum ni plim si la redirection échoue.
Je ne constate pas cela sur mon bash :
-------------------------------------- $ if : > out; then echo Ok; else echo PB; fi bash: out: Permission non accordée PB --------------------------------------
Ah, monter un tmpfs peut être une bonne chose car là je suis sûr qu'à chaque redémarrage, je repars sur un répertoire vide.
Avec l'inconvénient que si le script a été appellé avant le montage, boum.
C'est le script qui fait le montage.
if ! mountpoint "$rep"; then mount -t tmpfs -o size=1M tmpfs "$rep" fi
Toujours une race-condition.
Ah, zut. :-)
Très honnêtement, la probabilité d'avoir une race-condition me semble vraiment nulle et en plus le script ne fait pas grand chose de méchant. Mes craintes portaient surtout sur /tmp et la « non maîtrise » de son contenu ce qui est résolu, il me semble, avec un montage de type tmpfs. Du coup, je suis quand même plutôt satisfait, même si je ne nie pas que le problème de race-condition demeure.
-- François Lafont
Le 10/05/2012 13:25, Luc Habert a écrit :
L'idée c'est que lorsqu'il y a tentative d'écriture dans un fichier, il ne
peut avoir simultanéité car le noyau ne le permet pas, c'est ça ?
Non, contrairement à windows, linux ne permet pas vraiment ça.
Pas sûr d'avoir compris cette double négation. Le noyau ne permet pas
l'écriture simultanée sur un même fichier : c'est juste ou faux ? :-)
Par contre,
il permet de lui demander "crée moi ce fichier si il n'existe pas, et jette
moi sinon", ce que fait > lorsqu'on a fait un set -C.
Ok.
Que veux-tu dire par « panique » ? Si on a un code d'erreur en retour,
c'est suffisant pour le test, non ? Pourquoi vouloir faire en sorte
qu'il y ait « panique » ?
Je ne veux pas faire en sorte, mais c'est juste comme ça que ça se passe.
if : > blah; then ploum; else plim; fi
n'exécute ni ploum ni plim si la redirection échoue.
Je ne constate pas cela sur mon bash :
--------------------------------------
$ if : > out; then echo Ok; else echo PB; fi
bash: out: Permission non accordée
PB
--------------------------------------
Ah, monter un tmpfs peut être une bonne chose car là je suis sûr qu'à
chaque redémarrage, je repars sur un répertoire vide.
Avec l'inconvénient que si le script a été appellé avant le montage, boum.
C'est le script qui fait le montage.
if ! mountpoint "$rep"; then
mount -t tmpfs -o size=1M tmpfs "$rep"
fi
Toujours une race-condition.
Ah, zut. :-)
Très honnêtement, la probabilité d'avoir une race-condition me semble
vraiment nulle et en plus le script ne fait pas grand chose de méchant.
Mes craintes portaient surtout sur /tmp et la « non maîtrise » de son
contenu ce qui est résolu, il me semble, avec un montage de type tmpfs.
Du coup, je suis quand même plutôt satisfait, même si je ne nie pas que
le problème de race-condition demeure.
L'idée c'est que lorsqu'il y a tentative d'écriture dans un fichier, il ne peut avoir simultanéité car le noyau ne le permet pas, c'est ça ?
Non, contrairement à windows, linux ne permet pas vraiment ça.
Pas sûr d'avoir compris cette double négation. Le noyau ne permet pas l'écriture simultanée sur un même fichier : c'est juste ou faux ? :-)
Par contre, il permet de lui demander "crée moi ce fichier si il n'existe pas, et jette moi sinon", ce que fait > lorsqu'on a fait un set -C.
Ok.
Que veux-tu dire par « panique » ? Si on a un code d'erreur en retour, c'est suffisant pour le test, non ? Pourquoi vouloir faire en sorte qu'il y ait « panique » ?
Je ne veux pas faire en sorte, mais c'est juste comme ça que ça se passe.
if : > blah; then ploum; else plim; fi
n'exécute ni ploum ni plim si la redirection échoue.
Je ne constate pas cela sur mon bash :
-------------------------------------- $ if : > out; then echo Ok; else echo PB; fi bash: out: Permission non accordée PB --------------------------------------
Ah, monter un tmpfs peut être une bonne chose car là je suis sûr qu'à chaque redémarrage, je repars sur un répertoire vide.
Avec l'inconvénient que si le script a été appellé avant le montage, boum.
C'est le script qui fait le montage.
if ! mountpoint "$rep"; then mount -t tmpfs -o size=1M tmpfs "$rep" fi
Toujours une race-condition.
Ah, zut. :-)
Très honnêtement, la probabilité d'avoir une race-condition me semble vraiment nulle et en plus le script ne fait pas grand chose de méchant. Mes craintes portaient surtout sur /tmp et la « non maîtrise » de son contenu ce qui est résolu, il me semble, avec un montage de type tmpfs. Du coup, je suis quand même plutôt satisfait, même si je ne nie pas que le problème de race-condition demeure.
-- François Lafont
Francois Lafont
Le 10/05/2012 13:17, Marc Boyer a écrit :
Mon point de vue serait un peu différent: soit tu désires faire un truc vraiment fiable, et il faut insérer ta commande dans la liste des scripts exécutés au démarrage et à l'extinction de ta machine,
Ah, je sais que ça serait le truc propre mais j'aimerais bien éviter et faire un truc plus « artisanal ». :-)
soit tu veux rester en dehors,
Oui.
et de manière moins précise, tu peux par exemple comparer la date de création de ton fichier avec l'uptime de la machine.
Au delà de l'aspect conversion de date, mesure d'écart qui je verrai plus tard, je ne vois pas trop ce que tu veux dire.
Avec l'uptime, j'ai la possibilité de connaître la date de démarrage du système. Ok. Mais ensuite. Cette date, tu veux que je la « compare » avec la date de dernière modif (et donc de création) du fichier, c'est ça ? Ok. Mais alors qu'entends-tu par « comparer » ? Mesurer l'écart ? Mais dans ce cas, comment fixer une règle de décision ? Quel seuil fixer ?
-- François Lafont
Le 10/05/2012 13:17, Marc Boyer a écrit :
Mon point de vue serait un peu différent: soit tu désires faire
un truc vraiment fiable, et il faut insérer ta commande dans la
liste des scripts exécutés au démarrage et à l'extinction de
ta machine,
Ah, je sais que ça serait le truc propre mais j'aimerais bien éviter et
faire un truc plus « artisanal ». :-)
soit tu veux rester en dehors,
Oui.
et de manière moins
précise, tu peux par exemple comparer la date de création de
ton fichier avec l'uptime de la machine.
Au delà de l'aspect conversion de date, mesure d'écart qui je verrai
plus tard, je ne vois pas trop ce que tu veux dire.
Avec l'uptime, j'ai la possibilité de connaître la date de démarrage du
système. Ok. Mais ensuite. Cette date, tu veux que je la « compare »
avec la date de dernière modif (et donc de création) du fichier, c'est
ça ? Ok. Mais alors qu'entends-tu par « comparer » ? Mesurer l'écart ?
Mais dans ce cas, comment fixer une règle de décision ? Quel seuil fixer ?
Mon point de vue serait un peu différent: soit tu désires faire un truc vraiment fiable, et il faut insérer ta commande dans la liste des scripts exécutés au démarrage et à l'extinction de ta machine,
Ah, je sais que ça serait le truc propre mais j'aimerais bien éviter et faire un truc plus « artisanal ». :-)
soit tu veux rester en dehors,
Oui.
et de manière moins précise, tu peux par exemple comparer la date de création de ton fichier avec l'uptime de la machine.
Au delà de l'aspect conversion de date, mesure d'écart qui je verrai plus tard, je ne vois pas trop ce que tu veux dire.
Avec l'uptime, j'ai la possibilité de connaître la date de démarrage du système. Ok. Mais ensuite. Cette date, tu veux que je la « compare » avec la date de dernière modif (et donc de création) du fichier, c'est ça ? Ok. Mais alors qu'entends-tu par « comparer » ? Mesurer l'écart ? Mais dans ce cas, comment fixer une règle de décision ? Quel seuil fixer ?
-- François Lafont
Sergio
Le Thu, 10 May 2012 13:15:36 +0200, Francois Lafont a écrit :
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Clairement non. Mon /tmp est plein de fichiers temporaires « anciens » (antérieurs au dernier démarrage) ; leur effacement est configurable (opensuse 11.2) en fonction de l'âge.
Ah, et bien j'apprends quelque chose car je pensais que /tmp était toujours vidé à chaque redémarrage.
Ça dépend des scripts au démarrage. La plupart des distributions le font par défaut, mais on ne connaît jamais les vicieux...
Sinon, tu vérifie, s'il existe, que son âge est inférieur à l'uptime...
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le Thu, 10 May 2012 13:15:36 +0200, Francois Lafont a écrit :
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Clairement non. Mon /tmp est plein de fichiers temporaires « anciens »
(antérieurs au dernier démarrage) ; leur effacement est configurable
(opensuse 11.2) en fonction de l'âge.
Ah, et bien j'apprends quelque chose car je pensais que /tmp était
toujours vidé à chaque redémarrage.
Ça dépend des scripts au démarrage. La plupart des distributions le font
par défaut, mais on ne connaît jamais les vicieux...
Sinon, tu vérifie, s'il existe, que son âge est inférieur à l'uptime...
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Le Thu, 10 May 2012 13:15:36 +0200, Francois Lafont a écrit :
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Clairement non. Mon /tmp est plein de fichiers temporaires « anciens » (antérieurs au dernier démarrage) ; leur effacement est configurable (opensuse 11.2) en fonction de l'âge.
Ah, et bien j'apprends quelque chose car je pensais que /tmp était toujours vidé à chaque redémarrage.
Ça dépend des scripts au démarrage. La plupart des distributions le font par défaut, mais on ne connaît jamais les vicieux...
Sinon, tu vérifie, s'il existe, que son âge est inférieur à l'uptime...
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Luc.Habert.00__arjf
Francois Lafont :
Le noyau ne permet pas l'écriture simultanée sur un même fichier : c'est juste ou faux ? :-)
Le noyau ne permet pas vraiment d'interdire l'écriture simultanée. Il y a des locks, mais ça n'interdit pas l'écriture, il faut que tous les programmes susceptibles d'écrire tentent explicitement d'acquerir un lock avant d'écrire.
Je disais pas vraiment, parce qu'un jour, un gus défoncé a décidé que ça serait une bonne idée que si le fichier a un bit sgid, alors un lock interdit vraiment les writes de la part d'autres programmes. Je sais pas si c'est encore supporté sous linux, ou si ils ont pas ajouté une autre feature mutante du style.
Je ne constate pas cela sur mon bash :
Oui, il y a des chances que ça varie en fonction du shell.
Francois Lafont :
Le noyau ne permet pas l'écriture simultanée sur un même fichier : c'est
juste ou faux ? :-)
Le noyau ne permet pas vraiment d'interdire l'écriture simultanée. Il y a
des locks, mais ça n'interdit pas l'écriture, il faut que tous les
programmes susceptibles d'écrire tentent explicitement d'acquerir un lock
avant d'écrire.
Je disais pas vraiment, parce qu'un jour, un gus défoncé a décidé que ça
serait une bonne idée que si le fichier a un bit sgid, alors un lock
interdit vraiment les writes de la part d'autres programmes. Je sais pas si
c'est encore supporté sous linux, ou si ils ont pas ajouté une autre feature
mutante du style.
Je ne constate pas cela sur mon bash :
Oui, il y a des chances que ça varie en fonction du shell.
Le noyau ne permet pas l'écriture simultanée sur un même fichier : c'est juste ou faux ? :-)
Le noyau ne permet pas vraiment d'interdire l'écriture simultanée. Il y a des locks, mais ça n'interdit pas l'écriture, il faut que tous les programmes susceptibles d'écrire tentent explicitement d'acquerir un lock avant d'écrire.
Je disais pas vraiment, parce qu'un jour, un gus défoncé a décidé que ça serait une bonne idée que si le fichier a un bit sgid, alors un lock interdit vraiment les writes de la part d'autres programmes. Je sais pas si c'est encore supporté sous linux, ou si ils ont pas ajouté une autre feature mutante du style.
Je ne constate pas cela sur mon bash :
Oui, il y a des chances que ça varie en fonction du shell.
Marc Boyer
Le 10-05-2012, Francois Lafont a écrit :
Le 10/05/2012 13:17, Marc Boyer a écrit :
et de manière moins précise, tu peux par exemple comparer la date de création de ton fichier avec l'uptime de la machine.
Au delà de l'aspect conversion de date, mesure d'écart qui je verrai plus tard, je ne vois pas trop ce que tu veux dire.
Avec l'uptime, j'ai la possibilité de connaître la date de démarrage du système. Ok. Mais ensuite. Cette date, tu veux que je la « compare » avec la date de dernière modif (et donc de création) du fichier, c'est ça ? Ok. Mais alors qu'entends-tu par « comparer » ? Mesurer l'écart ? Mais dans ce cas, comment fixer une règle de décision ? Quel seuil fixer ?
Je veux un script qui s'exécute de façon différente si c'est sa première exécution depuis le reboot: dans un cas, il appelle prem(), et dans l'autre, pas_prem()
Si le fichier n'existe pas # Première exécution prem() Creer le fichier SinonSi le fichier existe *et* est plus vieux que l'uptime # Première exécution depuis le dernier reboot prem() Mettre à jour le fichier Sinon # Pas une première exécution pas_prem()
-- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Le 10-05-2012, Francois Lafont <francois.lafont@nospam.invalid> a écrit :
Le 10/05/2012 13:17, Marc Boyer a écrit :
et de manière moins
précise, tu peux par exemple comparer la date de création de
ton fichier avec l'uptime de la machine.
Au delà de l'aspect conversion de date, mesure d'écart qui je verrai
plus tard, je ne vois pas trop ce que tu veux dire.
Avec l'uptime, j'ai la possibilité de connaître la date de démarrage du
système. Ok. Mais ensuite. Cette date, tu veux que je la « compare »
avec la date de dernière modif (et donc de création) du fichier, c'est
ça ? Ok. Mais alors qu'entends-tu par « comparer » ? Mesurer l'écart ?
Mais dans ce cas, comment fixer une règle de décision ? Quel seuil fixer ?
Je veux un script qui s'exécute de façon différente si c'est sa
première exécution depuis le reboot: dans un cas, il appelle
prem(), et dans l'autre, pas_prem()
Si le fichier n'existe pas
# Première exécution
prem()
Creer le fichier
SinonSi le fichier existe *et* est plus vieux que l'uptime
# Première exécution depuis le dernier reboot
prem()
Mettre à jour le fichier
Sinon
# Pas une première exécution
pas_prem()
--
À mesure que les inégalités regressent, les attentes se renforcent.
François Dubet
et de manière moins précise, tu peux par exemple comparer la date de création de ton fichier avec l'uptime de la machine.
Au delà de l'aspect conversion de date, mesure d'écart qui je verrai plus tard, je ne vois pas trop ce que tu veux dire.
Avec l'uptime, j'ai la possibilité de connaître la date de démarrage du système. Ok. Mais ensuite. Cette date, tu veux que je la « compare » avec la date de dernière modif (et donc de création) du fichier, c'est ça ? Ok. Mais alors qu'entends-tu par « comparer » ? Mesurer l'écart ? Mais dans ce cas, comment fixer une règle de décision ? Quel seuil fixer ?
Je veux un script qui s'exécute de façon différente si c'est sa première exécution depuis le reboot: dans un cas, il appelle prem(), et dans l'autre, pas_prem()
Si le fichier n'existe pas # Première exécution prem() Creer le fichier SinonSi le fichier existe *et* est plus vieux que l'uptime # Première exécution depuis le dernier reboot prem() Mettre à jour le fichier Sinon # Pas une première exécution pas_prem()
-- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Nicolas George
Luc Habert, dans le message <jogdgp$qtl$, a écrit :
ou si ils ont pas ajouté une autre feature mutante du style.
Il y a les leases qui peuvent ressembler, de loin, à ça.
Luc Habert, dans le message <jogdgp$qtl$1@news.ens.fr>, a écrit :
ou si ils ont pas ajouté une autre feature
mutante du style.
Il y a les leases qui peuvent ressembler, de loin, à ça.
Luc Habert, dans le message <jogdgp$qtl$, a écrit :
ou si ils ont pas ajouté une autre feature mutante du style.
Il y a les leases qui peuvent ressembler, de loin, à ça.
Francois Lafont
Le 10/05/2012 15:47, Marc Boyer a écrit :
Je veux un script qui s'exécute de façon différente si c'est sa première exécution depuis le reboot: dans un cas, il appelle prem(), et dans l'autre, pas_prem()
Si le fichier n'existe pas # Première exécution prem() Creer le fichier SinonSi le fichier existe *et* est plus vieux que l'uptime # Première exécution depuis le dernier reboot prem() Mettre à jour le fichier Sinon # Pas une première exécution pas_prem()
Ah, d'accord, je comprends. Ça rejoint l'idée de Sergio. Merci bien.
-- François Lafont
Le 10/05/2012 15:47, Marc Boyer a écrit :
Je veux un script qui s'exécute de façon différente si c'est sa
première exécution depuis le reboot: dans un cas, il appelle
prem(), et dans l'autre, pas_prem()
Si le fichier n'existe pas
# Première exécution
prem()
Creer le fichier
SinonSi le fichier existe *et* est plus vieux que l'uptime
# Première exécution depuis le dernier reboot
prem()
Mettre à jour le fichier
Sinon
# Pas une première exécution
pas_prem()
Ah, d'accord, je comprends. Ça rejoint l'idée de Sergio.
Merci bien.
Je veux un script qui s'exécute de façon différente si c'est sa première exécution depuis le reboot: dans un cas, il appelle prem(), et dans l'autre, pas_prem()
Si le fichier n'existe pas # Première exécution prem() Creer le fichier SinonSi le fichier existe *et* est plus vieux que l'uptime # Première exécution depuis le dernier reboot prem() Mettre à jour le fichier Sinon # Pas une première exécution pas_prem()
Ah, d'accord, je comprends. Ça rejoint l'idée de Sergio. Merci bien.
-- François Lafont
Francois Lafont
Le 10/05/2012 14:49, Luc Habert a écrit :
Francois Lafont :
Le noyau ne permet pas l'écriture simultanée sur un même fichier : c'est juste ou faux ? :-)
Le noyau ne permet pas vraiment d'interdire l'écriture simultanée. Il y a des locks, mais ça n'interdit pas l'écriture, il faut que tous les programmes susceptibles d'écrire tentent explicitement d'acquerir un lock avant d'écrire.
Je disais pas vraiment, parce qu'un jour, un gus défoncé a décidé que ça serait une bonne idée que si le fichier a un bit sgid, alors un lock interdit vraiment les writes de la part d'autres programmes. Je sais pas si c'est encore supporté sous linux, ou si ils ont pas ajouté une autre feature mutante du style.
Ok.
Je ne constate pas cela sur mon bash :
Oui, il y a des chances que ça varie en fonction du shell.
Ok.
Merci à tous pour vos explications. Avec tous ces éléments, j'ai de quoi faire un truc qui tiendra la route je pense.
À+
-- François Lafont
Le 10/05/2012 14:49, Luc Habert a écrit :
Francois Lafont :
Le noyau ne permet pas l'écriture simultanée sur un même fichier : c'est
juste ou faux ? :-)
Le noyau ne permet pas vraiment d'interdire l'écriture simultanée. Il y a
des locks, mais ça n'interdit pas l'écriture, il faut que tous les
programmes susceptibles d'écrire tentent explicitement d'acquerir un lock
avant d'écrire.
Je disais pas vraiment, parce qu'un jour, un gus défoncé a décidé que ça
serait une bonne idée que si le fichier a un bit sgid, alors un lock
interdit vraiment les writes de la part d'autres programmes. Je sais pas si
c'est encore supporté sous linux, ou si ils ont pas ajouté une autre feature
mutante du style.
Ok.
Je ne constate pas cela sur mon bash :
Oui, il y a des chances que ça varie en fonction du shell.
Ok.
Merci à tous pour vos explications. Avec tous ces éléments, j'ai de quoi
faire un truc qui tiendra la route je pense.
Le noyau ne permet pas l'écriture simultanée sur un même fichier : c'est juste ou faux ? :-)
Le noyau ne permet pas vraiment d'interdire l'écriture simultanée. Il y a des locks, mais ça n'interdit pas l'écriture, il faut que tous les programmes susceptibles d'écrire tentent explicitement d'acquerir un lock avant d'écrire.
Je disais pas vraiment, parce qu'un jour, un gus défoncé a décidé que ça serait une bonne idée que si le fichier a un bit sgid, alors un lock interdit vraiment les writes de la part d'autres programmes. Je sais pas si c'est encore supporté sous linux, ou si ils ont pas ajouté une autre feature mutante du style.
Ok.
Je ne constate pas cela sur mon bash :
Oui, il y a des chances que ça varie en fonction du shell.
Ok.
Merci à tous pour vos explications. Avec tous ces éléments, j'ai de quoi faire un truc qui tiendra la route je pense.
