Salut,

Avec sed, ceci a l'air de marcher :

cat fichier | sed "s/\t\|$/<br>/g"

Poste le Friday 28 September 2007 12:46:16

Oui, ça marche, merci. &

--
On ne prête qu’aux riches, et on a bien raison, parce que les autres remboursent difficilement.
-+- Tristan Bernard (1866-1947) -+-

Poste le Friday 28 September 2007 18:08:14

Citation
Mochi
Salut,

Avec sed, ceci a l'air de marcher :

cat fichier | sed "s/\t\|$/<br>/g"

sed "s/\t\|$/<br>/g" fichier et on évite un process inutile....

L'homme qui murmurait à l'oreille des pingouins
[fr.lang.free.fr]

Poste le Friday 28 September 2007 20:51:20

Mais s'il demande "après un tube" c'est qu'il ne doit pas travailler sur un fichier...

[catwell.info]

Poste le Friday 28 September 2007 23:01:46

Si c'est dans un script, rien n'empeche d'utiliser une variable pour reprendre le chemin et le nom du fichier.

Donc oui, autant éviter le pipe si c'est possible



--
Brugmans Frédéric

[www.brugmans.net]
[triathlon.sport-challenge.be]

Poste le Friday 28 September 2007 23:27:12

Citation

Si c'est dans un script, rien n'empeche d'utiliser une variable pour reprendre le chemin et le nom du fichier

Sauf que là l'argument ne sera visiblement pas un fichier mais l'entrée standard. Et comme on ne sait pas ce qu'il y a dans le script, le mieux est àmha de donner une pièce à nicola puis de le laisser la monter comme il veut (avec une demande aussi précise, il doit savoir où ça va -- y a pas que les grands débutants qui postent). KISS!

Poste le Saturday 29 September 2007 10:49:11

L'entrée standard, c'est le clavier
Le flux, c'est ce qui sort d'un tube

--
Brugmans Frédéric

[www.brugmans.net]
[triathlon.sport-challenge.be]

Poste le Saturday 29 September 2007 10:58:50

Tsss... c'est quoi le soucis ?

L'entrée standard, c'est le descripteur stdin (&0). Si on est dans un mode interactif c'est le clavier. Essaie :

cat <&0

Puis tape ce que tu veux, à chaque fois que tu tapes [Entrée], cat lit ta ligne et la renvoie sur stdout.

Dans le mode non-interactif qu'est le tube, c'est la sortie de l'autre commande qui arrive sur stdin.

Citation
man bash, section Pipelines
The standard output of command is connected via a pipe to the standard input of command2. This connection is performed before any redirections specified by the command (see REDIRECTION below).

Mets maintenant le cat ci-dessus dans un script, puis fais comme nicola un truc genre lsmod | script, tu verras que ce qui arrive sur le descripteur 0 c'est maintenant la sortie de lsmod. Flux ou pas, c'est stdin.

Poste le Saturday 29 September 2007 12:41:49

Citation
Mochi
Tsss... c'est quoi le soucis ?

L'entrée standard, c'est le descripteur stdin
(&0). Si on est dans un mode interactif c'est
le clavier. Essaie :

cat <&0
Puis tape ce que tu veux, à chaque fois que tu
tapes , cat lit ta ligne et la renvoie sur stdout.


Dans le mode non-interactif qu'est le tube, c'est
la sortie de l'autre commande qui arrive sur
stdin.

man bash, section Pipelines a écrit :The standard
output of command is connected via a pipe to the
standard input of command2. This connection is
performed before any redirections specified by the
command (see REDIRECTION below).
Mets maintenant le cat ci-dessus dans un script,
puis fais comme nicola un truc genre lsmod |
script, tu verras que ce qui arrive sur le
descripteur 0 c'est maintenant la sortie de lsmod.
Flux ou pas, c'est stdin.

Vas-y, traite Brugmans comme un noob et tu vas rapidement comprendre ta douleur...

Citation
Mochi
Sauf que là l'argument ne sera visiblement pas un fichier mais l'entrée standard. Et comme on ne sait pas ce qu'il y a dans le script, le mieux est àmha de donner une pièce à nicola puis de le laisser la monter comme il veut

Là t'as pas tord. Vaut mieux être universel. Moi c'est pareil. J'avais fait un script et dans ce script diverses fonctions. Puis, pour faire passer une variable via ces fonctions je faisais
var=`fct1 info`
var=`fct2 $var`
var=`fct3 $var`
etc

