[ "$SUDO_USER" -a `id -u` -eq 0 ] || {
echo "Please run via sudo."
exit 1
}
export backup=/media/DD
if [ -d "$backup" ]; then
yt="/home/yt"
yt_="$backup/yt/"
echo "backup de '$yt' dans '$yt_'."
rsync -avz --delete-after $yt $yt_
etc="/etc"
etc_="$backup/etc/"
echo "backup de '$etc' dans '$etc_'."
rsync -avz --delete-after $etc $etc_
else
echo "Le disque '$backup' n'est pas monté."
fi
aussi, quand je suis en sudo, apparemment, le PATH est différent, par
exemple, je n'ai pas mon "/home/yt/bin" dans le PATH, ça se règle
comment le PATH de sudo ???
c'est automatique sur Ubuntu d'avoir "/home/yt/bin" dans le PATH ?
je ne l'ai pas ajouté par moi-même et pourtant il y est...
[ "$SUDO_USER" -a `id -u` -eq 0 ] || { echo "Please run via sudo." exit 1 }
export backup=/media/DD
if [ -d "$backup" ]; then yt="/home/yt" yt_="$backup/yt/" echo "backup de '$yt' dans '$yt_'." rsync -avz --delete-after $yt $yt_ etc="/etc" etc_="$backup/etc/" echo "backup de '$etc' dans '$etc_'." rsync -avz --delete-after $etc $etc_ else echo "Le disque '$backup' n'est pas monté." fi
aussi, quand je suis en sudo, apparemment, le PATH est différent, par exemple, je n'ai pas mon "/home/yt/bin" dans le PATH, ça se règle comment le PATH de sudo ???
c'est automatique sur Ubuntu d'avoir "/home/yt/bin" dans le PATH ? je ne l'ai pas ajouté par moi-même et pourtant il y est...
Une bonne pratique en Linux est de ne pas compter sur le "PATH" pour lancer une commande, il faut toujours lancer le programme avec le chemin complet. Quand on lance un shell on risque de ne pas retrouver ses variables.
Le 15/12/2011 10:25, Une Bévue a écrit :
j'ai du louper qqc car mon backup rsync oublie des trucs, par exemple le
symlink et son script de backup :
/home/yt/bin/backup2DD
symlink qui pointe vers :
/home/yt/bin/scripts/backup2DD.zsh
j'ai eu le mesage d'erreur suivant :
yt@D620:~$ sudo /home/yt/bin/backup2DD >
Installations/11-12-15--09-48--backup2DD.txt
rsync: readlink_stat("/home/yt/.gvfs") failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors)
(code 23) at main.c(1060) [sender=3.0.7]
les perms de .gvfs :
yt@D620:~$ ls -al /home/yt/.gvfs
total 4
dr-x------ 2 yt yt 0 2011-12-15 07:04 .
drwxr-xr-x 47 yt yt 4096 2011-12-15 09:19 ..
[ "$SUDO_USER" -a `id -u` -eq 0 ] || {
echo "Please run via sudo."
exit 1
}
export backup=/media/DD
if [ -d "$backup" ]; then
yt="/home/yt"
yt_="$backup/yt/"
echo "backup de '$yt' dans '$yt_'."
rsync -avz --delete-after $yt $yt_
etc="/etc"
etc_="$backup/etc/"
echo "backup de '$etc' dans '$etc_'."
rsync -avz --delete-after $etc $etc_
else
echo "Le disque '$backup' n'est pas monté."
fi
aussi, quand je suis en sudo, apparemment, le PATH est différent, par
exemple, je n'ai pas mon "/home/yt/bin" dans le PATH, ça se règle
comment le PATH de sudo ???
c'est automatique sur Ubuntu d'avoir "/home/yt/bin" dans le PATH ?
je ne l'ai pas ajouté par moi-même et pourtant il y est...
Une bonne pratique en Linux est de ne pas compter sur le "PATH" pour
lancer une commande, il faut toujours lancer le programme avec le chemin
complet. Quand on lance un shell on risque de ne pas retrouver ses
variables.
[ "$SUDO_USER" -a `id -u` -eq 0 ] || { echo "Please run via sudo." exit 1 }
export backup=/media/DD
if [ -d "$backup" ]; then yt="/home/yt" yt_="$backup/yt/" echo "backup de '$yt' dans '$yt_'." rsync -avz --delete-after $yt $yt_ etc="/etc" etc_="$backup/etc/" echo "backup de '$etc' dans '$etc_'." rsync -avz --delete-after $etc $etc_ else echo "Le disque '$backup' n'est pas monté." fi
aussi, quand je suis en sudo, apparemment, le PATH est différent, par exemple, je n'ai pas mon "/home/yt/bin" dans le PATH, ça se règle comment le PATH de sudo ???
c'est automatique sur Ubuntu d'avoir "/home/yt/bin" dans le PATH ? je ne l'ai pas ajouté par moi-même et pourtant il y est...
Une bonne pratique en Linux est de ne pas compter sur le "PATH" pour lancer une commande, il faut toujours lancer le programme avec le chemin complet. Quand on lance un shell on risque de ne pas retrouver ses variables.
Nicolas George
"denis.paris" , dans le message <4ee9bf7e$0$24980$, a écrit :
Une bonne pratique en Linux est de ne pas compter sur le "PATH" pour lancer une commande
Totalement faux.
"denis.paris" , dans le message
<4ee9bf7e$0$24980$426a74cc@news.free.fr>, a écrit :
Une bonne pratique en Linux est de ne pas compter sur le "PATH" pour
lancer une commande
"denis.paris" , dans le message <4ee9bf7e$0$24980$, a écrit :
Une bonne pratique en Linux est de ne pas compter sur le "PATH" pour lancer une commande
Totalement faux.
Nicolas George
Une Bévue , dans le message <4ee9bcfb$0$602$, a écrit :
rsync: readlink_stat("/home/yt/.gvfs") failed: Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1060) [sender=3.0.7]
Au hasard, .gvfs est un point de montage FUSE, ce qui est toujours particulier.
Une Bévue , dans le message <4ee9bcfb$0$602$426a74cc@news.free.fr>, a
écrit :
rsync: readlink_stat("/home/yt/.gvfs") failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors)
(code 23) at main.c(1060) [sender=3.0.7]
Au hasard, .gvfs est un point de montage FUSE, ce qui est toujours
particulier.
Une Bévue , dans le message <4ee9bcfb$0$602$, a écrit :
rsync: readlink_stat("/home/yt/.gvfs") failed: Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1060) [sender=3.0.7]
Au hasard, .gvfs est un point de montage FUSE, ce qui est toujours particulier.
Pascal
-------- Message original --------
"denis.paris" , dans le message <4ee9bf7e$0$24980$, a écrit :
Une bonne pratique en Linux est de ne pas compter sur le "PATH" pour lancer une commande
Totalement faux.
Ceci dit des commandes lancées via la crontab sans le chemin complet de cette commande échouent souvent
-------- Message original --------
"denis.paris" , dans le message
<4ee9bf7e$0$24980$426a74cc@news.free.fr>, a écrit :
Une bonne pratique en Linux est de ne pas compter sur le "PATH" pour
lancer une commande
Totalement faux.
Ceci dit des commandes lancées via la crontab sans le chemin complet de cette
commande échouent souvent
"denis.paris" , dans le message <4ee9bf7e$0$24980$, a écrit :
Une bonne pratique en Linux est de ne pas compter sur le "PATH" pour lancer une commande
Totalement faux.
Ceci dit des commandes lancées via la crontab sans le chemin complet de cette commande échouent souvent
Nicolas George
Pascal , dans le message <4ee9ca60$0$15950$, a écrit :
Ceci dit des commandes lancées via la crontab sans le chemin complet de cette commande échouent souvent
Il faut définir l'environnement dans la crontab, évidemment. C'est valable pour PATH, mais aussi pour LD_LIBRARY_PATH si nécessaire, LC_CTYPE et compagnie et bien d'autres.
Pascal , dans le message <4ee9ca60$0$15950$426a74cc@news.free.fr>, a
écrit :
Ceci dit des commandes lancées via la crontab sans le chemin complet de cette
commande échouent souvent
Il faut définir l'environnement dans la crontab, évidemment. C'est valable
pour PATH, mais aussi pour LD_LIBRARY_PATH si nécessaire, LC_CTYPE et
compagnie et bien d'autres.
Pascal , dans le message <4ee9ca60$0$15950$, a écrit :
Ceci dit des commandes lancées via la crontab sans le chemin complet de cette commande échouent souvent
Il faut définir l'environnement dans la crontab, évidemment. C'est valable pour PATH, mais aussi pour LD_LIBRARY_PATH si nécessaire, LC_CTYPE et compagnie et bien d'autres.
denis.paris
Le 15/12/2011 11:22, Pascal a écrit :
-------- Message original --------
"denis.paris" , dans le message <4ee9bf7e$0$24980$, a écrit :
Une bonne pratique en Linux est de ne pas compter sur le "PATH" pour lancer une commande
Totalement faux.
Ceci dit des commandes lancées via la crontab sans le chemin complet de cette commande échouent souvent
Évidemment c'est bien ce que je voulais dire, car en mode interactif dans un shell ce n'est le plus souvent pas nécessaire.
Mon affirmation ne se veut pas une vérité première, elle s'adresse aux débutants en linux qui viennent du monde Windows ou cette notion de chemin complet pour les exécutables est moins connue.
En particulier l'invocation d'un programme du répertoire courant fonctionne toujours en Windows, en linux le chemin "." n'est en général pas dans le path, sauf bidouille non recommandable.
Le 15/12/2011 11:22, Pascal a écrit :
-------- Message original --------
"denis.paris" , dans le message
<4ee9bf7e$0$24980$426a74cc@news.free.fr>, a écrit :
Une bonne pratique en Linux est de ne pas compter sur le "PATH" pour
lancer une commande
Totalement faux.
Ceci dit des commandes lancées via la crontab sans le chemin complet de cette
commande échouent souvent
Évidemment c'est bien ce que je voulais dire, car en mode interactif
dans un shell ce n'est le plus souvent pas nécessaire.
Mon affirmation ne se veut pas une vérité première, elle s'adresse aux
débutants en linux qui viennent du monde Windows ou cette notion de
chemin complet pour les exécutables est moins connue.
En particulier l'invocation d'un programme du répertoire courant
fonctionne toujours en Windows, en linux le chemin "." n'est en général
pas dans le path, sauf bidouille non recommandable.
"denis.paris" , dans le message <4ee9bf7e$0$24980$, a écrit :
Une bonne pratique en Linux est de ne pas compter sur le "PATH" pour lancer une commande
Totalement faux.
Ceci dit des commandes lancées via la crontab sans le chemin complet de cette commande échouent souvent
Évidemment c'est bien ce que je voulais dire, car en mode interactif dans un shell ce n'est le plus souvent pas nécessaire.
Mon affirmation ne se veut pas une vérité première, elle s'adresse aux débutants en linux qui viennent du monde Windows ou cette notion de chemin complet pour les exécutables est moins connue.
En particulier l'invocation d'un programme du répertoire courant fonctionne toujours en Windows, en linux le chemin "." n'est en général pas dans le path, sauf bidouille non recommandable.
Nicolas George
"denis.paris" , dans le message <4ee9cf2b$0$3201$, a écrit :
Mon affirmation ne se veut pas une vérité première, elle s'adresse aux débutants en linux qui viennent du monde Windows ou cette notion de chemin complet pour les exécutables est moins connue.
Tu as dit que c'était une bonne pratique. C'est totalement faux, c'est une _mauvaise_ pratique.
La bonne pratique, c'est de définir l'environnement si c'est nécessaire.
En particulier l'invocation d'un programme du répertoire courant fonctionne toujours en Windows, en linux le chemin "." n'est en général pas dans le path, sauf bidouille non recommandable.
L'invocation d'un programme du répertoire courant en situation d'utilisation normale est en général preuve que quelque chose a été mal fait.
"denis.paris" , dans le message <4ee9cf2b$0$3201$426a74cc@news.free.fr>,
a écrit :
Mon affirmation ne se veut pas une vérité première, elle s'adresse aux
débutants en linux qui viennent du monde Windows ou cette notion de
chemin complet pour les exécutables est moins connue.
Tu as dit que c'était une bonne pratique. C'est totalement faux, c'est une
_mauvaise_ pratique.
La bonne pratique, c'est de définir l'environnement si c'est nécessaire.
En particulier l'invocation d'un programme du répertoire courant
fonctionne toujours en Windows, en linux le chemin "." n'est en général
pas dans le path, sauf bidouille non recommandable.
L'invocation d'un programme du répertoire courant en situation d'utilisation
normale est en général preuve que quelque chose a été mal fait.
"denis.paris" , dans le message <4ee9cf2b$0$3201$, a écrit :
Mon affirmation ne se veut pas une vérité première, elle s'adresse aux débutants en linux qui viennent du monde Windows ou cette notion de chemin complet pour les exécutables est moins connue.
Tu as dit que c'était une bonne pratique. C'est totalement faux, c'est une _mauvaise_ pratique.
La bonne pratique, c'est de définir l'environnement si c'est nécessaire.
En particulier l'invocation d'un programme du répertoire courant fonctionne toujours en Windows, en linux le chemin "." n'est en général pas dans le path, sauf bidouille non recommandable.
L'invocation d'un programme du répertoire courant en situation d'utilisation normale est en général preuve que quelque chose a été mal fait.
unbewusst.sein
Nicolas George <nicolas$ wrote:
Une Bévue , dans le message <4ee9bcfb$0$602$, a écrit : > rsync: readlink_stat("/home/yt/.gvfs") failed: Permission denied (13) > rsync error: some files/attrs were not transferred (see previous errors) > (code 23) at main.c(1060) [sender=3.0.7]
Au hasard, .gvfs est un point de montage FUSE, ce qui est toujours particulier.
Ah, d'accord, je me doutais - un peu - d'un truc de ce genre... à cause du "fs"...
Et donc, ça peut faire que tout mon rsync a foiré, je veux dire à cause de ce .gvfs ???
Dans ce cas il me faudrait le mettre en exclude.
-- « L'homme est capable du meilleur comme du pire, mais c'est vraiment dans le pire qu'il est le meilleur. » (Grégoire Lacroix)
Nicolas George <nicolas$george@salle-s.org> wrote:
Une Bévue , dans le message <4ee9bcfb$0$602$426a74cc@news.free.fr>, a
écrit :
> rsync: readlink_stat("/home/yt/.gvfs") failed: Permission denied (13)
> rsync error: some files/attrs were not transferred (see previous errors)
> (code 23) at main.c(1060) [sender=3.0.7]
Au hasard, .gvfs est un point de montage FUSE, ce qui est toujours
particulier.
Ah, d'accord, je me doutais - un peu - d'un truc de ce genre...
à cause du "fs"...
Et donc, ça peut faire que tout mon rsync a foiré, je veux dire à cause
de ce .gvfs ???
Dans ce cas il me faudrait le mettre en exclude.
--
« L'homme est capable du meilleur comme du pire,
mais c'est vraiment dans le pire qu'il est le meilleur. »
(Grégoire Lacroix)
Une Bévue , dans le message <4ee9bcfb$0$602$, a écrit : > rsync: readlink_stat("/home/yt/.gvfs") failed: Permission denied (13) > rsync error: some files/attrs were not transferred (see previous errors) > (code 23) at main.c(1060) [sender=3.0.7]
Au hasard, .gvfs est un point de montage FUSE, ce qui est toujours particulier.
Ah, d'accord, je me doutais - un peu - d'un truc de ce genre... à cause du "fs"...
Et donc, ça peut faire que tout mon rsync a foiré, je veux dire à cause de ce .gvfs ???
Dans ce cas il me faudrait le mettre en exclude.
-- « L'homme est capable du meilleur comme du pire, mais c'est vraiment dans le pire qu'il est le meilleur. » (Grégoire Lacroix)
unbewusst.sein
Nicolas George <nicolas$ wrote:
Totalement faux.
c'est sûr !!! Mais ça ne me dit pas comment avoir, sous sudo, /home/yt/bin dans le PATH. Le rép "/home/yt/bin" est bien dans mon PATH comme utilisateur "normal", ie. SANS sudo... Sur Mac OS X, sans rien faire de spécial, le PATH normal est le même, il me semble, que le PATH avec sudo. -- « L'homme est capable du meilleur comme du pire, mais c'est vraiment dans le pire qu'il est le meilleur. » (Grégoire Lacroix)
Nicolas George <nicolas$george@salle-s.org> wrote:
Totalement faux.
c'est sûr !!!
Mais ça ne me dit pas comment avoir, sous sudo, /home/yt/bin dans le
PATH.
Le rép "/home/yt/bin" est bien dans mon PATH comme utilisateur "normal",
ie. SANS sudo...
Sur Mac OS X, sans rien faire de spécial, le PATH normal est le même, il
me semble, que le PATH avec sudo.
--
« L'homme est capable du meilleur comme du pire,
mais c'est vraiment dans le pire qu'il est le meilleur. »
(Grégoire Lacroix)
c'est sûr !!! Mais ça ne me dit pas comment avoir, sous sudo, /home/yt/bin dans le PATH. Le rép "/home/yt/bin" est bien dans mon PATH comme utilisateur "normal", ie. SANS sudo... Sur Mac OS X, sans rien faire de spécial, le PATH normal est le même, il me semble, que le PATH avec sudo. -- « L'homme est capable du meilleur comme du pire, mais c'est vraiment dans le pire qu'il est le meilleur. » (Grégoire Lacroix)
Nicolas George
Une Bévue, dans le message <1kcbi1a.13m1e81cpkuuiN%, a écrit :
Et donc, ça peut faire que tout mon rsync a foiré, je veux dire à cause de ce .gvfs ???
Non, juste pour ce répertoire.
Une Bévue, dans le message
<1kcbi1a.13m1e81cpkuuiN%unbewusst.sein@fai.invalid>, a écrit :
Et donc, ça peut faire que tout mon rsync a foiré, je veux dire à cause
de ce .gvfs ???
