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
Alain Ketterlin
Thomas writes:
1) déjÍ pour me repérer : sur mon vieux mac : + sh --version GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0) Copyright (C) 2007 Free Software Foundation, Inc. sur Ubuntu 16.4 : $ sh --version sh: 0: Illegal option -- $ man sh NAME dash -- command interpreter (shell) y a-t-il moyen de connaitre la version ?
dpkg -s dash (la ligne Version donne <version-upstream>-<version-ubuntu>)
2) redirection de sorties : je souhaite rediriger stdout et stderr dans le même fichier. sur mon vieux mac, je faisais : ( commande ) &> "fichier.log" & et ça marchais très bien. sur Ubuntu 16.4, ça ne marche pas. - pourquoi ? - comment faire ?
- c'est pas Posix - on fait : ... 1> fichier.log 2>&1 ... -- Alain.
Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:
1)
déjÍ pour me repérer :
sur mon vieux mac :
+ sh --version
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0)
Copyright (C) 2007 Free Software Foundation, Inc.
sur Ubuntu 16.4 :
$ sh --version
sh: 0: Illegal option --
$ man sh
NAME
dash -- command interpreter (shell)
y a-t-il moyen de connaitre la version ?
dpkg -s dash (la ligne Version donne <version-upstream>-<version-ubuntu>)
2)
redirection de sorties :
je souhaite rediriger stdout et stderr dans le même fichier.
sur mon vieux mac, je faisais :
( commande ) &> "fichier.log" &
et ça marchais très bien.
sur Ubuntu 16.4, ça ne marche pas.
- pourquoi ?
- comment faire ?
- c'est pas Posix
- on fait : ... 1> fichier.log 2>&1 ...
1) déjÍ pour me repérer : sur mon vieux mac : + sh --version GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0) Copyright (C) 2007 Free Software Foundation, Inc. sur Ubuntu 16.4 : $ sh --version sh: 0: Illegal option -- $ man sh NAME dash -- command interpreter (shell) y a-t-il moyen de connaitre la version ?
dpkg -s dash (la ligne Version donne <version-upstream>-<version-ubuntu>)
2) redirection de sorties : je souhaite rediriger stdout et stderr dans le même fichier. sur mon vieux mac, je faisais : ( commande ) &> "fichier.log" & et ça marchais très bien. sur Ubuntu 16.4, ça ne marche pas. - pourquoi ? - comment faire ?
- c'est pas Posix - on fait : ... 1> fichier.log 2>&1 ... -- Alain.
Thomas
In article , Alain Ketterlin wrote:
Thomas writes:
1) déjÍ pour me repérer : sur mon vieux mac : + sh --version GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0) Copyright (C) 2007 Free Software Foundation, Inc. sur Ubuntu 16.4 : $ sh --version sh: 0: Illegal option -- $ man sh NAME dash -- command interpreter (shell) y a-t-il moyen de connaitre la version ?
dpkg -s dash (la ligne Version donne <version-upstream>-<version-ubuntu>)
merci :-) (j'ai l'impression que tu n'en as pas besoin, dis moi si je me trompe.)
2) redirection de sorties : je souhaite rediriger stdout et stderr dans le même fichier. sur mon vieux mac, je faisais : ( commande ) &> "fichier.log" & et ça marchais très bien. sur Ubuntu 16.4, ça ne marche pas. - pourquoi ? - comment faire ?
- c'est pas Posix
ok
- on fait : ... 1> fichier.log 2>&1 ...
c'est bête qu'on doive en mettre de chaque coté du nom du fichier, y a-t-il un moyen plus compact, du genre : ... 2>&1 1> fichier.log ... ? (intérêt : remplacement automatique avec moins de risque de se tromper ou d'en oublier, par ex) merci bcp :-) -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
In article <8735jhxx27.fsf@universite-de-strasbourg.fr.invalid>,
Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> wrote:
Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:
> 1)
> déjÍ pour me repérer :
>
> sur mon vieux mac :
> + sh --version
> GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0)
> Copyright (C) 2007 Free Software Foundation, Inc.
>
> sur Ubuntu 16.4 :
> $ sh --version
> sh: 0: Illegal option --
> $ man sh
> NAME
> dash -- command interpreter (shell)
>
> y a-t-il moyen de connaitre la version ?
dpkg -s dash (la ligne Version donne <version-upstream>-<version-ubuntu>)
merci :-)
(j'ai l'impression que tu n'en as pas besoin, dis moi si je me trompe.)
> 2)
> redirection de sorties :
>
> je souhaite rediriger stdout et stderr dans le même fichier.
>
> sur mon vieux mac, je faisais :
> ( commande ) &> "fichier.log" &
> et ça marchais très bien.
>
> sur Ubuntu 16.4, ça ne marche pas.
>
> - pourquoi ?
> - comment faire ?
- c'est pas Posix
ok
- on fait : ... 1> fichier.log 2>&1 ...
c'est bête qu'on doive en mettre de chaque coté du nom du fichier,
y a-t-il un moyen plus compact, du genre : ... 2>&1 1> fichier.log ... ?
(intérêt : remplacement automatique avec moins de risque de se tromper
ou d'en oublier, par ex)
1) déjÍ pour me repérer : sur mon vieux mac : + sh --version GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0) Copyright (C) 2007 Free Software Foundation, Inc. sur Ubuntu 16.4 : $ sh --version sh: 0: Illegal option -- $ man sh NAME dash -- command interpreter (shell) y a-t-il moyen de connaitre la version ?
dpkg -s dash (la ligne Version donne <version-upstream>-<version-ubuntu>)
merci :-) (j'ai l'impression que tu n'en as pas besoin, dis moi si je me trompe.)
2) redirection de sorties : je souhaite rediriger stdout et stderr dans le même fichier. sur mon vieux mac, je faisais : ( commande ) &> "fichier.log" & et ça marchais très bien. sur Ubuntu 16.4, ça ne marche pas. - pourquoi ? - comment faire ?
- c'est pas Posix
ok
- on fait : ... 1> fichier.log 2>&1 ...
c'est bête qu'on doive en mettre de chaque coté du nom du fichier, y a-t-il un moyen plus compact, du genre : ... 2>&1 1> fichier.log ... ? (intérêt : remplacement automatique avec moins de risque de se tromper ou d'en oublier, par ex) merci bcp :-) -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
Alain Ketterlin
Thomas writes:
- on fait : ... 1> fichier.log 2>&1 ...
Je ne sais pas pourquoi j'ai écrit "1> fichier.log", le 1 n'est pas nécessaire (mais inoffensif). Donc "commande > fichier.log 2>&1"
c'est bête qu'on doive en mettre de chaque coté du nom du fichier, y a-t-il un moyen plus compact, du genre : ... 2>&1 1> fichier.log ... ?
L'ordre est important, les redirections sont faites de gauche Í droite (Il n'y a pas "deux cotés" du nom du fichier.) Dans ton exemple, l'effet est : 1) 2>&1 : renvoie l'erreur (2) sur la même chose que la sortie (1, le terminal, Í ce stade) 2) 1> fichier.log (ou simplement "> fichier.log") : renvoie la sortie sur le fichier Donc l'erreur standard reste affectée au terminal (ou Í ce Í quoi était affectée la sortie standard au moment o͹ elle a été dupliquée).
(intérêt : remplacement automatique avec moins de risque de se tromper ou d'en oublier, par ex)
C'est plus compliqué que ça, c'est un langage général de manipulation des descripteurs de fichiers. Par exemple : commande 3>&1 1>&2 2>&3 3>&- intervertit sortie et erreur standard. L'opérateur [n]>&[m] ferme [n] (s'il est ouvert) et le remplace par une copie de [m]. Bref, c'est un langage pour traduire les appels système de manipulation des descripteurs de fichiers (open/close/dup). -- Alain.
Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:
- on fait : ... 1> fichier.log 2>&1 ...
Je ne sais pas pourquoi j'ai écrit "1> fichier.log", le 1 n'est pas
nécessaire (mais inoffensif). Donc "commande > fichier.log 2>&1"
c'est bête qu'on doive en mettre de chaque coté du nom du fichier,
y a-t-il un moyen plus compact, du genre : ... 2>&1 1> fichier.log ... ?
L'ordre est important, les redirections sont faites de gauche Í droite
(Il n'y a pas "deux cotés" du nom du fichier.) Dans ton exemple, l'effet
est :
1) 2>&1 : renvoie l'erreur (2) sur la même chose que la sortie (1, le
terminal, Í ce stade)
2) 1> fichier.log (ou simplement "> fichier.log") : renvoie la sortie
sur le fichier
Donc l'erreur standard reste affectée au terminal (ou Í ce Í quoi était
affectée la sortie standard au moment o͹ elle a été dupliquée).
(intérêt : remplacement automatique avec moins de risque de se tromper
ou d'en oublier, par ex)
C'est plus compliqué que ça, c'est un langage général de manipulation
des descripteurs de fichiers. Par exemple :
commande 3>&1 1>&2 2>&3 3>&-
intervertit sortie et erreur standard. L'opérateur [n]>&[m] ferme [n]
(s'il est ouvert) et le remplace par une copie de [m]. Bref, c'est un
langage pour traduire les appels système de manipulation des descripteurs
de fichiers (open/close/dup).
Je ne sais pas pourquoi j'ai écrit "1> fichier.log", le 1 n'est pas nécessaire (mais inoffensif). Donc "commande > fichier.log 2>&1"
c'est bête qu'on doive en mettre de chaque coté du nom du fichier, y a-t-il un moyen plus compact, du genre : ... 2>&1 1> fichier.log ... ?
L'ordre est important, les redirections sont faites de gauche Í droite (Il n'y a pas "deux cotés" du nom du fichier.) Dans ton exemple, l'effet est : 1) 2>&1 : renvoie l'erreur (2) sur la même chose que la sortie (1, le terminal, Í ce stade) 2) 1> fichier.log (ou simplement "> fichier.log") : renvoie la sortie sur le fichier Donc l'erreur standard reste affectée au terminal (ou Í ce Í quoi était affectée la sortie standard au moment o͹ elle a été dupliquée).
(intérêt : remplacement automatique avec moins de risque de se tromper ou d'en oublier, par ex)
C'est plus compliqué que ça, c'est un langage général de manipulation des descripteurs de fichiers. Par exemple : commande 3>&1 1>&2 2>&3 3>&- intervertit sortie et erreur standard. L'opérateur [n]>&[m] ferme [n] (s'il est ouvert) et le remplace par une copie de [m]. Bref, c'est un langage pour traduire les appels système de manipulation des descripteurs de fichiers (open/close/dup). -- Alain.
Nicolas George
Alain Ketterlin , dans le message , a écrit :
L'ordre est important, les redirections sont faites de gauche Í droite
Sauf |, qui s'écrit en dernier mais agit en premier.
Alain Ketterlin , dans le message
<87y218wton.fsf@universite-de-strasbourg.fr.invalid>, a écrit :
L'ordre est important, les redirections sont faites de gauche Í droite
Sauf |, qui s'écrit en dernier mais agit en premier.
L'ordre est important, les redirections sont faites de gauche Í droite
Sauf |, qui s'écrit en dernier mais agit en premier.
Alain Ketterlin
Nicolas George <nicolas$ writes:
Alain Ketterlin , dans le message , a écrit :
L'ordre est important, les redirections sont faites de gauche Í droite
Sauf |, qui s'écrit en dernier mais agit en premier.
Hmm, techniquement un pipe n'effectue pas une redirection (le manuel posix parle de "connexion" ou "affectation"). Mais effectivement, ce "truc" est fait avant les redirections des différentes commandes du pipeline, qui donc en annulent possiblement l'effet. Par exemple : ls | cat < whatever.txt redirige l'entrée standard de cat sur le fichier, après l'avoir initialemment connecté/affectée au pipe (et ls prend donc un SIGPIPE, puisqu'il n'y a plus rien Í l'extrémité en lecture du pipe). -- Alain.
Nicolas George <nicolas$george@salle-s.org> writes:
Alain Ketterlin , dans le message
<87y218wton.fsf@universite-de-strasbourg.fr.invalid>, a écrit :
L'ordre est important, les redirections sont faites de gauche Í droite
Sauf |, qui s'écrit en dernier mais agit en premier.
Hmm, techniquement un pipe n'effectue pas une redirection (le manuel
posix parle de "connexion" ou "affectation"). Mais effectivement, ce
"truc" est fait avant les redirections des différentes commandes du
pipeline, qui donc en annulent possiblement l'effet. Par exemple :
ls | cat < whatever.txt
redirige l'entrée standard de cat sur le fichier, après l'avoir
initialemment connecté/affectée au pipe (et ls prend donc un SIGPIPE,
puisqu'il n'y a plus rien Í l'extrémité en lecture du pipe).
L'ordre est important, les redirections sont faites de gauche Í droite
Sauf |, qui s'écrit en dernier mais agit en premier.
Hmm, techniquement un pipe n'effectue pas une redirection (le manuel posix parle de "connexion" ou "affectation"). Mais effectivement, ce "truc" est fait avant les redirections des différentes commandes du pipeline, qui donc en annulent possiblement l'effet. Par exemple : ls | cat < whatever.txt redirige l'entrée standard de cat sur le fichier, après l'avoir initialemment connecté/affectée au pipe (et ls prend donc un SIGPIPE, puisqu'il n'y a plus rien Í l'extrémité en lecture du pipe). -- Alain.
Thomas
In article , Alain Ketterlin wrote:
Thomas writes:
- on fait : ... 1> fichier.log 2>&1 ...
Je ne sais pas pourquoi j'ai écrit "1> fichier.log", le 1 n'est pas nécessaire (mais inoffensif). Donc "commande > fichier.log 2>&1"
surement parce que c'est logique et plus lisible, puisque le 1 apparait dans le terme suivant.
c'est bête qu'on doive en mettre de chaque coté du nom du fichier, y a-t-il un moyen plus compact, du genre : ... 2>&1 1> fichier.log ... ?
L'ordre est important, les redirections sont faites de gauche Í droite (Il n'y a pas "deux cotés" du nom du fichier.) Dans ton exemple, l'effet est : 1) 2>&1 : renvoie l'erreur (2) sur la même chose que la sortie (1, le terminal, Í ce stade) 2) 1> fichier.log (ou simplement "> fichier.log") : renvoie la sortie sur le fichier Donc l'erreur standard reste affectée au terminal (ou Í ce Í quoi était affectée la sortie standard au moment o͹ elle a été dupliquée).
ce que je comprend, c'est que ça n'est pas parfaitement intuitif, parce que : le 1er chiffre désigne le descripteur de fichier lui-même, tandis que le 2eme désigne sa destination. cad que placé en 1ere ou en 2eme position, ils n'ont pas le même sens. -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
In article <87y218wton.fsf@universite-de-strasbourg.fr.invalid>,
Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> wrote:
Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:
>> - on fait : ... 1> fichier.log 2>&1 ...
Je ne sais pas pourquoi j'ai écrit "1> fichier.log", le 1 n'est pas
nécessaire (mais inoffensif). Donc "commande > fichier.log 2>&1"
surement parce que c'est logique et plus lisible, puisque le 1 apparait
dans le terme suivant.
> c'est bête qu'on doive en mettre de chaque coté du nom du fichier,
> y a-t-il un moyen plus compact, du genre : ... 2>&1 1> fichier.log ... ?
L'ordre est important, les redirections sont faites de gauche Í droite
(Il n'y a pas "deux cotés" du nom du fichier.) Dans ton exemple, l'effet
est :
1) 2>&1 : renvoie l'erreur (2) sur la même chose que la sortie (1, le
terminal, Í ce stade)
2) 1> fichier.log (ou simplement "> fichier.log") : renvoie la sortie
sur le fichier
Donc l'erreur standard reste affectée au terminal (ou Í ce Í quoi était
affectée la sortie standard au moment o͹ elle a été dupliquée).
ce que je comprend, c'est que ça n'est pas parfaitement intuitif, parce
que :
le 1er chiffre désigne le descripteur de fichier lui-même, tandis que le
2eme désigne sa destination.
cad que placé en 1ere ou en 2eme position, ils n'ont pas le même sens.
Je ne sais pas pourquoi j'ai écrit "1> fichier.log", le 1 n'est pas nécessaire (mais inoffensif). Donc "commande > fichier.log 2>&1"
surement parce que c'est logique et plus lisible, puisque le 1 apparait dans le terme suivant.
c'est bête qu'on doive en mettre de chaque coté du nom du fichier, y a-t-il un moyen plus compact, du genre : ... 2>&1 1> fichier.log ... ?
L'ordre est important, les redirections sont faites de gauche Í droite (Il n'y a pas "deux cotés" du nom du fichier.) Dans ton exemple, l'effet est : 1) 2>&1 : renvoie l'erreur (2) sur la même chose que la sortie (1, le terminal, Í ce stade) 2) 1> fichier.log (ou simplement "> fichier.log") : renvoie la sortie sur le fichier Donc l'erreur standard reste affectée au terminal (ou Í ce Í quoi était affectée la sortie standard au moment o͹ elle a été dupliquée).
ce que je comprend, c'est que ça n'est pas parfaitement intuitif, parce que : le 1er chiffre désigne le descripteur de fichier lui-même, tandis que le 2eme désigne sa destination. cad que placé en 1ere ou en 2eme position, ils n'ont pas le même sens. -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
Alain Ketterlin
Thomas writes:
c'est bête qu'on doive en mettre de chaque coté du nom du fichier, y a-t-il un moyen plus compact, du genre : ... 2>&1 1> fichier.log ... ?
1) 2>&1 : renvoie l'erreur (2) sur la même chose que la sortie (1, le terminal, Í ce stade) 2) 1> fichier.log (ou simplement "> fichier.log") : renvoie la sortie sur le fichier Donc l'erreur standard reste affectée au terminal (ou Í ce Í quoi était affectée la sortie standard au moment o͹ elle a été dupliquée).
ce que je comprend, c'est que ça n'est pas parfaitement intuitif, parce que : le 1er chiffre désigne le descripteur de fichier lui-même, tandis que le 2eme désigne sa destination. cad que placé en 1ere ou en 2eme position, ils n'ont pas le même sens.
Il y a quand même quelque chose entre les deux : > pour écriture, < pour lecture, et & pour indiquer qu'on fait référence Í un descripteur ("... 1>2" redirige la sortie standard sur un fichier nommé 2). En fait ce sont des notations pour les appels système de gestion des descripteurs (dans la suite [n] représente un entier optionnel, {n} un entier obligatoire) : [n]> nom : f=open(mot)+dup2(f,n)+close(f) [n]>&{m} : dup2(m,n) [n]>&- : close(n) (etc. pour les variantes >> et aussi < et d'autres encore). Unix pur jus. Quant Í parler d'intuition Í propos des descripteurs de fichiers, même un dinosaure comme moi ne s'y risquerait pas. -- Alain.
Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:
> c'est bête qu'on doive en mettre de chaque coté du nom du fichier,
> y a-t-il un moyen plus compact, du genre : ... 2>&1 1> fichier.log ... ?
1) 2>&1 : renvoie l'erreur (2) sur la même chose que la sortie (1, le
terminal, Í ce stade)
2) 1> fichier.log (ou simplement "> fichier.log") : renvoie la sortie
sur le fichier
Donc l'erreur standard reste affectée au terminal (ou Í ce Í quoi était
affectée la sortie standard au moment o͹ elle a été dupliquée).
ce que je comprend, c'est que ça n'est pas parfaitement intuitif, parce
que :
le 1er chiffre désigne le descripteur de fichier lui-même, tandis que le
2eme désigne sa destination.
cad que placé en 1ere ou en 2eme position, ils n'ont pas le même sens.
Il y a quand même quelque chose entre les deux : > pour écriture, < pour
lecture, et & pour indiquer qu'on fait référence Í un descripteur ("...
1>2" redirige la sortie standard sur un fichier nommé 2).
En fait ce sont des notations pour les appels système de gestion des
descripteurs (dans la suite [n] représente un entier optionnel, {n} un
entier obligatoire) :
[n]> nom : f=open(mot)+dup2(f,n)+close(f)
[n]>&{m} : dup2(m,n)
[n]>&- : close(n)
(etc. pour les variantes >> et aussi < et d'autres encore). Unix pur jus.
Quant Í parler d'intuition Í propos des descripteurs de fichiers, même
un dinosaure comme moi ne s'y risquerait pas.
c'est bête qu'on doive en mettre de chaque coté du nom du fichier, y a-t-il un moyen plus compact, du genre : ... 2>&1 1> fichier.log ... ?
1) 2>&1 : renvoie l'erreur (2) sur la même chose que la sortie (1, le terminal, Í ce stade) 2) 1> fichier.log (ou simplement "> fichier.log") : renvoie la sortie sur le fichier Donc l'erreur standard reste affectée au terminal (ou Í ce Í quoi était affectée la sortie standard au moment o͹ elle a été dupliquée).
ce que je comprend, c'est que ça n'est pas parfaitement intuitif, parce que : le 1er chiffre désigne le descripteur de fichier lui-même, tandis que le 2eme désigne sa destination. cad que placé en 1ere ou en 2eme position, ils n'ont pas le même sens.
Il y a quand même quelque chose entre les deux : > pour écriture, < pour lecture, et & pour indiquer qu'on fait référence Í un descripteur ("... 1>2" redirige la sortie standard sur un fichier nommé 2). En fait ce sont des notations pour les appels système de gestion des descripteurs (dans la suite [n] représente un entier optionnel, {n} un entier obligatoire) : [n]> nom : f=open(mot)+dup2(f,n)+close(f) [n]>&{m} : dup2(m,n) [n]>&- : close(n) (etc. pour les variantes >> et aussi < et d'autres encore). Unix pur jus. Quant Í parler d'intuition Í propos des descripteurs de fichiers, même un dinosaure comme moi ne s'y risquerait pas. -- Alain.