Y a-t-il mieux, pour supprimer le code d'erreur (pas le message) d'une
commande bash que "commande || true" ?
Pour que ma demande ne semble pas trop surprenante à ceux qui aiment
toujours remettre en cause le bienfondé des questions, c'est pour mettre
dans une configuration de système de sauvegarde (bacula) du genre :
dans une config générique qui sert à toutes les machines, mais qui pour
certaines renvoie une erreur (sans le || true) si le chemin n'existe pas,
mais surtout, interrompt totalement l'ensemble de la sauvegarde.
Ça m'évite de faire une config par machine, plus compliqué à maintenir,
sans toutefois être obligé de créer ces répertoires vides, juste pour que
la sauvegarde n'échoue pas.
Mais s'il n'y a pas mieux/plus propre que le "|| true", je laisse comme
ça.
Le Sat, 25 Jul 2020 22:50:12 +0000, Stéphane CARPENTIER a écrit :
Ben si, de faire un test sur l'existence du répertoire avant de lancer la commande.
Et non faire un test n'a pas d'intérêt, puisque ce n'est pas une condition au lancement de la sauvegarde ou pas. JE veux juste que si le répertoire existe, il soit sauvegardé, et que s'il n'existe pas, il ne le soit évidemment pas, mais qu'il n'y ait pas de code d'erreur pour ne pas empêcher la sauvegarde de TOUT LE RESTE.
J'ai bien compris ce que tu demandais. J'explique la raison de ma réponse dans l'autre message que je viens de poster.
Donc je persiste à dire que mon option est la bonne. Et je voulais juste savoir si le || true pour le faire était correct. Mais vu que personne n'a finalement proposé mieux, c'est que ça l'est.
Après tu fais ce que tu veux. C'est toi qui vois si les autres possibilités d'erreurs sont à prendre en compte ou pas. -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io
Le 26-07-2020, Christophe PEREZ <chris@novazur.fr> a écrit :
Le Sat, 25 Jul 2020 22:50:12 +0000, Stéphane CARPENTIER a écrit :
Ben si, de faire un test sur l'existence du répertoire avant de lancer
la commande.
Et non faire un test n'a pas d'intérêt, puisque ce n'est pas une
condition au lancement de la sauvegarde ou pas.
JE veux juste que si le répertoire existe, il soit sauvegardé, et que
s'il n'existe pas, il ne le soit évidemment pas, mais qu'il n'y ait pas
de code d'erreur pour ne pas empêcher la sauvegarde de TOUT LE RESTE.
J'ai bien compris ce que tu demandais. J'explique la raison de ma
réponse dans l'autre message que je viens de poster.
Donc je persiste à dire que mon option est la bonne. Et je voulais juste
savoir si le || true pour le faire était correct. Mais vu que personne
n'a finalement proposé mieux, c'est que ça l'est.
Après tu fais ce que tu veux. C'est toi qui vois si les autres
possibilités d'erreurs sont à prendre en compte ou pas.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io
Le Sat, 25 Jul 2020 22:50:12 +0000, Stéphane CARPENTIER a écrit :
Ben si, de faire un test sur l'existence du répertoire avant de lancer la commande.
Et non faire un test n'a pas d'intérêt, puisque ce n'est pas une condition au lancement de la sauvegarde ou pas. JE veux juste que si le répertoire existe, il soit sauvegardé, et que s'il n'existe pas, il ne le soit évidemment pas, mais qu'il n'y ait pas de code d'erreur pour ne pas empêcher la sauvegarde de TOUT LE RESTE.
J'ai bien compris ce que tu demandais. J'explique la raison de ma réponse dans l'autre message que je viens de poster.
Donc je persiste à dire que mon option est la bonne. Et je voulais juste savoir si le || true pour le faire était correct. Mais vu que personne n'a finalement proposé mieux, c'est que ça l'est.
Après tu fais ce que tu veux. C'est toi qui vois si les autres possibilités d'erreurs sont à prendre en compte ou pas. -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io
Nicolas George
Stéphane CARPENTIER , dans le message , a écrit :
C'est pour ça que je te dis que tu peux tester l'existence du répertoire. Si, pour une raisons quelconque, bacula n'a plus les droits de lire le contenu du répertoire, tu auras aussi une erreur. Sauf que si tu supprimes le code d'erreur quoiqu'il arrive, tu assumeras que la sauvegarde échoue parce que ton répertoire n'existe pas. Et il ne sera jamais sauvegardé. Il y a plein d'autres raisons pour lesquelles la commande peut échouer. Par exemple, tu peux perdre le réseau. La seule que tu veux bypasser, c'est celle qui correspond au répertoire inexistant. C'est pour ça que je dis que tester la raisons avant de considérer que c'est ça me semble préférable.
Excellent argument. D'une manière générale, plus quelque chose est important, plus il faut être spécifique quand on l'automatise.
Stéphane CARPENTIER , dans le message
<slrnrhreq7.p3.sc@scarpet42p.localdomain>, a écrit :
C'est pour ça que je te dis que tu peux tester l'existence du
répertoire. Si, pour une raisons quelconque, bacula n'a plus les droits
de lire le contenu du répertoire, tu auras aussi une erreur. Sauf que si
tu supprimes le code d'erreur quoiqu'il arrive, tu assumeras que la
sauvegarde échoue parce que ton répertoire n'existe pas. Et il ne sera
jamais sauvegardé. Il y a plein d'autres raisons pour lesquelles la
commande peut échouer. Par exemple, tu peux perdre le réseau. La seule
que tu veux bypasser, c'est celle qui correspond au répertoire
inexistant. C'est pour ça que je dis que tester la raisons avant de
considérer que c'est ça me semble préférable.
Excellent argument.
D'une manière générale, plus quelque chose est important, plus il faut être
spécifique quand on l'automatise.
C'est pour ça que je te dis que tu peux tester l'existence du répertoire. Si, pour une raisons quelconque, bacula n'a plus les droits de lire le contenu du répertoire, tu auras aussi une erreur. Sauf que si tu supprimes le code d'erreur quoiqu'il arrive, tu assumeras que la sauvegarde échoue parce que ton répertoire n'existe pas. Et il ne sera jamais sauvegardé. Il y a plein d'autres raisons pour lesquelles la commande peut échouer. Par exemple, tu peux perdre le réseau. La seule que tu veux bypasser, c'est celle qui correspond au répertoire inexistant. C'est pour ça que je dis que tester la raisons avant de considérer que c'est ça me semble préférable.
Excellent argument. D'une manière générale, plus quelque chose est important, plus il faut être spécifique quand on l'automatise.
Benoit Izac
Bonjour, Le 26/07/2020 à 18:50, Christophe PEREZ a écrit dans le message <rfkc7s$u9k$ :
Mieux, je ne pense pas, plus court, oui :
Quand je dis "mieux", je veux dire "plus convenable/correct", pas forcément plus court.
J'ai bien compris et c'est justement pourquoi j'ai précisé.
commande;:
Hu ? Qu'est-ce ?
Tu exécutes « commande » puis, quelque soit son code de retour, tu exécutes « : » qui ne fait rien et renvoie 0 (comme « true » donc). -- Benoit Izac
Bonjour,
Le 26/07/2020 à 18:50, Christophe PEREZ a écrit dans le message
<rfkc7s$u9k$1@serveur2.novazur.fr> :
Mieux, je ne pense pas, plus court, oui :
Quand je dis "mieux", je veux dire "plus convenable/correct", pas
forcément plus court.
J'ai bien compris et c'est justement pourquoi j'ai précisé.
commande;:
Hu ? Qu'est-ce ?
Tu exécutes « commande » puis, quelque soit son code de retour, tu
exécutes « : » qui ne fait rien et renvoie 0 (comme « true » donc).
Bonjour, Le 26/07/2020 à 18:50, Christophe PEREZ a écrit dans le message <rfkc7s$u9k$ :
Mieux, je ne pense pas, plus court, oui :
Quand je dis "mieux", je veux dire "plus convenable/correct", pas forcément plus court.
J'ai bien compris et c'est justement pourquoi j'ai précisé.
commande;:
Hu ? Qu'est-ce ?
Tu exécutes « commande » puis, quelque soit son code de retour, tu exécutes « : » qui ne fait rien et renvoie 0 (comme « true » donc). -- Benoit Izac
Marc SCHAEFER
Jo Engo wrote:
Le Sun, 26 Jul 2020 16:50:04 +0000, Christophe PEREZ a écrit : $ false;: $ echo $? 0
Toutefois: :~$ /tmp/bla :~$ cat /tmp/bla #! /bin/bash set -e false;: echo ok # ne s'affiche pas à cause du `set -e' Mais pas de souci avec la variante || true ( ou || : )
Jo Engo <yl@icite.fr> wrote:
Le Sun, 26 Jul 2020 16:50:04 +0000, Christophe PEREZ a écrit :
$ false;:
$ echo $?
0
Le Sun, 26 Jul 2020 16:50:04 +0000, Christophe PEREZ a écrit : $ false;: $ echo $? 0
Toutefois: :~$ /tmp/bla :~$ cat /tmp/bla #! /bin/bash set -e false;: echo ok # ne s'affiche pas à cause du `set -e' Mais pas de souci avec la variante || true ( ou || : )
Nicolas George
Marc SCHAEFER , dans le message <rfkilv$or6$, a écrit :
set -e false;: echo ok # ne s'affiche pas à cause du `set -e'
Évidemment, puisque set -e travaille instruction par instruction. Mais l'outil de backup de Christophe ne verra que le code de retour de l'ensemble de la commande donnée.
Marc SCHAEFER , dans le message <rfkilv$or6$1@shakotay.alphanet.ch>, a
écrit :
set -e
false;:
echo ok # ne s'affiche pas à cause du `set -e'
Évidemment, puisque set -e travaille instruction par instruction. Mais
l'outil de backup de Christophe ne verra que le code de retour de l'ensemble
de la commande donnée.
Marc SCHAEFER , dans le message <rfkilv$or6$, a écrit :
set -e false;: echo ok # ne s'affiche pas à cause du `set -e'
Évidemment, puisque set -e travaille instruction par instruction. Mais l'outil de backup de Christophe ne verra que le code de retour de l'ensemble de la commande donnée.
Christophe PEREZ
Le Sun, 26 Jul 2020 17:20:48 +0000, Nicolas George a écrit :
Ta phrase contient un « si », c'est bien qu'un test est la solution adaptée.
Mmmmhhh à part que le sinon est "rien".
if [ -d $dir ]; then ls -d $dir; fi
à part que mon $dir est du genre /le/dir/*/*/est/multiple/fichier_en_question J'ai du mal à voir toutes les implications à tous les niveaux
Le Sun, 26 Jul 2020 17:20:48 +0000, Nicolas George a écrit :
Ta phrase contient un « si », c'est bien qu'un test est la solution
adaptée.
Mmmmhhh à part que le sinon est "rien".
if [ -d $dir ]; then ls -d $dir; fi
à part que mon $dir est du genre
/le/dir/*/*/est/multiple/fichier_en_question
J'ai du mal à voir toutes les implications à tous les niveaux
Le Sun, 26 Jul 2020 17:20:48 +0000, Nicolas George a écrit :
Ta phrase contient un « si », c'est bien qu'un test est la solution adaptée.
Mmmmhhh à part que le sinon est "rien".
if [ -d $dir ]; then ls -d $dir; fi
à part que mon $dir est du genre /le/dir/*/*/est/multiple/fichier_en_question J'ai du mal à voir toutes les implications à tous les niveaux
Christophe PEREZ
Le Sun, 26 Jul 2020 17:24:42 +0000, Stéphane CARPENTIER a écrit :
J'ai bien compris ce que tu demandais. J'explique la raison de ma réponse dans l'autre message que je viens de poster.
Oui, j'ai bien vu, et je t'en remercie.
Après tu fais ce que tu veux. C'est toi qui vois si les autres possibilités d'erreurs sont à prendre en compte ou pas.
C'est bien la question que je me pose "à cause" ou "grâce" à vous selon la conclusion ;) A priori, et vous l'aurez compris, j'ai tendance à dire que je ne vois aucun impact, mais ça se réfléchi. bacula tourne en root, donc pas de pb de permission. Et il tourne sur le client, donc pas de pb de réseau. Et s'il y a pb réseau, le serveur ne lancera pas la sauvegarde, donc toujours pas un problème. Et s'il y a un problème réseau, c'est d'ailleurs que j'ai l'erreur. Je vais réfléchir à tout ça à tête reposée, et je verrai ce que j'en conclue. Merci à tous.
Le Sun, 26 Jul 2020 17:24:42 +0000, Stéphane CARPENTIER a écrit :
J'ai bien compris ce que tu demandais. J'explique la raison de ma
réponse dans l'autre message que je viens de poster.
Oui, j'ai bien vu, et je t'en remercie.
Après tu fais ce que tu veux. C'est toi qui vois si les autres
possibilités d'erreurs sont à prendre en compte ou pas.
C'est bien la question que je me pose "à cause" ou "grâce" à vous selon
la conclusion ;)
A priori, et vous l'aurez compris, j'ai tendance à dire que je ne vois
aucun impact, mais ça se réfléchi.
bacula tourne en root, donc pas de pb de permission.
Et il tourne sur le client, donc pas de pb de réseau. Et s'il y a pb
réseau, le serveur ne lancera pas la sauvegarde, donc toujours pas un
problème.
Et s'il y a un problème réseau, c'est d'ailleurs que j'ai l'erreur.
Je vais réfléchir à tout ça à tête reposée, et je verrai ce que j'en
conclue.
Le Sun, 26 Jul 2020 17:24:42 +0000, Stéphane CARPENTIER a écrit :
J'ai bien compris ce que tu demandais. J'explique la raison de ma réponse dans l'autre message que je viens de poster.
Oui, j'ai bien vu, et je t'en remercie.
Après tu fais ce que tu veux. C'est toi qui vois si les autres possibilités d'erreurs sont à prendre en compte ou pas.
C'est bien la question que je me pose "à cause" ou "grâce" à vous selon la conclusion ;) A priori, et vous l'aurez compris, j'ai tendance à dire que je ne vois aucun impact, mais ça se réfléchi. bacula tourne en root, donc pas de pb de permission. Et il tourne sur le client, donc pas de pb de réseau. Et s'il y a pb réseau, le serveur ne lancera pas la sauvegarde, donc toujours pas un problème. Et s'il y a un problème réseau, c'est d'ailleurs que j'ai l'erreur. Je vais réfléchir à tout ça à tête reposée, et je verrai ce que j'en conclue. Merci à tous.
Christophe PEREZ
Le Sun, 26 Jul 2020 19:55:52 +0200, Benoit Izac a écrit :
Tu exécutes « commande » puis, quelque soit son code de retour, tu exécutes « : » qui ne fait rien et renvoie 0 (comme « true » donc).
Ah oui, ok, donc ça revient au même que le true, ou il y a une nuance ?
Le Sun, 26 Jul 2020 19:55:52 +0200, Benoit Izac a écrit :
Tu exécutes « commande » puis, quelque soit son code de retour, tu
exécutes « : » qui ne fait rien et renvoie 0 (comme « true » donc).
Ah oui, ok, donc ça revient au même que le true, ou il y a une nuance ?
Le Sun, 26 Jul 2020 19:55:52 +0200, Benoit Izac a écrit :
Tu exécutes « commande » puis, quelque soit son code de retour, tu exécutes « : » qui ne fait rien et renvoie 0 (comme « true » donc).
Ah oui, ok, donc ça revient au même que le true, ou il y a une nuance ?
Benoit Izac
Bonjour, Le 26/07/2020 à 21:47, Christophe PEREZ a écrit dans le message <rfkmks$2cc$ :
Tu exécutes « commande » puis, quelque soit son code de retour, tu exécutes « : » qui ne fait rien et renvoie 0 (comme « true » donc).
Ah oui, ok, donc ça revient au même que le true, ou il y a une nuance ?
Pas vraiment à part que « : » est toujours un builtin du shell alors que true peut-être une commande externe (mais je pense que tous les shells actuels l'ont en builtin). Dans SUSv4 <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/true.html>, on peut lire : RATIONALE The true utility has been retained in this volume of POSIX.1-2017, even though the shell special built-in : provides similar functionality, because true is widely used in historical scripts and is less cryptic to novice script readers. -- Benoit Izac
Bonjour,
Le 26/07/2020 à 21:47, Christophe PEREZ a écrit dans le message
<rfkmks$2cc$3@serveur2.novazur.fr> :
Tu exécutes « commande » puis, quelque soit son code de retour, tu
exécutes « : » qui ne fait rien et renvoie 0 (comme « true » donc).
Ah oui, ok, donc ça revient au même que le true, ou il y a une nuance ?
Pas vraiment à part que « : » est toujours un builtin du shell alors que
true peut-être une commande externe (mais je pense que tous les shells
actuels l'ont en builtin).
Dans SUSv4
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/true.html>,
on peut lire :
RATIONALE
The true utility has been retained in this volume of POSIX.1-2017,
even though the shell special built-in : provides similar
functionality, because true is widely used in historical scripts and
is less cryptic to novice script readers.
Bonjour, Le 26/07/2020 à 21:47, Christophe PEREZ a écrit dans le message <rfkmks$2cc$ :
Tu exécutes « commande » puis, quelque soit son code de retour, tu exécutes « : » qui ne fait rien et renvoie 0 (comme « true » donc).
Ah oui, ok, donc ça revient au même que le true, ou il y a une nuance ?
Pas vraiment à part que « : » est toujours un builtin du shell alors que true peut-être une commande externe (mais je pense que tous les shells actuels l'ont en builtin). Dans SUSv4 <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/true.html>, on peut lire : RATIONALE The true utility has been retained in this volume of POSIX.1-2017, even though the shell special built-in : provides similar functionality, because true is widely used in historical scripts and is less cryptic to novice script readers. -- Benoit Izac
Nicolas George
Christophe PEREZ , dans le message <rfkmat$2cc$, a écrit :
J'ai du mal à voir toutes les implications à tous les niveaux
Dans ce cas, c'est ÇA qu'il faut corriger. Sinon tu ne pourras jamais avoir confiance en tes sauvegardes.
Christophe PEREZ , dans le message <rfkmat$2cc$1@serveur2.novazur.fr>, a
écrit :
J'ai du mal à voir toutes les implications à tous les niveaux
Dans ce cas, c'est ÇA qu'il faut corriger. Sinon tu ne pourras jamais avoir
confiance en tes sauvegardes.
