Je voudrais qu'un script s'invoque lui même sous un autre
utilisateur. J'ai placé quelque chose comme :
exec su - mail -c "$0 $@"
Si le "-c" du shell prenait autant de paramètres que je désirais,
j'aurais plutôt mis "$0" "$@". Mais comme je dois tout donner comme un
seul argument, je suis obligé de coller "$0 $@". Problème, si le
premier argument est "truc machin", j'ai "$0 truc machin" donc
j'obtiens deux arguments au lieu d'un.
Comment écrire ceci proprement ?
--
Take care to branch the right way on equality.
- The Elements of Programming Style (Kernighan & Plauger)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
lhabert
Vincent Bernat :
Je voudrais qu'un script s'invoque lui même sous un autre utilisateur. J'ai placé quelque chose comme : exec su - mail -c "$0 $@"
Si le "-c" du shell prenait autant de paramètres que je désirais, j'aurais plutôt mis "$0" "$@". Mais comme je dois tout donner comme un seul argument, je suis obligé de coller "$0 $@". Problème, si le premier argument est "truc machin", j'ai "$0 truc machin" donc j'obtiens deux arguments au lieu d'un.
Comment écrire ceci proprement ?
Utiliser sudo à la place de su.
Vincent Bernat :
Je voudrais qu'un script s'invoque lui même sous un autre
utilisateur. J'ai placé quelque chose comme :
exec su - mail -c "$0 $@"
Si le "-c" du shell prenait autant de paramètres que je désirais,
j'aurais plutôt mis "$0" "$@". Mais comme je dois tout donner comme un
seul argument, je suis obligé de coller "$0 $@". Problème, si le
premier argument est "truc machin", j'ai "$0 truc machin" donc
j'obtiens deux arguments au lieu d'un.
Je voudrais qu'un script s'invoque lui même sous un autre utilisateur. J'ai placé quelque chose comme : exec su - mail -c "$0 $@"
Si le "-c" du shell prenait autant de paramètres que je désirais, j'aurais plutôt mis "$0" "$@". Mais comme je dois tout donner comme un seul argument, je suis obligé de coller "$0 $@". Problème, si le premier argument est "truc machin", j'ai "$0 truc machin" donc j'obtiens deux arguments au lieu d'un.
Comment écrire ceci proprement ?
Utiliser sudo à la place de su.
Vincent Bernat
OoO En ce début de soirée du mardi 06 février 2007, vers 21:04, (Luc Habert) disait:
Je voudrais qu'un script s'invoque lui même sous un autre utilisateur. J'ai placé quelque chose comme : exec su - mail -c "$0 $@"
Si le "-c" du shell prenait autant de paramètres que je désirais, j'aurais plutôt mis "$0" "$@". Mais comme je dois tout donner comme un seul argument, je suis obligé de coller "$0 $@". Problème, si le premier argument est "truc machin", j'ai "$0 truc machin" donc j'obtiens deux arguments au lieu d'un.
Comment écrire ceci proprement ?
Utiliser sudo à la place de su.
Ca enlève le charme de l'exercice. :) -- printk("HPFS: Grrrr... Kernel memory corrupted ... going on, but it'll crash very soon :-(n"); 2.4.3 linux/fs/hpfs/super.c
OoO En ce début de soirée du mardi 06 février 2007, vers 21:04,
lhabert@clipper.ens.fr (Luc Habert) disait:
Je voudrais qu'un script s'invoque lui même sous un autre
utilisateur. J'ai placé quelque chose comme :
exec su - mail -c "$0 $@"
Si le "-c" du shell prenait autant de paramètres que je désirais,
j'aurais plutôt mis "$0" "$@". Mais comme je dois tout donner comme un
seul argument, je suis obligé de coller "$0 $@". Problème, si le
premier argument est "truc machin", j'ai "$0 truc machin" donc
j'obtiens deux arguments au lieu d'un.
Comment écrire ceci proprement ?
Utiliser sudo à la place de su.
Ca enlève le charme de l'exercice. :)
--
printk("HPFS: Grrrr... Kernel memory corrupted ... going on, but
it'll crash very soon :-(n");
2.4.3 linux/fs/hpfs/super.c
OoO En ce début de soirée du mardi 06 février 2007, vers 21:04, (Luc Habert) disait:
Je voudrais qu'un script s'invoque lui même sous un autre utilisateur. J'ai placé quelque chose comme : exec su - mail -c "$0 $@"
Si le "-c" du shell prenait autant de paramètres que je désirais, j'aurais plutôt mis "$0" "$@". Mais comme je dois tout donner comme un seul argument, je suis obligé de coller "$0 $@". Problème, si le premier argument est "truc machin", j'ai "$0 truc machin" donc j'obtiens deux arguments au lieu d'un.
Comment écrire ceci proprement ?
Utiliser sudo à la place de su.
Ca enlève le charme de l'exercice. :) -- printk("HPFS: Grrrr... Kernel memory corrupted ... going on, but it'll crash very soon :-(n"); 2.4.3 linux/fs/hpfs/super.c
Stephane Chazelas
2007-02-06, 20:38(+01), Vincent Bernat:
Coucou !
Je voudrais qu'un script s'invoque lui même sous un autre utilisateur. J'ai placé quelque chose comme : exec su - mail -c "$0 $@"
Si le "-c" du shell prenait autant de paramètres que je désirais, j'aurais plutôt mis "$0" "$@". Mais comme je dois tout donner comme un seul argument, je suis obligé de coller "$0 $@". Problème, si le premier argument est "truc machin", j'ai "$0 truc machin" donc j'obtiens deux arguments au lieu d'un.
Comment écrire ceci proprement ?
Le probleme est qu'il y a plusieurs version de su qui fonctionnent differemment. Le -c historiquement etait passé au shell de l'utilisateur avec le reste des arguments. Donc, on pouvait faire:
su user -c 'shift "$1"; exec "$@"' 2 1 "$0" "$@"
(a supposer qu'user a un shell bourne-like)
Le problem est qu'il y a des su qui se croient malins en faisant des trucs differents (comme concatener les arguments avant de les passer au shell de l'utilisateur).
Le mieux est probablement de construire la ligne de commande from scratch:
cmd=$( awk ' BEGIN { cmd="exec" for (i = 1; i < ARGC; i++) { arg = ARGV[i] gsub(/'''/, "'''''''", arg) cmd = cmd " '''" arg "'''" } print cmd exit }' "$0" "$@" ) su user -c "$cmd"
Qui devrait marcher si le shell de l'utilisateur est Bourne ou csh type, mais pas rc.
Sinon, ya aussi
su user -c sh << EOF $cmd EOF -- Stéphane
2007-02-06, 20:38(+01), Vincent Bernat:
Coucou !
Je voudrais qu'un script s'invoque lui même sous un autre
utilisateur. J'ai placé quelque chose comme :
exec su - mail -c "$0 $@"
Si le "-c" du shell prenait autant de paramètres que je désirais,
j'aurais plutôt mis "$0" "$@". Mais comme je dois tout donner comme un
seul argument, je suis obligé de coller "$0 $@". Problème, si le
premier argument est "truc machin", j'ai "$0 truc machin" donc
j'obtiens deux arguments au lieu d'un.
Comment écrire ceci proprement ?
Le probleme est qu'il y a plusieurs version de su qui
fonctionnent differemment. Le -c historiquement etait passé au
shell de l'utilisateur avec le reste des arguments. Donc, on
pouvait faire:
su user -c 'shift "$1"; exec "$@"' 2 1 "$0" "$@"
(a supposer qu'user a un shell bourne-like)
Le problem est qu'il y a des su qui se croient malins en faisant
des trucs differents (comme concatener les arguments avant de
les passer au shell de l'utilisateur).
Le mieux est probablement de construire la ligne de commande
from scratch:
cmd=$(
awk '
BEGIN {
cmd="exec"
for (i = 1; i < ARGC; i++) {
arg = ARGV[i]
gsub(/'''/, "'''\''''", arg)
cmd = cmd " '''" arg "'''"
}
print cmd
exit
}' "$0" "$@"
)
su user -c "$cmd"
Qui devrait marcher si le shell de l'utilisateur est Bourne ou
csh type, mais pas rc.
Je voudrais qu'un script s'invoque lui même sous un autre utilisateur. J'ai placé quelque chose comme : exec su - mail -c "$0 $@"
Si le "-c" du shell prenait autant de paramètres que je désirais, j'aurais plutôt mis "$0" "$@". Mais comme je dois tout donner comme un seul argument, je suis obligé de coller "$0 $@". Problème, si le premier argument est "truc machin", j'ai "$0 truc machin" donc j'obtiens deux arguments au lieu d'un.
Comment écrire ceci proprement ?
Le probleme est qu'il y a plusieurs version de su qui fonctionnent differemment. Le -c historiquement etait passé au shell de l'utilisateur avec le reste des arguments. Donc, on pouvait faire:
su user -c 'shift "$1"; exec "$@"' 2 1 "$0" "$@"
(a supposer qu'user a un shell bourne-like)
Le problem est qu'il y a des su qui se croient malins en faisant des trucs differents (comme concatener les arguments avant de les passer au shell de l'utilisateur).
Le mieux est probablement de construire la ligne de commande from scratch:
cmd=$( awk ' BEGIN { cmd="exec" for (i = 1; i < ARGC; i++) { arg = ARGV[i] gsub(/'''/, "'''''''", arg) cmd = cmd " '''" arg "'''" } print cmd exit }' "$0" "$@" ) su user -c "$cmd"
Qui devrait marcher si le shell de l'utilisateur est Bourne ou csh type, mais pas rc.
Sinon, ya aussi
su user -c sh << EOF $cmd EOF -- Stéphane
Vincent Bernat
OoO En ce début de soirée du mardi 06 février 2007, vers 21:32, Stephane Chazelas disait:
cmd=$( awk ' BEGIN { cmd="exec" for (i = 1; i < ARGC; i++) { arg = ARGV[i] gsub(/'''/, "'''''''", arg) cmd = cmd " '''" arg "'''" } print cmd exit }' "$0" "$@" ) su user -c "$cmd"
Merci de la réponse, c'est très instructif. Comme sudo est installé, je vais plutôt l'utiliser. Mon script est quasiment aussi grand que la commande que tu proposes. ;-)
Qui devrait marcher si le shell de l'utilisateur est Bourne ou csh type, mais pas rc.
rc ? -- BOFH excuse #235: The new frame relay network hasn't bedded down the software loop transmitter yet.
OoO En ce début de soirée du mardi 06 février 2007, vers 21:32,
Stephane Chazelas <cette.adresse@est.invalid> disait:
cmd=$(
awk '
BEGIN {
cmd="exec"
for (i = 1; i < ARGC; i++) {
arg = ARGV[i]
gsub(/'''/, "'''\''''", arg)
cmd = cmd " '''" arg "'''"
}
print cmd
exit
}' "$0" "$@"
)
su user -c "$cmd"
Merci de la réponse, c'est très instructif. Comme sudo est installé,
je vais plutôt l'utiliser. Mon script est quasiment aussi grand que la
commande que tu proposes. ;-)
Qui devrait marcher si le shell de l'utilisateur est Bourne ou
csh type, mais pas rc.
rc ?
--
BOFH excuse #235: The new frame relay network hasn't bedded down the
software loop transmitter yet.
OoO En ce début de soirée du mardi 06 février 2007, vers 21:32, Stephane Chazelas disait:
cmd=$( awk ' BEGIN { cmd="exec" for (i = 1; i < ARGC; i++) { arg = ARGV[i] gsub(/'''/, "'''''''", arg) cmd = cmd " '''" arg "'''" } print cmd exit }' "$0" "$@" ) su user -c "$cmd"
Merci de la réponse, c'est très instructif. Comme sudo est installé, je vais plutôt l'utiliser. Mon script est quasiment aussi grand que la commande que tu proposes. ;-)
Qui devrait marcher si le shell de l'utilisateur est Bourne ou csh type, mais pas rc.
rc ? -- BOFH excuse #235: The new frame relay network hasn't bedded down the software loop transmitter yet.
Stephane Chazelas
2007-02-06, 21:42(+01), Vincent Bernat: [...]
Qui devrait marcher si le shell de l'utilisateur est Bourne ou csh type, mais pas rc.
rc ?
Le shell de plan9. Un bien meilleur shell pour les scripts que les shells Bourne-likes. N'a pas la plupart des erreurs de design introduites par ksh. es et akanga sont deux de ses descendants.
Le here-string (<<< string) que l'on trouve chez zsh et maintenant chez ksh93 puis bash vient de la par exemple.
Si les shells de maintenant etaient basés sur rc plutot que ksh, les shells ne seraient pas le bordel qu'ils sont aujourd'hui. Malheureusement, on ne peut pas revenir en arriere.
-- Stéphane
2007-02-06, 21:42(+01), Vincent Bernat:
[...]
Qui devrait marcher si le shell de l'utilisateur est Bourne ou
csh type, mais pas rc.
rc ?
Le shell de plan9. Un bien meilleur shell pour les scripts que
les shells Bourne-likes. N'a pas la plupart des erreurs de
design introduites par ksh. es et akanga sont deux de ses
descendants.
Le here-string (<<< string) que l'on trouve chez zsh et
maintenant chez ksh93 puis bash vient de la par exemple.
Si les shells de maintenant etaient basés sur rc plutot que ksh,
les shells ne seraient pas le bordel qu'ils sont aujourd'hui.
Malheureusement, on ne peut pas revenir en arriere.
Qui devrait marcher si le shell de l'utilisateur est Bourne ou csh type, mais pas rc.
rc ?
Le shell de plan9. Un bien meilleur shell pour les scripts que les shells Bourne-likes. N'a pas la plupart des erreurs de design introduites par ksh. es et akanga sont deux de ses descendants.
Le here-string (<<< string) que l'on trouve chez zsh et maintenant chez ksh93 puis bash vient de la par exemple.
Si les shells de maintenant etaient basés sur rc plutot que ksh, les shells ne seraient pas le bordel qu'ils sont aujourd'hui. Malheureusement, on ne peut pas revenir en arriere.
-- Stéphane
Pascal Bourguignon
Stephane Chazelas writes:
2007-02-06, 21:42(+01), Vincent Bernat: [...]
Qui devrait marcher si le shell de l'utilisateur est Bourne ou csh type, mais pas rc.
rc ?
Le shell de plan9. Un bien meilleur shell pour les scripts que les shells Bourne-likes. N'a pas la plupart des erreurs de design introduites par ksh. es et akanga sont deux de ses descendants.
Le here-string (<<< string) que l'on trouve chez zsh et maintenant chez ksh93 puis bash vient de la par exemple.
Si les shells de maintenant etaient basés sur rc plutot que ksh, les shells ne seraient pas le bordel qu'ils sont aujourd'hui. Malheureusement, on ne peut pas revenir en arriere.
Enfin il me semble qu'il serait assez simple de specifier dans un "standard" quelconque un bon shell, qui serait rapidement disponible dans toutes les "distributions", tout en figeant un sh pour les anciens scripts. Tout nouveau script pourrait alors être écrit dans ce nouveau et bon shell. Voir comment perl, ruby et python se sont répandus: ils sont maintenant "standard de fait". Et grâce au logiciel libre, s'ils ne sont pas disponible sur un ancien système, il est trés simple de les y installer.
Et finalement, je n'ai pas l'impression qu'il y ait beaucoup de vieux scripts (ou même shar) sur un système moderne (MacOSX, Linux, même *BSD). On pourrait même assez rapidement se retrouver avec un système purgé de tout bourne shell ou script...
-- __Pascal Bourguignon__ http://www.informatimago.com/ You never feed me. Perhaps I'll sleep on your face. That will sure show you.
Qui devrait marcher si le shell de l'utilisateur est Bourne ou
csh type, mais pas rc.
rc ?
Le shell de plan9. Un bien meilleur shell pour les scripts que
les shells Bourne-likes. N'a pas la plupart des erreurs de
design introduites par ksh. es et akanga sont deux de ses
descendants.
Le here-string (<<< string) que l'on trouve chez zsh et
maintenant chez ksh93 puis bash vient de la par exemple.
Si les shells de maintenant etaient basés sur rc plutot que ksh,
les shells ne seraient pas le bordel qu'ils sont aujourd'hui.
Malheureusement, on ne peut pas revenir en arriere.
Enfin il me semble qu'il serait assez simple de specifier dans un
"standard" quelconque un bon shell, qui serait rapidement disponible
dans toutes les "distributions", tout en figeant un sh pour les
anciens scripts. Tout nouveau script pourrait alors être écrit dans
ce nouveau et bon shell. Voir comment perl, ruby et python se sont
répandus: ils sont maintenant "standard de fait". Et grâce au
logiciel libre, s'ils ne sont pas disponible sur un ancien système, il
est trés simple de les y installer.
Et finalement, je n'ai pas l'impression qu'il y ait beaucoup de vieux
scripts (ou même shar) sur un système moderne (MacOSX, Linux, même
*BSD). On pourrait même assez rapidement se retrouver avec un système
purgé de tout bourne shell ou script...
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
Qui devrait marcher si le shell de l'utilisateur est Bourne ou csh type, mais pas rc.
rc ?
Le shell de plan9. Un bien meilleur shell pour les scripts que les shells Bourne-likes. N'a pas la plupart des erreurs de design introduites par ksh. es et akanga sont deux de ses descendants.
Le here-string (<<< string) que l'on trouve chez zsh et maintenant chez ksh93 puis bash vient de la par exemple.
Si les shells de maintenant etaient basés sur rc plutot que ksh, les shells ne seraient pas le bordel qu'ils sont aujourd'hui. Malheureusement, on ne peut pas revenir en arriere.
Enfin il me semble qu'il serait assez simple de specifier dans un "standard" quelconque un bon shell, qui serait rapidement disponible dans toutes les "distributions", tout en figeant un sh pour les anciens scripts. Tout nouveau script pourrait alors être écrit dans ce nouveau et bon shell. Voir comment perl, ruby et python se sont répandus: ils sont maintenant "standard de fait". Et grâce au logiciel libre, s'ils ne sont pas disponible sur un ancien système, il est trés simple de les y installer.
Et finalement, je n'ai pas l'impression qu'il y ait beaucoup de vieux scripts (ou même shar) sur un système moderne (MacOSX, Linux, même *BSD). On pourrait même assez rapidement se retrouver avec un système purgé de tout bourne shell ou script...
-- __Pascal Bourguignon__ http://www.informatimago.com/ You never feed me. Perhaps I'll sleep on your face. That will sure show you.
Moi
Pascal Bourguignon wrote:
Enfin il me semble qu'il serait assez simple de specifier dans un "standard" quelconque un bon shell, qui serait rapidement disponible dans toutes les "distributions", tout en figeant un sh pour les anciens scripts. Tout nouveau script pourrait alors être écrit dans ce nouveau et bon shell. Voir comment perl, ruby et python se sont répandus: ils sont maintenant "standard de fait". Et grâce au logiciel libre, s'ils ne sont pas disponible sur un ancien système, il est trés simple de les y installer.
Combien de mégas faut il insteller pour scripter en perl,ruby,python ? Trop à coté d'un /bin/sh de 131 kilo-octets statically linked !!
Et finalement, je n'ai pas l'impression qu'il y ait beaucoup de vieux scripts (ou même shar) sur un système moderne (MacOSX, Linux, même *BSD). On pourrait même assez rapidement se retrouver avec un système purgé de tout bourne shell ou script...
mouais, un cmd.exe fera l'affaire
Pascal Bourguignon wrote:
Enfin il me semble qu'il serait assez simple de specifier dans un
"standard" quelconque un bon shell, qui serait rapidement disponible
dans toutes les "distributions", tout en figeant un sh pour les
anciens scripts. Tout nouveau script pourrait alors être écrit dans
ce nouveau et bon shell. Voir comment perl, ruby et python se sont
répandus: ils sont maintenant "standard de fait". Et grâce au
logiciel libre, s'ils ne sont pas disponible sur un ancien système, il
est trés simple de les y installer.
Combien de mégas faut il insteller pour scripter en perl,ruby,python ?
Trop à coté d'un /bin/sh de 131 kilo-octets statically linked !!
Et finalement, je n'ai pas l'impression qu'il y ait beaucoup de vieux
scripts (ou même shar) sur un système moderne (MacOSX, Linux, même
*BSD). On pourrait même assez rapidement se retrouver avec un système
purgé de tout bourne shell ou script...
Enfin il me semble qu'il serait assez simple de specifier dans un "standard" quelconque un bon shell, qui serait rapidement disponible dans toutes les "distributions", tout en figeant un sh pour les anciens scripts. Tout nouveau script pourrait alors être écrit dans ce nouveau et bon shell. Voir comment perl, ruby et python se sont répandus: ils sont maintenant "standard de fait". Et grâce au logiciel libre, s'ils ne sont pas disponible sur un ancien système, il est trés simple de les y installer.
Combien de mégas faut il insteller pour scripter en perl,ruby,python ? Trop à coté d'un /bin/sh de 131 kilo-octets statically linked !!
Et finalement, je n'ai pas l'impression qu'il y ait beaucoup de vieux scripts (ou même shar) sur un système moderne (MacOSX, Linux, même *BSD). On pourrait même assez rapidement se retrouver avec un système purgé de tout bourne shell ou script...