Puis un jour je me suis dit que j'avais qu'à créer mes fonctions de façon à ce qu'elles travaillent sur stdin et stdout puis j'ai réduit mon code à
var=`fct1 info |fct2 |fct3` :chef:

L'homme qui murmurait à l'oreille des pingouins
[fr.lang.free.fr]

Poste le Wednesday 3 October 2007 22:29:54

Citation

tu vas rapidement comprendre ta douleur...

(!)(?)

Citation

Là t'as pas tord. Vaut mieux être universel. Moi c'est pareil.

Non, je ne veux pas être universel mais simple. Peu importe que nicola fasse de la dentelle ou du bricolage à l'arrache, je réponds simplement au problème posé. Donc, j'ai un peu de mal à saisir l'intérêt véritable des commentaires annexes qui spéculent sur un script que personne ne connaît au lieu de proposer des solutions alternatives au problème tel qu'il est posé.

Citation

Puis un jour je me suis dit que j'avais qu'à créer mes fonctions de façon à ce qu'elles travaillent sur stdin et stdout puis j'ai réduit mon code à [...]

D'un autre côté, en shell les fonctions travaillent par défaut dans l'espace de nommage principal. Donc, si tu es soucieux du nombre de processus, t'as même pas besoin de sous-shells : il suffit de terminer tes fonctions par var=<résultat>.

Mais il est vrai qu'après ça dépend de la taille du script, de son objet, de sa durée de vie, ... bref après c'est la cuisine de chacun.

Poste le Thursday 4 October 2007 20:29:15

Ce que Sve@r veut simplement dire c'est que si tu vas voir mes différentes réponses sur le forum, tu verras que mon point fort, c'est surtout le shell et tous les outils standards.

Et pour revenir à la pertinence des réponses :

Citation
Nicola
Par exemple grep machin truc | le script.

Ce que je peux dire pour avoir participé à de nombreux forums techniques linux, qu'il est régulièrement nécessaire de recadrer ou de repréciser une demande voir même de proposer des solutions qui ne vont pas le sens des tentatives originales.
Tu te braques sur le fait que tu vas utiliser le stdin alors qu'il n'y a rien de moins sur d'autant plus que nicola a selectionné une réponse qui utilise ce pipe et ce fichier. Nicola précise d'ailleurs Par exemple ...etc et.


Les différentes interventions ne font que souligner l'utilité de se passer d'un sous-shell lorsque c'est possible car la solution proposée et fonctionnelle, je le répète utilise un sous-shell inutile.



--
Brugmans Frédéric

[www.brugmans.net]
[triathlon.sport-challenge.be]

Poste le Friday 5 October 2007 12:28:54

Citation

Ce que Sve@r veut simplement dire c'est que si tu vas voir mes différentes réponses sur le forum, tu verras que mon point fort, c'est surtout le shell et tous les outils standards.

Bin ça c'est plutôt bien pour toi, mais je te jure que ça ne me fait pas particulièrement mal.

Citation

Tu te braques sur le fait que tu vas utiliser le stdin alors qu'il n'y a rien de moins sur d'autant plus que nicola a selectionné une réponse qui utilise ce pipe et ce fichier.

Je ne me braque sur rien du tout, c'est juste que l'énoncé précise à partir d'un flux, ce qui implique un travail sur stdin. Le cat fichier de ma réponse, c'est l'exact équivalent du grep machin de nicola... pour tester ma solution, il a bien fallu que je crée un flux avec fins de lignes et tabulations. La pièce à monter dont je parle c'est l'expression régulière de sed. Ce que je vous reproche, c'est de vous focaliser sur un composant arbitraire -- donc non-significatif -- de ma solution.

Citation

Les différentes interventions ne font que souligner l'utilité de se passer d'un sous-shell lorsque c'est possible car la solution proposée et fonctionnelle, je le répète utilise un sous-shell inutile.

Et je répète qu'on n'en sait rien du tout... par exemple si je fais comme vous et que je prends grep machin au pied de la lettre (soit un truc qui doit forcément être fait avec grep), tu seras obligé d'écrire grep machin | sed ... dans ton script (en supposant que machin soit un fichier) et tu l'auras quand même ton sous-shell.

Poste le Friday 5 October 2007 18:27:34