Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

script sh / redirection de sorties

7 réponses
Avatar
Thomas
bonjour :-)



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 ?



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 ?

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

7 réponses

Avatar
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.
Avatar
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/
Avatar
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.
Avatar
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.
Avatar
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.
Avatar
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/
Avatar
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.