Considérons mon infrastructure. J'ai un serveur principal qui tourne
sous NetBSD (serveur de boot, serveur NIS/NFSv3) et qui se débrouille
pour exporter tout ce qu'il faut à un certain nombre de stations
diskless. Ces stations fonctionnent sous FreeBSD et Linux/Debian.
Problème : bash est par défaut sous Debian dans /bin/bash. Sous
FreeBSD, il se trouve dans /usr/local/bin/bash. Sous NetBSD, c'est dans
/usr/pkg/bin/bash.
Je me suis cru malin en écrivant :
#!/bin/sh
if [ `uname -s` = Linux ]; then
/bin/bash
else
if [ -e /usr/pkg/bin/bash ]; then
/usr/pkg/bin/bash
else
/bin/sh
fi
fi
exit 0
et en déclarant ce script comme shell de l'utilisateur.
J'arrive à me connecter à n'importe quelle machine en ssh sans aucun
problème. Mais il m'est impossible d'effectuer en sftp.
Je suppose qu'il existe un mécanisme dans ssh spécifique à sftp pour
refuser cette astuce mais je sèche.
Via env, cela donne quoi ? #!/usr/bin/env bash gaby -- Gabriel Moreau - IR CNRS http://www.legi.grenoble-inp.fr LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France mailto: tel:+33.476.825.015
BERTRAND Jo=c3=abl
Gabriel Moreau a écrit :
#!/bin/sh
Via env, cela donne quoi ? #!/usr/bin/env bash
Pareil. Mais /bin/sh étant présent sur tous les systèmes, je doute que ce soit le fautif (d'autant que je peux me connecter par ssh sur toutes les machines). Bien cordialement, JKB
Gabriel Moreau a écrit :
#!/bin/sh
Via env, cela donne quoi ?
#!/usr/bin/env bash
Pareil. Mais /bin/sh étant présent sur tous les systèmes, je doute que
ce soit le fautif (d'autant que je peux me connecter par ssh sur toutes
les machines).
Pareil. Mais /bin/sh étant présent sur tous les systèmes, je doute que ce soit le fautif (d'autant que je peux me connecter par ssh sur toutes les machines). Bien cordialement, JKB
=c3
On 02/12/2018 04:01 PM, BERTRAND Joël wrote:
J'arrive à me connecter à n'importe quelle machine en ssh sans aucun problème. Mais il m'est impossible d'effectuer en sftp.
Bonsoir, Au risque de passer à côté du sujet, j'ai rencontré un problème similaire. Si j'édite le fichier de ressource de mon shell pour lui faire afficher quelque chose, alors ça me plante sftp, mais pas ssh : $ head -n2 ~/.bashrc #!/bin/bash echo plante $ ssh localhost plante $ echo 'Dans une session ssh... :)' Dans une session ssh... :) $ sftp localhost Received message too long 1886151022 $ echo 'Pas dans une session sftp... :(' Pas dans une session sftp... :( « Il suffit » d'enlever tout ce qui pourrait écrire dans stdout pour corriger le problème. Si j'efface mon « echo plante », alors le problème est corrigé : $ head -n2 ~/.bashrc #!/bin/bash $ sftp localhost Connected to localhost. sftp> Sauf que, et à moins que j'ai loupé quelque chose, votre script ne devrait pas engendrer de message dans stdout. Est-ce que le problème se présentait si vous aviez l'un des bash codé en dur dans votre entrée NIS, en vous loguant en sftp sur le système correspondant ? À plus, -- Étienne Mollier
On 02/12/2018 04:01 PM, BERTRAND Joël wrote:
J'arrive à me connecter à n'importe quelle machine en ssh
sans aucun problème. Mais il m'est impossible d'effectuer en
sftp.
Bonsoir,
Au risque de passer à côté du sujet, j'ai rencontré un problème
similaire. Si j'édite le fichier de ressource de mon shell pour
lui faire afficher quelque chose, alors ça me plante sftp, mais
pas ssh :
$ head -n2 ~/.bashrc
#!/bin/bash
echo plante
$ ssh localhost
plante
$ echo 'Dans une session ssh... :)'
Dans une session ssh... :)
$ sftp localhost
Received message too long 1886151022
$ echo 'Pas dans une session sftp... :('
Pas dans une session sftp... :(
« Il suffit » d'enlever tout ce qui pourrait écrire dans stdout
pour corriger le problème. Si j'efface mon « echo plante »,
alors le problème est corrigé :
$ head -n2 ~/.bashrc
#!/bin/bash
$ sftp localhost
Connected to localhost.
sftp>
Sauf que, et à moins que j'ai loupé quelque chose, votre script
ne devrait pas engendrer de message dans stdout. Est-ce que le
problème se présentait si vous aviez l'un des bash codé en dur
dans votre entrée NIS, en vous loguant en sftp sur le système
correspondant ?
À plus,
--
Étienne Mollier <etienne.mollier@mailoo.org>
J'arrive à me connecter à n'importe quelle machine en ssh sans aucun problème. Mais il m'est impossible d'effectuer en sftp.
Bonsoir, Au risque de passer à côté du sujet, j'ai rencontré un problème similaire. Si j'édite le fichier de ressource de mon shell pour lui faire afficher quelque chose, alors ça me plante sftp, mais pas ssh : $ head -n2 ~/.bashrc #!/bin/bash echo plante $ ssh localhost plante $ echo 'Dans une session ssh... :)' Dans une session ssh... :) $ sftp localhost Received message too long 1886151022 $ echo 'Pas dans une session sftp... :(' Pas dans une session sftp... :( « Il suffit » d'enlever tout ce qui pourrait écrire dans stdout pour corriger le problème. Si j'efface mon « echo plante », alors le problème est corrigé : $ head -n2 ~/.bashrc #!/bin/bash $ sftp localhost Connected to localhost. sftp> Sauf que, et à moins que j'ai loupé quelque chose, votre script ne devrait pas engendrer de message dans stdout. Est-ce que le problème se présentait si vous aviez l'un des bash codé en dur dans votre entrée NIS, en vous loguant en sftp sur le système correspondant ? À plus, -- Étienne Mollier
BERTRAND Jo=c3=abl
Étienne Mollier a écrit :
On 02/12/2018 04:01 PM, BERTRAND Joël wrote:
J'arrive à me connecter à n'importe quelle machine en ssh sans aucun problème. Mais il m'est impossible d'effectuer en sftp.
Bonsoir, Au risque de passer à côté du sujet, j'ai rencontré un problème similaire. Si j'édite le fichier de ressource de mon shell pour lui faire afficher quelque chose, alors ça me plante sftp, mais pas ssh : $ head -n2 ~/.bashrc #!/bin/bash echo plante $ ssh localhost plante $ echo 'Dans une session ssh... :)' Dans une session ssh... :) $ sftp localhost Received message too long 1886151022 $ echo 'Pas dans une session sftp... :(' Pas dans une session sftp... :( « Il suffit » d'enlever tout ce qui pourrait écrire dans stdout pour corriger le problème. Si j'efface mon « echo plante », alors le problème est corrigé : $ head -n2 ~/.bashrc #!/bin/bash $ sftp localhost Connected to localhost. sftp> Sauf que, et à moins que j'ai loupé quelque chose, votre script ne devrait pas engendrer de message dans stdout.
Effectivement, le script en question ne renvoie rien sur stdout (ni sur stderr du reste).
Est-ce que le problème se présentait si vous aviez l'un des bash codé en dur dans votre entrée NIS, en vous loguant en sftp sur le système correspondant ?
Si je mets l'un des bash en dur, ça fonctionne sur le poste en question (mais pas sur les autres...). La question que je me suis posé est de savoir si /etc/shells doit contenir mon script ou non. Visiblement non puisque l'exécutable réel est le vrai shell. Bien cordialement, JKB
Étienne Mollier a écrit :
On 02/12/2018 04:01 PM, BERTRAND Joël wrote:
J'arrive à me connecter à n'importe quelle machine en ssh
sans aucun problème. Mais il m'est impossible d'effectuer en
sftp.
Bonsoir,
Au risque de passer à côté du sujet, j'ai rencontré un problème
similaire. Si j'édite le fichier de ressource de mon shell pour
lui faire afficher quelque chose, alors ça me plante sftp, mais
pas ssh :
$ head -n2 ~/.bashrc
#!/bin/bash
echo plante
$ ssh localhost
plante
$ echo 'Dans une session ssh... :)'
Dans une session ssh... :)
$ sftp localhost
Received message too long 1886151022
$ echo 'Pas dans une session sftp... :('
Pas dans une session sftp... :(
« Il suffit » d'enlever tout ce qui pourrait écrire dans stdout
pour corriger le problème. Si j'efface mon « echo plante »,
alors le problème est corrigé :
$ head -n2 ~/.bashrc
#!/bin/bash
$ sftp localhost
Connected to localhost.
sftp>
Sauf que, et à moins que j'ai loupé quelque chose, votre script
ne devrait pas engendrer de message dans stdout.
Effectivement, le script en question ne renvoie rien sur stdout (ni sur
stderr du reste).
Est-ce que le
problème se présentait si vous aviez l'un des bash codé en dur
dans votre entrée NIS, en vous loguant en sftp sur le système
correspondant ?
Si je mets l'un des bash en dur, ça fonctionne sur le poste en question
(mais pas sur les autres...).
La question que je me suis posé est de savoir si /etc/shells doit
contenir mon script ou non. Visiblement non puisque l'exécutable réel
est le vrai shell.
J'arrive à me connecter à n'importe quelle machine en ssh sans aucun problème. Mais il m'est impossible d'effectuer en sftp.
Bonsoir, Au risque de passer à côté du sujet, j'ai rencontré un problème similaire. Si j'édite le fichier de ressource de mon shell pour lui faire afficher quelque chose, alors ça me plante sftp, mais pas ssh : $ head -n2 ~/.bashrc #!/bin/bash echo plante $ ssh localhost plante $ echo 'Dans une session ssh... :)' Dans une session ssh... :) $ sftp localhost Received message too long 1886151022 $ echo 'Pas dans une session sftp... :(' Pas dans une session sftp... :( « Il suffit » d'enlever tout ce qui pourrait écrire dans stdout pour corriger le problème. Si j'efface mon « echo plante », alors le problème est corrigé : $ head -n2 ~/.bashrc #!/bin/bash $ sftp localhost Connected to localhost. sftp> Sauf que, et à moins que j'ai loupé quelque chose, votre script ne devrait pas engendrer de message dans stdout.
Effectivement, le script en question ne renvoie rien sur stdout (ni sur stderr du reste).
Est-ce que le problème se présentait si vous aviez l'un des bash codé en dur dans votre entrée NIS, en vous loguant en sftp sur le système correspondant ?
Si je mets l'un des bash en dur, ça fonctionne sur le poste en question (mais pas sur les autres...). La question que je me suis posé est de savoir si /etc/shells doit contenir mon script ou non. Visiblement non puisque l'exécutable réel est le vrai shell. Bien cordialement, JKB
Francois Lafont
Bonjour, Bonjour, Pardon, j'ai envoyé mon message en privé au lieu de l'envoyer sur la liste. Je reposte. On 02/12/2018 04:01 PM, BERTRAND Joël wrote:
Je me suis cru malin en écrivant : #!/bin/sh if [ `uname -s` = Linux ]; then /bin/bash else if [ -e /usr/pkg/bin/bash ]; then /usr/pkg/bin/bash else /bin/sh fi fi exit 0
Ce script ne prend en charge aucun argument alors qu'en principe c'est le cas d'un shell. Éventuellement tenter de faire ça (où "$@" permet de reprendre les arguments passés au script) : ------------------------ #!/bin/sh if [ `uname -s` = Linux ]; then /bin/bash "$@" else if [ -e /usr/pkg/bin/bash ]; then /usr/pkg/bin/bash "$@" else /bin/sh "$@" fi fi ------------------------ Enfin si bash est correctement installé sur le système, la logique voudrait qu'il soit dans le PATH. Dans ce cas, je tenterais plutôt : if which bash >/dev/null then bash "$@" else /bin/sh "$@" fi -- François Lafont
Bonjour,
Bonjour,
Pardon, j'ai envoyé mon message en privé au lieu de l'envoyer sur la liste.
Je reposte.
On 02/12/2018 04:01 PM, BERTRAND Joël wrote:
Je me suis cru malin en écrivant :
#!/bin/sh
if [ `uname -s` = Linux ]; then
/bin/bash
else
if [ -e /usr/pkg/bin/bash ]; then
/usr/pkg/bin/bash
else
/bin/sh
fi
fi
exit 0
Ce script ne prend en charge aucun argument alors qu'en principe
c'est le cas d'un shell. Éventuellement tenter de faire ça (où
"$@" permet de reprendre les arguments passés au script) :
------------------------
#!/bin/sh
if [ `uname -s` = Linux ]; then
/bin/bash "$@"
else
if [ -e /usr/pkg/bin/bash ]; then
/usr/pkg/bin/bash "$@"
else
/bin/sh "$@"
fi
fi
------------------------
Enfin si bash est correctement installé sur le système, la logique
voudrait qu'il soit dans le PATH. Dans ce cas, je tenterais plutôt :
if which bash >/dev/null
then
bash "$@"
else
/bin/sh "$@"
fi
Bonjour, Bonjour, Pardon, j'ai envoyé mon message en privé au lieu de l'envoyer sur la liste. Je reposte. On 02/12/2018 04:01 PM, BERTRAND Joël wrote:
Je me suis cru malin en écrivant : #!/bin/sh if [ `uname -s` = Linux ]; then /bin/bash else if [ -e /usr/pkg/bin/bash ]; then /usr/pkg/bin/bash else /bin/sh fi fi exit 0
Ce script ne prend en charge aucun argument alors qu'en principe c'est le cas d'un shell. Éventuellement tenter de faire ça (où "$@" permet de reprendre les arguments passés au script) : ------------------------ #!/bin/sh if [ `uname -s` = Linux ]; then /bin/bash "$@" else if [ -e /usr/pkg/bin/bash ]; then /usr/pkg/bin/bash "$@" else /bin/sh "$@" fi fi ------------------------ Enfin si bash est correctement installé sur le système, la logique voudrait qu'il soit dans le PATH. Dans ce cas, je tenterais plutôt : if which bash >/dev/null then bash "$@" else /bin/sh "$@" fi -- François Lafont
Gabriel Moreau
if [ `uname -s` = Linux ]; then
Je remplace juste ce test par celui-là if [ "$(uname -s)" = Linux ]; then cela permet d'assurer à 100% d'avoir une vraie chaîne à gauche et sur le principe, le $() est plus sur que le `` (car récursif). gabriel -- Gabriel Moreau - IR CNRS http://www.legi.grenoble-inp.fr LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France mailto: tel:+33.476.825.015
if [ `uname -s` = Linux ]; then
Je remplace juste ce test par celui-là
if [ "$(uname -s)" = Linux ]; then
cela permet d'assurer à 100% d'avoir une vraie chaîne à gauche
et sur le principe, le $() est plus sur que le `` (car récursif).
gabriel
--
Gabriel Moreau - IR CNRS http://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France
mailto:Gabriel.Moreau@legi.grenoble-inp.fr tel:+33.476.825.015
Je remplace juste ce test par celui-là if [ "$(uname -s)" = Linux ]; then cela permet d'assurer à 100% d'avoir une vraie chaîne à gauche et sur le principe, le $() est plus sur que le `` (car récursif). gabriel -- Gabriel Moreau - IR CNRS http://www.legi.grenoble-inp.fr LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France mailto: tel:+33.476.825.015
=c3
Joël Bertrand, le 2018-02-13 :
Étienne Mollier a écrit :
Est-ce que le problème se présentait si vous aviez l'un des bash codé en dur dans votre entrée NIS, en vous loguant en sftp sur le système correspondant ?
Si je mets l'un des bash en dur, ça fonctionne sur le poste en question (mais pas sur les autres...).
D'accord, on peut écarter ce problème de sortie texte.
La question que je me suis posé est de savoir si /etc/shells doit contenir mon script ou non. Visiblement non puisque l'exécutable réel est le vrai shell.
Dans le doute, je l'y mettrais tout de même. Si j'en juge par le manuel, les vénérables dæmons ftp pouvaient interdire l'accès s'ils ne trouvaient pas le shell de l'utilisateur dans la liste fournie par le fichier /etc/shells. man 5 shells :
Be aware that there are programs which consult this file to find out if a user is a normal user; for example, FTP daemons traditionally disallow access to users with shells not included in this file.
Ça n'apparaît pas dans le manuel de sftp, mais rien ne dit qu'il n'a pas hérité, ou n'héritera pas, de ce comportement. François Lafont, le 2018-02-13 :
On 02/12/2018 04:01 PM, BERTRAND Joël wrote:
Je me suis cru malin en écrivant : #!/bin/sh if [ `uname -s` = Linux ]; then /bin/bash else if [ -e /usr/pkg/bin/bash ]; then /usr/pkg/bin/bash else /bin/sh fi fi exit 0
Ce script ne prend en charge aucun argument alors qu'en principe c'est le cas d'un shell. Éventuellement tenter de faire ça (où "$@" permet de reprendre les arguments passés au script) : ------------------------ #!/bin/sh if [ `uname -s` = Linux ]; then /bin/bash "$@" else if [ -e /usr/pkg/bin/bash ]; then /usr/pkg/bin/bash "$@" else /bin/sh "$@" fi fi ------------------------ Enfin si bash est correctement installé sur le système, la logique voudrait qu'il soit dans le PATH. Dans ce cas, je tenterais plutôt : if which bash >/dev/null then bash "$@" else /bin/sh "$@" fi
Bien vu, sans le transfert des arguments, l'option de login shell « -l » ne peut pas être transférée par le wrapper au shell du système. Il y a fort à parier que ça aide à résoudre pas mal de problèmes. :-) Pour aller encore plus loin, il est possible de transférer complètement la main au shell et obtenir du même coup la remontée des éventuels codes d'erreurs en ajoutant des directives exec. Cela donnerait : #!/bin/sh if which bash >/dev/null then exec bash "$@" fi exec /bin/sh "$@" À plus, -- Étienne Mollier
Joël Bertrand, le 2018-02-13 :
Étienne Mollier a écrit :
> Est-ce que le problème se présentait si vous aviez l'un des
> bash codé en dur dans votre entrée NIS, en vous loguant en
> sftp sur le système correspondant ?
Si je mets l'un des bash en dur, ça fonctionne sur le
poste en question (mais pas sur les autres...).
D'accord, on peut écarter ce problème de sortie texte.
La question que je me suis posé est de savoir si
/etc/shells doit contenir mon script ou non. Visiblement non
puisque l'exécutable réel est le vrai shell.
Dans le doute, je l'y mettrais tout de même. Si j'en juge par le
manuel, les vénérables dæmons ftp pouvaient interdire l'accès
s'ils ne trouvaient pas le shell de l'utilisateur dans la liste
fournie par le fichier /etc/shells.
man 5 shells :
Be aware that there are programs which consult this file
to find out if a user is a normal user; for example, FTP
daemons traditionally disallow access to users with
shells not included in this file.
Ça n'apparaît pas dans le manuel de sftp, mais rien ne dit qu'il
n'a pas hérité, ou n'héritera pas, de ce comportement.
François Lafont, le 2018-02-13 :
On 02/12/2018 04:01 PM, BERTRAND Joël wrote:
> Je me suis cru malin en écrivant :
>
> #!/bin/sh
> if [ `uname -s` = Linux ]; then
> /bin/bash
> else
> if [ -e /usr/pkg/bin/bash ]; then
> /usr/pkg/bin/bash
> else
> /bin/sh
> fi
> fi
> exit 0
Ce script ne prend en charge aucun argument alors qu'en
principe c'est le cas d'un shell. Éventuellement tenter de
faire ça (où "$@" permet de reprendre les arguments passés au
script) :
------------------------
#!/bin/sh
if [ `uname -s` = Linux ]; then
/bin/bash "$@"
else
if [ -e /usr/pkg/bin/bash ]; then
/usr/pkg/bin/bash "$@"
else
/bin/sh "$@"
fi
fi
------------------------
Enfin si bash est correctement installé sur le système, la
logique voudrait qu'il soit dans le PATH. Dans ce cas, je
tenterais plutôt :
if which bash >/dev/null
then
bash "$@"
else
/bin/sh "$@"
fi
Bien vu, sans le transfert des arguments, l'option de login shell
« -l » ne peut pas être transférée par le wrapper au shell du
système. Il y a fort à parier que ça aide à résoudre pas mal de
problèmes. :-)
Pour aller encore plus loin, il est possible de transférer
complètement la main au shell et obtenir du même coup la remontée
des éventuels codes d'erreurs en ajoutant des directives exec.
Cela donnerait :
#!/bin/sh
if which bash >/dev/null
then
exec bash "$@"
fi
exec /bin/sh "$@"
À plus,
--
Étienne Mollier <etienne.mollier@mailoo.org>
Est-ce que le problème se présentait si vous aviez l'un des bash codé en dur dans votre entrée NIS, en vous loguant en sftp sur le système correspondant ?
Si je mets l'un des bash en dur, ça fonctionne sur le poste en question (mais pas sur les autres...).
D'accord, on peut écarter ce problème de sortie texte.
La question que je me suis posé est de savoir si /etc/shells doit contenir mon script ou non. Visiblement non puisque l'exécutable réel est le vrai shell.
Dans le doute, je l'y mettrais tout de même. Si j'en juge par le manuel, les vénérables dæmons ftp pouvaient interdire l'accès s'ils ne trouvaient pas le shell de l'utilisateur dans la liste fournie par le fichier /etc/shells. man 5 shells :
Be aware that there are programs which consult this file to find out if a user is a normal user; for example, FTP daemons traditionally disallow access to users with shells not included in this file.
Ça n'apparaît pas dans le manuel de sftp, mais rien ne dit qu'il n'a pas hérité, ou n'héritera pas, de ce comportement. François Lafont, le 2018-02-13 :
On 02/12/2018 04:01 PM, BERTRAND Joël wrote:
Je me suis cru malin en écrivant : #!/bin/sh if [ `uname -s` = Linux ]; then /bin/bash else if [ -e /usr/pkg/bin/bash ]; then /usr/pkg/bin/bash else /bin/sh fi fi exit 0
Ce script ne prend en charge aucun argument alors qu'en principe c'est le cas d'un shell. Éventuellement tenter de faire ça (où "$@" permet de reprendre les arguments passés au script) : ------------------------ #!/bin/sh if [ `uname -s` = Linux ]; then /bin/bash "$@" else if [ -e /usr/pkg/bin/bash ]; then /usr/pkg/bin/bash "$@" else /bin/sh "$@" fi fi ------------------------ Enfin si bash est correctement installé sur le système, la logique voudrait qu'il soit dans le PATH. Dans ce cas, je tenterais plutôt : if which bash >/dev/null then bash "$@" else /bin/sh "$@" fi
Bien vu, sans le transfert des arguments, l'option de login shell « -l » ne peut pas être transférée par le wrapper au shell du système. Il y a fort à parier que ça aide à résoudre pas mal de problèmes. :-) Pour aller encore plus loin, il est possible de transférer complètement la main au shell et obtenir du même coup la remontée des éventuels codes d'erreurs en ajoutant des directives exec. Cela donnerait : #!/bin/sh if which bash >/dev/null then exec bash "$@" fi exec /bin/sh "$@" À plus, -- Étienne Mollier
Francois Lafont
On 02/13/2018 09:03 PM, Étienne Mollier wrote:
Pour aller encore plus loin, il est possible de transférer complètement la main au shell et obtenir du même coup la remontée des éventuels codes d'erreurs en ajoutant des directives exec. Cela donnerait : #!/bin/sh if which bash >/dev/null then exec bash "$@" fi exec /bin/sh "$@"
Ah oui, tout à fait, c'est encore mieux avec le exec. :) -- François Lafont
On 02/13/2018 09:03 PM, Étienne Mollier wrote:
Pour aller encore plus loin, il est possible de transférer
complètement la main au shell et obtenir du même coup la remontée
des éventuels codes d'erreurs en ajoutant des directives exec.
Cela donnerait :
#!/bin/sh
if which bash >/dev/null
then
exec bash "$@"
fi
exec /bin/sh "$@"
Ah oui, tout à fait, c'est encore mieux avec le exec. :)
Pour aller encore plus loin, il est possible de transférer complètement la main au shell et obtenir du même coup la remontée des éventuels codes d'erreurs en ajoutant des directives exec. Cela donnerait : #!/bin/sh if which bash >/dev/null then exec bash "$@" fi exec /bin/sh "$@"
Ah oui, tout à fait, c'est encore mieux avec le exec. :) -- François Lafont
BERTRAND Jo=c3=abl
Francois Lafont a écrit :
On 02/13/2018 09:03 PM, Étienne Mollier wrote:
Pour aller encore plus loin, il est possible de transférer complètement la main au shell et obtenir du même coup la remontée des éventuels codes d'erreurs en ajoutant des directives exec. Cela donnerait : #!/bin/sh if which bash >/dev/null then exec bash "$@" fi exec /bin/sh "$@"
Ah oui, tout à fait, c'est encore mieux avec le exec. :)
Bonsoir à tous, Je vais regarder tout cela attentivement et ferai un retour dès que possible (j'ai un truc beaucoup plus important sur le feu). Bien cordialement, -- http://www.systella.fr
Francois Lafont a écrit :
On 02/13/2018 09:03 PM, Étienne Mollier wrote:
Pour aller encore plus loin, il est possible de transférer
complètement la main au shell et obtenir du même coup la remontée
des éventuels codes d'erreurs en ajoutant des directives exec.
Cela donnerait :
#!/bin/sh
if which bash >/dev/null
then
exec bash "$@"
fi
exec /bin/sh "$@"
Ah oui, tout à fait, c'est encore mieux avec le exec. :)
Bonsoir à tous,
Je vais regarder tout cela attentivement et ferai un retour dès que
possible (j'ai un truc beaucoup plus important sur le feu).
Pour aller encore plus loin, il est possible de transférer complètement la main au shell et obtenir du même coup la remontée des éventuels codes d'erreurs en ajoutant des directives exec. Cela donnerait : #!/bin/sh if which bash >/dev/null then exec bash "$@" fi exec /bin/sh "$@"
Ah oui, tout à fait, c'est encore mieux avec le exec. :)
Bonsoir à tous, Je vais regarder tout cela attentivement et ferai un retour dès que possible (j'ai un truc beaucoup plus important sur le feu). Bien cordialement, -- http://www.systella.fr
