Le Wed, 05 Sep 2007 02:32:58 +0200 Thomas a écrit:
Pas forcément partout, mais quand il y a une action importante qui peut échouer, oui, c'est important.
j'ai mis ça dans mon ~/.profile : cd dossier || exit du coup, quand le dossier n'existe pas, quand j'ouvre le terminal la fenêtre se referme aussitôt
Tu as la possibilité d'exécuter le bloc d'instruction concerné dans un sous-shell.
en fait, là si ça ne marche pas on n'a pas besoin d'action particulière, donc il suffit de faire cd dossier 2> /dev/null ?
Même réponse qu'en haut. Tout dépend des commandes qui suivent et qui en dépendent. Si tu es certain que c'est bon, alors ne te gène pas. Si tu as un doute, alors mieux vaut placer l'«exit».
-- Nicolas S.
Le Wed, 05 Sep 2007 02:32:58 +0200
Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit:
Pas forcément partout, mais quand il y a une action importante qui
peut échouer, oui, c'est important.
j'ai mis ça dans mon ~/.profile :
cd dossier || exit
du coup, quand le dossier n'existe pas, quand j'ouvre le terminal la
fenêtre se referme aussitôt
Tu as la possibilité d'exécuter le bloc d'instruction concerné dans un
sous-shell.
en fait, là si ça ne marche pas on n'a pas besoin d'action
particulière, donc il suffit de faire
cd dossier 2> /dev/null
?
Même réponse qu'en haut. Tout dépend des commandes qui suivent et qui
en dépendent. Si tu es certain que c'est bon, alors ne te gène pas. Si
tu as un doute, alors mieux vaut placer l'«exit».
Le Wed, 05 Sep 2007 02:32:58 +0200 Thomas a écrit:
Pas forcément partout, mais quand il y a une action importante qui peut échouer, oui, c'est important.
j'ai mis ça dans mon ~/.profile : cd dossier || exit du coup, quand le dossier n'existe pas, quand j'ouvre le terminal la fenêtre se referme aussitôt
Tu as la possibilité d'exécuter le bloc d'instruction concerné dans un sous-shell.
en fait, là si ça ne marche pas on n'a pas besoin d'action particulière, donc il suffit de faire cd dossier 2> /dev/null ?
Même réponse qu'en haut. Tout dépend des commandes qui suivent et qui en dépendent. Si tu es certain que c'est bon, alors ne te gène pas. Si tu as un doute, alors mieux vaut placer l'«exit».
-- Nicolas S.
Thomas
In article , "Nicolas S." wrote:
Le Wed, 05 Sep 2007 02:32:58 +0200 Thomas a écrit:
Pas forcément partout, mais quand il y a une action importante qui peut échouer, oui, c'est important.
j'ai mis ça dans mon ~/.profile : cd dossier || exit du coup, quand le dossier n'existe pas, quand j'ouvre le terminal la fenêtre se referme aussitôt
Tu as la possibilité d'exécuter le bloc d'instruction concerné dans un sous-shell.
ah merci, j'y avais pas pensé (pourtant c'est logique) :-)
en fait, là si ça ne marche pas on n'a pas besoin d'action particulière, donc il suffit de faire cd dossier 2> /dev/null ?
Même réponse qu'en haut. Tout dépend des commandes qui suivent et qui en dépendent. Si tu es certain que c'est bon, alors ne te gène pas. Si tu as un doute, alors mieux vaut placer l'«exit».
merci :-)
en fait je veux juste être ailleurs que dans mon dossier de départ quand j'ouvre le terminal donc ça marche pas si je met le cd dans un sous-shell
j'ai sûrement l'air d'un idiot, mais j'aimerais quand même avoir la confirmation que je ne fais pas de bêtise :-)
-- j'agis contre l'assistanat, je travaille dans une SCOP !
In article <20070907185415.78e2040e.ni.s-factice@laposte.net>,
"Nicolas S." <ni.s-factice@laposte.net> wrote:
Le Wed, 05 Sep 2007 02:32:58 +0200
Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit:
Pas forcément partout, mais quand il y a une action importante qui
peut échouer, oui, c'est important.
j'ai mis ça dans mon ~/.profile :
cd dossier || exit
du coup, quand le dossier n'existe pas, quand j'ouvre le terminal la
fenêtre se referme aussitôt
Tu as la possibilité d'exécuter le bloc d'instruction concerné dans un
sous-shell.
ah merci, j'y avais pas pensé (pourtant c'est logique) :-)
en fait, là si ça ne marche pas on n'a pas besoin d'action
particulière, donc il suffit de faire
cd dossier 2> /dev/null
?
Même réponse qu'en haut. Tout dépend des commandes qui suivent et qui
en dépendent. Si tu es certain que c'est bon, alors ne te gène pas. Si
tu as un doute, alors mieux vaut placer l'«exit».
merci :-)
en fait je veux juste être ailleurs que dans mon dossier de départ quand
j'ouvre le terminal
donc ça marche pas si je met le cd dans un sous-shell
j'ai sûrement l'air d'un idiot, mais j'aimerais quand même avoir la
confirmation que je ne fais pas de bêtise :-)
--
j'agis contre l'assistanat, je travaille dans une SCOP !
Le Wed, 05 Sep 2007 02:32:58 +0200 Thomas a écrit:
Pas forcément partout, mais quand il y a une action importante qui peut échouer, oui, c'est important.
j'ai mis ça dans mon ~/.profile : cd dossier || exit du coup, quand le dossier n'existe pas, quand j'ouvre le terminal la fenêtre se referme aussitôt
Tu as la possibilité d'exécuter le bloc d'instruction concerné dans un sous-shell.
ah merci, j'y avais pas pensé (pourtant c'est logique) :-)
en fait, là si ça ne marche pas on n'a pas besoin d'action particulière, donc il suffit de faire cd dossier 2> /dev/null ?
Même réponse qu'en haut. Tout dépend des commandes qui suivent et qui en dépendent. Si tu es certain que c'est bon, alors ne te gène pas. Si tu as un doute, alors mieux vaut placer l'«exit».
merci :-)
en fait je veux juste être ailleurs que dans mon dossier de départ quand j'ouvre le terminal donc ça marche pas si je met le cd dans un sous-shell
j'ai sûrement l'air d'un idiot, mais j'aimerais quand même avoir la confirmation que je ne fais pas de bêtise :-)
-- j'agis contre l'assistanat, je travaille dans une SCOP !
Thomas
In article , Stephane Chazelas wrote:
2007-09-05, 02:11(+02), Thomas: [...]
Pour rediriger les erreurs. Le fd 2 d'un process est sa sortie d'erreur, le fd 1 sa sortie standard. cmd > file est un raccourci pour cmd 1> file, cmd &> file est un raccourci non-standard pour cmd 1> file 2>&1.
merci :-)
et donc "2>&1" veut dire qu'on veut rediriger le fd 2 au même endroit que le fd 1 ? :-)
Oui. Attention, > file 2>&1 n'est pas la meme chose que > file 2> file. Le premier ouvre un seul /flux/ en ecriture vers le fichier qui est assigné a la fois au fd 1 et 2, le deuxieme ouvre 2 flux separes. Dans le deuxieme cas, ce que la commande ecrirait sur ses file descriptors 1 et 2 se chevaucheraient.
merci :-)
[...]
En principe oui, a condition d'eviter que le premier caractere du fichier ne soit pas un "#".
il faut que le 1er caractère soit "#" ?
Non, desolé pour le cafouillage des negations. Si le premier caractère est "#" et que l'on essaie de lancer le script depuis un shell csh, certaines versions de csh (mais aussi de sh sur certains vieux systemes) executeront le script avec csh. Raison historique. Donc eviter le "#".
ok :-)
Mais bon, ca ne garantit pas non-plus d'avoir un shell POSIX, ca garantit d'avoir un shell POSIX que si celui qui execute le script est "en environnement POSIX" qui n'est pas tres clairement defini.
une question que j'ai oublié de poser, c'est : si on indique rien, comment ça décide avec quel shell ça va exécuter le script ??
C'est a la discretion de l'outil qui executera le script. En environnement POSIX, un outil POSIX utilisera un shell POSIX, un outil Unix utilisera un shell Unix (si disponible, qui sera par consequent POSIX aussi).
Si le script est executé au moyen des fonctions C execp, execl... la bibliotheque C fera appel a un shell POSIX.
Certains shells POSIX executeront le script dans un fils sans meme faire de exec*().
Malheureusement, il y a toujours Solaris pour faire bande a part. Il y a encore beaucoup d'outils qui sous Solaris utiliseront "/bin/sh" (qui n'est pas POSIX) pour executer le script. Le execp() de Solaris utilise aussi /bin/sh par defaut si on ne passe pas d'obscures options de compilation specifiques pour qu'il se comporte POSIXement.
bon, comme ça ne marche pas avec solaris de toutes façons, c'est p-e mieux de préciser le shell de toutes façons, même si il y a d'autres systèmes que solaris où on devra le changer ...
merci pour toutes les explications :-)
-- j'agis contre l'assistanat, je travaille dans une SCOP !
In article <slrnfdu8hn.jbv.stephane.chazelas@spam.is.invalid>,
Stephane Chazelas <cette.adresse@est.invalid> wrote:
2007-09-05, 02:11(+02), Thomas:
[...]
Pour rediriger les erreurs. Le fd 2 d'un process est sa sortie
d'erreur, le fd 1 sa sortie standard. cmd > file est un
raccourci pour cmd 1> file, cmd &> file est un raccourci
non-standard pour cmd 1> file 2>&1.
merci :-)
et donc "2>&1" veut dire qu'on veut rediriger le fd 2 au même endroit
que le fd 1 ? :-)
Oui. Attention, > file 2>&1 n'est pas la meme chose que > file
2> file. Le premier ouvre un seul /flux/ en ecriture vers le
fichier qui est assigné a la fois au fd 1 et 2, le deuxieme
ouvre 2 flux separes. Dans le deuxieme cas, ce que la commande
ecrirait sur ses file descriptors 1 et 2 se chevaucheraient.
merci :-)
[...]
En principe oui, a condition d'eviter que le premier caractere
du fichier ne soit pas un "#".
il faut que le 1er caractère soit "#" ?
Non, desolé pour le cafouillage des negations. Si le premier
caractère est "#" et que l'on essaie de lancer le script depuis
un shell csh, certaines versions de csh (mais aussi de sh sur
certains vieux systemes) executeront le script avec csh. Raison
historique. Donc eviter le "#".
ok :-)
Mais bon, ca ne garantit pas non-plus d'avoir un shell POSIX, ca
garantit d'avoir un shell POSIX que si celui qui execute le
script est "en environnement POSIX" qui n'est pas tres
clairement defini.
une question que j'ai oublié de poser, c'est :
si on indique rien, comment ça décide avec quel shell ça va exécuter le
script ??
C'est a la discretion de l'outil qui executera le script. En
environnement POSIX, un outil POSIX utilisera un shell POSIX, un
outil Unix utilisera un shell Unix (si disponible, qui sera par
consequent POSIX aussi).
Si le script est executé au moyen des fonctions C execp,
execl... la bibliotheque C fera appel a un shell POSIX.
Certains shells POSIX executeront le script dans un fils sans
meme faire de exec*().
Malheureusement, il y a toujours Solaris pour faire bande a
part. Il y a encore beaucoup d'outils qui sous Solaris
utiliseront "/bin/sh" (qui n'est pas POSIX) pour executer le
script. Le execp() de Solaris utilise aussi /bin/sh par defaut
si on ne passe pas d'obscures options de compilation specifiques
pour qu'il se comporte POSIXement.
bon, comme ça ne marche pas avec solaris de toutes façons, c'est p-e
mieux de préciser le shell de toutes façons, même si il y a d'autres
systèmes que solaris où on devra le changer ...
merci pour toutes les explications :-)
--
j'agis contre l'assistanat, je travaille dans une SCOP !
Pour rediriger les erreurs. Le fd 2 d'un process est sa sortie d'erreur, le fd 1 sa sortie standard. cmd > file est un raccourci pour cmd 1> file, cmd &> file est un raccourci non-standard pour cmd 1> file 2>&1.
merci :-)
et donc "2>&1" veut dire qu'on veut rediriger le fd 2 au même endroit que le fd 1 ? :-)
Oui. Attention, > file 2>&1 n'est pas la meme chose que > file 2> file. Le premier ouvre un seul /flux/ en ecriture vers le fichier qui est assigné a la fois au fd 1 et 2, le deuxieme ouvre 2 flux separes. Dans le deuxieme cas, ce que la commande ecrirait sur ses file descriptors 1 et 2 se chevaucheraient.
merci :-)
[...]
En principe oui, a condition d'eviter que le premier caractere du fichier ne soit pas un "#".
il faut que le 1er caractère soit "#" ?
Non, desolé pour le cafouillage des negations. Si le premier caractère est "#" et que l'on essaie de lancer le script depuis un shell csh, certaines versions de csh (mais aussi de sh sur certains vieux systemes) executeront le script avec csh. Raison historique. Donc eviter le "#".
ok :-)
Mais bon, ca ne garantit pas non-plus d'avoir un shell POSIX, ca garantit d'avoir un shell POSIX que si celui qui execute le script est "en environnement POSIX" qui n'est pas tres clairement defini.
une question que j'ai oublié de poser, c'est : si on indique rien, comment ça décide avec quel shell ça va exécuter le script ??
C'est a la discretion de l'outil qui executera le script. En environnement POSIX, un outil POSIX utilisera un shell POSIX, un outil Unix utilisera un shell Unix (si disponible, qui sera par consequent POSIX aussi).
Si le script est executé au moyen des fonctions C execp, execl... la bibliotheque C fera appel a un shell POSIX.
Certains shells POSIX executeront le script dans un fils sans meme faire de exec*().
Malheureusement, il y a toujours Solaris pour faire bande a part. Il y a encore beaucoup d'outils qui sous Solaris utiliseront "/bin/sh" (qui n'est pas POSIX) pour executer le script. Le execp() de Solaris utilise aussi /bin/sh par defaut si on ne passe pas d'obscures options de compilation specifiques pour qu'il se comporte POSIXement.
bon, comme ça ne marche pas avec solaris de toutes façons, c'est p-e mieux de préciser le shell de toutes façons, même si il y a d'autres systèmes que solaris où on devra le changer ...
merci pour toutes les explications :-)
-- j'agis contre l'assistanat, je travaille dans une SCOP !
Thomas
In article , "Nicolas S." wrote:
Tu as la possibilité d'exécuter le bloc d'instruction concerné dans un sous-shell.
j'ai oublié de te demander :
comme j'utilise abondamment "source" et les sous-shells, pour factoriser un maximum,
y a t il moyen d'indiquer un fichier avec un chemin relatif au fichier d'où on l'appelle ?
pour l'instant je suis obligé de partir du dossier de départ, avec ~/
-- j'agis contre l'assistanat, je travaille dans une SCOP !
In article <20070907185415.78e2040e.ni.s-factice@laposte.net>,
"Nicolas S." <ni.s-factice@laposte.net> wrote:
Tu as la possibilité d'exécuter le bloc d'instruction concerné dans un
sous-shell.
j'ai oublié de te demander :
comme j'utilise abondamment "source" et les sous-shells, pour factoriser
un maximum,
y a t il moyen d'indiquer un fichier avec un chemin relatif au fichier
d'où on l'appelle ?
pour l'instant je suis obligé de partir du dossier de départ, avec ~/
--
j'agis contre l'assistanat, je travaille dans une SCOP !
en fait je veux juste être ailleurs que dans mon dossier de départ quand j'ouvre le terminal donc ça marche pas si je met le cd dans un sous-shell
Si c'est vraiment ce que tu veux, tu peux rajouter un truc de ce genre en toute fin de ton ~/.profile: cd "blah" && printf 'Vous êtes dans le répertoire %b.' $PWD
-- Nicolas S.
Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit:
en fait je veux juste être ailleurs que dans mon dossier de départ
quand j'ouvre le terminal
donc ça marche pas si je met le cd dans un sous-shell
Si c'est vraiment ce que tu veux, tu peux rajouter un truc de ce genre
en toute fin de ton ~/.profile:
cd "blah" && printf 'Vous êtes dans le répertoire %b.' $PWD
en fait je veux juste être ailleurs que dans mon dossier de départ quand j'ouvre le terminal donc ça marche pas si je met le cd dans un sous-shell
Si c'est vraiment ce que tu veux, tu peux rajouter un truc de ce genre en toute fin de ton ~/.profile: cd "blah" && printf 'Vous êtes dans le répertoire %b.' $PWD
