Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Matériel Ordinateur Mac Programmation longueur max d'une ligne en cli ???

longueur max d'une ligne en cli ???

20 réponses
Avatar
pere.noel
si je fais un ps -wax je remarque que certaines lignes sont trouquées
(d'après moi), expérimentalement la longueur max d'une ligne semble être
131 chars, ce qui me paraît peu.

y a t'il un moyen de changer ça, une var d'environnement ?
--
une bévue
Signaler un problème avec ce contenu

10 réponses

Supprimer
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
1 2
Avatar
Eric Levenez
Le 18/10/06 17:11, dans <20061018150432$, « Vincent
Lefevre » <vincent+ a écrit :

Dans l'article <C151A960.871AA%,
Eric Levenez écrit:

Les variables COLUMNS et LINES sont là, pour une compatibilité avec
de très vieux programmes. C'était un moyen de forcer une taille
quand la base termcap ou terminfo n'avait pas l'info ou pas la bonne
(c'était avant X10 et X11).


C'est aussi utile quand le programme n'est pas directement connecté
à un terminal, par exemple quand la sortie est envoyée dans un pipe,
même si le bout du pipe est connecté à un terminal (e.g., grep ou
filtre de colorisation).


Ce mode de fonctionnement est une source inépuisable de problèmes. Le mieux
est encore de ne jamais utiliser LINES et COLUMNS et d'utiliser les ioctl
prévus pour. Ceci permet de ne pas tronquer les commandes redirigées.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.


Avatar
Eric Levenez
Le 19/10/06 0:04, dans , « Erwan
David » a écrit :

Eric Levenez écrivait :


Ce mode de fonctionnement est une source inépuisable de problèmes. Le mieux
est encore de ne jamais utiliser LINES et COLUMNS et d'utiliser les ioctl
prévus pour. Ceci permet de ne pas tronquer les commandes redirigées.


Et si stdourt n'est pas un tty ? Pas d'IOCTL de taille sur un pipe ou
un fichier.


Justement, c'est cela qui est bien : pas de troncature lors d'un traitement
informatique de stdout.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.


Avatar
Vincent Lefevre
Dans l'article <C15CD75D.896A4%,
Eric Levenez écrit:

Le 19/10/06 0:04, dans , « Erwan
David » a écrit :

Et si stdourt n'est pas un tty ? Pas d'IOCTL de taille sur un pipe ou
un fichier.


Justement, c'est cela qui est bien : pas de troncature lors d'un traitement
informatique de stdout.


Mais on peut vouloir tronquer les lignes (ou tout simplement "mettre en
page") pour que la sortie soit bien lisible dans la fenêtre du terminal.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


Avatar
Eric Levenez
Le 19/10/06 18:32, dans <20061019162744$, « Vincent
Lefevre » <vincent+ a écrit :

Dans l'article <C15CD75D.896A4%,
Eric Levenez écrit:

Le 19/10/06 0:04, dans , « Erwan
David » a écrit :

Et si stdourt n'est pas un tty ? Pas d'IOCTL de taille sur un pipe ou
un fichier.


Justement, c'est cela qui est bien : pas de troncature lors d'un traitement
informatique de stdout.


Mais on peut vouloir tronquer les lignes (ou tout simplement "mettre en
page") pour que la sortie soit bien lisible dans la fenêtre du terminal.


Et bien dans ce cas on ne fait pas de redirection ou pipe et on laisse
l'ioctl faire son boulot.

Si on redirige une sortie dans un fichier c'est pour la traiter plus tard,
et plus tard on aimera sûrement avoir une ligne complète et non tronquée. Si
on utilise un pipe c'est parce que l'on veut appliqué un traitement figé sur
un format de sortie connu et que l'on ne veut pas que le traitement change
en fonction de la longueur de la ligne à traiter.

Remarque on a le même problème avec LANG qui entraîne une modification de la
sortie des programmes et entraîne là aussi beaucoup de bugs dans les
traitements automatisés.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.



Avatar
Vincent Lefevre
Dans l'article <C15D8DC0.899FD%,
Eric Levenez écrit:

Le 19/10/06 18:32, dans <20061019162744$, « Vincent
Lefevre » <vincent+ a écrit :

Dans l'article <C15CD75D.896A4%,
Eric Levenez écrit:

Le 19/10/06 0:04, dans , « Erwan
David » a écrit :

Et si stdourt n'est pas un tty ? Pas d'IOCTL de taille sur un pipe ou
un fichier.


Justement, c'est cela qui est bien : pas de troncature lors d'un traitement
informatique de stdout.


Mais on peut vouloir tronquer les lignes (ou tout simplement "mettre en
page") pour que la sortie soit bien lisible dans la fenêtre du terminal.


Et bien dans ce cas on ne fait pas de redirection ou pipe et on laisse
l'ioctl faire son boulot.


On peut vouloir *à la fois* tronquer les lignes et filtrer la sortie
(e.g. pipe dans un grep ou dans une commande de colorisation).

Si on redirige une sortie dans un fichier c'est pour la traiter plus tard,
et plus tard on aimera sûrement avoir une ligne complète et non tronquée. Si
on utilise un pipe c'est parce que l'on veut appliqué un traitement figé sur
un format de sortie connu et que l'on ne veut pas que le traitement change
en fonction de la longueur de la ligne à traiter.


Non, pas toujours. Pour des questions pratiques évidentes, on peut
très bien vouloir piper un résultat déjà mis en forme. Parfois c'est
même obligatoire: par exemple, la sortie d'une commande peut être un
format du style tableau et le nombre de caractères par ligne permet
de dire quelle largeur on veut avoir. Maintenant, si tu acceptes de
réécrire un parseur d'un format de sortie fixé à chaque fois que tu
veux faire un grep, les options sont faites pour ça.

Note: tronquer une sortie colorisée n'est pas simple, car il faut
savoir interpréter les séquences d'échappement. Si on a besoin de
tronquer, mieux vaut donc le faire avant, si cela ne perturbe pas
la colorisation.

Remarque on a le même problème avec LANG qui entraîne une
modification de la sortie des programmes et entraîne là aussi
beaucoup de bugs dans les traitements automatisés.


Il suffit juste de penser à faire un LANG=C LC_ALL=C en shell, ou
l'équivalent avec d'autres langages (et en langage C, la locale par
défaut est "C", donc pas de problème, sauf si on appelle system(),
dont le comportement peut dépendre des variables d'environnement,
ou si on est dans une bibliothèque). C'est le (faible) prix à payer
pour avoir une localisation.

D'ailleurs, il n'y a pas que les locales qui influent sur la sortie.
Il y a potentiellement toutes les variables d'environnement, en
particulier PATH, LD_LIBRARY_PATH, etc. C'est bien connu...

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)




Avatar
Eric Levenez
Le 19/10/06 22:53, dans <20061019203207$, « Vincent
Lefevre » <vincent+ a écrit :

On peut vouloir *à la fois* tronquer les lignes et filtrer la sortie
(e.g. pipe dans un grep ou dans une commande de colorisation).


Il y a les commandes cut, sed, awk... Pour faire ce traitement.

Non, pas toujours. Pour des questions pratiques évidentes, on peut
très bien vouloir piper un résultat déjà mis en forme. Parfois c'est
même obligatoire: par exemple, la sortie d'une commande peut être un
format du style tableau et le nombre de caractères par ligne permet
de dire quelle largeur on veut avoir.


Tu peux toujours trouver des cas où le comportement imposé par l'utilisation
de COLUMNS t'arrangera, mais ce n'est pas le cas dans la majorité des cas.

Maintenant, si tu acceptes de
réécrire un parseur d'un format de sortie fixé à chaque fois que tu
veux faire un grep, les options sont faites pour ça.


C'est l'inverse justement, je ne veux pas changer le post-traitement juste
parce qu'une commande se comporte différemment en fonction d'une variable
shell.

Note: tronquer une sortie colorisée n'est pas simple, car il faut
savoir interpréter les séquences d'échappement. Si on a besoin de
tronquer, mieux vaut donc le faire avant, si cela ne perturbe pas
la colorisation.


Je ne vois pas l'intérêt de tronquer une version colorisée d'une commande
unix car cela veut dire que le traitement est spécifique à un TERM et donc
non utilisable sur un autre TERM.

Il suffit juste de penser à faire un LANG=C LC_ALL=C en shell, ou
l'équivalent avec d'autres langages (et en langage C, la locale par
défaut est "C", donc pas de problème, sauf si on appelle system(),
dont le comportement peut dépendre des variables d'environnement,
ou si on est dans une bibliothèque). C'est le (faible) prix à payer
pour avoir une localisation.


C'est ce qu'oublient beaucoup de shell scripts.

D'ailleurs, il n'y a pas que les locales qui influent sur la sortie.
Il y a potentiellement toutes les variables d'environnement, en
particulier PATH, LD_LIBRARY_PATH, etc. C'est bien connu...


C'est bien connu et c'est souvent ignoré des programmeurs.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Avatar
Vincent Lefevre
Dans l'article <C15E2C0F.89BA5%,
Eric Levenez écrit:

Le 19/10/06 22:53, dans <20061019203207$, « Vincent
Lefevre » <vincent+ a écrit :

On peut vouloir *à la fois* tronquer les lignes et filtrer la sortie
(e.g. pipe dans un grep ou dans une commande de colorisation).


Il y a les commandes cut, sed, awk... Pour faire ce traitement.


C'est beaucoup plus long à taper qu'un "| grep blah", sans compter les
risques de bugs. Donc en pratique, un tel traitement avec cut, sed, awk
est impensable. Et tu peux utiliser les ioctl avec cut, sed, awk?

Tu peux toujours trouver des cas où le comportement imposé par
l'utilisation de COLUMNS t'arrangera, mais ce n'est pas le cas dans
la majorité des cas.


L'existence de tels cas justifie la présence de COLUMNS encore
aujourd'hui.

Maintenant, si tu acceptes de réécrire un parseur d'un format de
sortie fixé à chaque fois que tu veux faire un grep, les options
sont faites pour ça.


C'est l'inverse justement, je ne veux pas changer le post-traitement
juste parce qu'une commande se comporte différemment en fonction
d'une variable shell.


Tu n'as qu'à fixer toi-même les locales à POSIX.

Note: tronquer une sortie colorisée n'est pas simple, car il faut
savoir interpréter les séquences d'échappement. Si on a besoin de
tronquer, mieux vaut donc le faire avant, si cela ne perturbe pas
la colorisation.


Je ne vois pas l'intérêt de tronquer une version colorisée d'une
commande unix car cela veut dire que le traitement est spécifique à
un TERM et donc non utilisable sur un autre TERM.


Justement. C'est pour ça que la sortie doit être tronquée *avant* la
colorisation. Par conséquent, les ioctl ne sont pas utilisables, et
la variable d'environnement COLUMNS doit être utilisée.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


Avatar
Eric Levenez
Le 21/10/06 23:57, dans <20061021214534$, « Vincent
Lefevre » <vincent+ a écrit :

Dans l'article <C15E2C0F.89BA5%,
Eric Levenez écrit:

Le 19/10/06 22:53, dans <20061019203207$, « Vincent
Lefevre » <vincent+ a écrit :

On peut vouloir *à la fois* tronquer les lignes et filtrer la sortie
(e.g. pipe dans un grep ou dans une commande de colorisation).


Il y a les commandes cut, sed, awk... Pour faire ce traitement.


C'est beaucoup plus long à taper qu'un "| grep blah", sans compter les
risques de bugs.


Les bugs, c'est quand on présuppose une valeur de COLUMNS pour le
traitement. Sans cette limite la sortie de la première commande est
constante et le traitement n'a pas à être adapté selon la longueur.

Donc en pratique, un tel traitement avec cut, sed, awk
est impensable.


Non, c'est ce qu'il se fait tous les jours

Et tu peux utiliser les ioctl avec cut, sed, awk?


Non. Je n'ai jamais dit cela. Relis un peu mes explications.

Tu peux toujours trouver des cas où le comportement imposé par
l'utilisation de COLUMNS t'arrangera, mais ce n'est pas le cas dans
la majorité des cas.


L'existence de tels cas justifie la présence de COLUMNS encore
aujourd'hui.


C'est un méthode qui date d'un autre age, et certains ne sont pas prêt à
changer :-/


Maintenant, si tu acceptes de réécrire un parseur d'un format de
sortie fixé à chaque fois que tu veux faire un grep, les options
sont faites pour ça.


C'est l'inverse justement, je ne veux pas changer le post-traitement
juste parce qu'une commande se comporte différemment en fonction
d'une variable shell.


Tu n'as qu'à fixer toi-même les locales à POSIX.


C'est ce que je fais, mais ce n'est pas ce que font 99 % des programmeurs
shell.

Note: tronquer une sortie colorisée n'est pas simple, car il faut
savoir interpréter les séquences d'échappement. Si on a besoin de
tronquer, mieux vaut donc le faire avant, si cela ne perturbe pas
la colorisation.


Je ne vois pas l'intérêt de tronquer une version colorisée d'une
commande unix car cela veut dire que le traitement est spécifique à
un TERM et donc non utilisable sur un autre TERM.


Justement. C'est pour ça que la sortie doit être tronquée *avant* la
colorisation.


La colorisation n'a d'importance que pour 2 ou 3 commandes et cela n'a pas
d'utilité en redirection car c'est non portable par définition.

Par conséquent, les ioctl ne sont pas utilisables, et
la variable d'environnement COLUMNS doit être utilisée.


Bon, je te laisse à tes rêves :-)

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.



Avatar
Vincent Lefevre
Dans l'article <C1610075.8A383%,
Eric Levenez écrit:

Le 21/10/06 23:57, dans <20061021214534$, « Vincent
Lefevre » <vincent+ a écrit :

Dans l'article <C15E2C0F.89BA5%,
Eric Levenez écrit:

Le 19/10/06 22:53, dans <20061019203207$, « Vincent
Lefevre » <vincent+ a écrit :

On peut vouloir *à la fois* tronquer les lignes et filtrer la sortie
(e.g. pipe dans un grep ou dans une commande de colorisation).


Il y a les commandes cut, sed, awk... Pour faire ce traitement.


C'est beaucoup plus long à taper qu'un "| grep blah", sans compter les
risques de bugs.


Les bugs, c'est quand on présuppose une valeur de COLUMNS pour le
traitement. Sans cette limite la sortie de la première commande est
constante et le traitement n'a pas à être adapté selon la longueur.


Je rappelle que le but est d'avoir au final une sortie adaptée à la
largeur du terminal. Tu ne réponds pas du tout au problème.

Donc en pratique, un tel traitement avec cut, sed, awk
est impensable.


Non, c'est ce qu'il se fait tous les jours


Si tu aimes taper ces commandes à longueur de journée, c'est ton
problème.

Et tu peux utiliser les ioctl avec cut, sed, awk?


Non. Je n'ai jamais dit cela. Relis un peu mes explications.


Ceci dit, il n'y en a pas besoin, ni de COLUMNS. En ce qui me concerne,
j'utilise `tput cols` (que tu n'as pas mentionné, au passage), mais il
faut qu'il soit installé, ce qui n'est pas toujours le cas.

Tu n'as qu'à fixer toi-même les locales à POSIX.


C'est ce que je fais, mais ce n'est pas ce que font 99 % des
programmeurs shell.


Cet oubli était souvent/toujours le cas dans le passé, car les
machines étaient peu localisées sous Unix (notamment au moment
du boot), mais plus maintenant. Ceci dit, on voit les limites
du système shell, si on veut à la fois la localisation et
récupérer la sortie de commandes pour les besoins du script.

La colorisation n'a d'importance que pour 2 ou 3 commandes


Peut-être chez toi, mais je m'en sers en permanence.

et cela n'a pas d'utilité en redirection car c'est non portable par
définition.


C'est bien pour ça que je colorise juste avant la sortie sur le
terminal, et que s'il doit y avoir une mise en forme (e.g. tronquer
les lignes), celle-ci se fait *avant*.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)




Avatar
bertrand.NOSPAM.lupart
Eric Levenez wrote:

En pratique, les programmes n'utilisent pas ces variables
d'environnement. L'émulateur de terminal (Terminal.app sous Mac OS X)
indique au noyau un changement de taille de fenêtre par un ioctl du
type TIOCSWINSZ. Le noyau va alors envoyer le signal SIGWINCH au groupe
de processus dépendant du pseudo tty, et ces programmes liront la
nouvelle taille en utilisant l'ioctl TIOCGWINSZ. Le shell lancé par
Terminal.app positionnera alors COLUMNS et LINES en conséquence.


Intéressant. On peut faire quelque chose d'équivalent avec DISPLAY?


DISPLAY est juste une variable shell utilisée pour trouver le serveur X
par défaut pour une application à son lancement.


Comme COLUMNS et LINES à l'origine.

Lorsque X11 est lancé, toutes les instances de Terminal.app seraient
averties de la valeur du nouveaux display.


Je ne vois pas le rapport entre une application X11 et Terminal.app qui
est un programme Mac OS X natif.


C'était un exemple d'application. Si le lancement d'un serveur X11
pouvait informer le noyau de son adresse, qui lui même pouvait en
informer les applications suceptibles d'en avoir besoin (c'est bien le
principe que tu décrits avec TIOCSWINSZ et SIGWINCH?), ce serait
intérressant.

Dans le cas de X11 sur Mac, seules les applis X11 connaissent le
display. Si Terminal.app pouvait être mis au courant qu'un serveur X a
été lancé, on pourrait lancer des applis X sans avoir à bidouiller les
variables d'environnement.

"netstat" quant à lui semble afficher sur 80 colonnes, quoi qu'il
arrive.


"netstat" n'a pas besoin de tronquer l'affichage alors il n'a pas besoin
d'utiliser COLUMNS ou SIGWINCH.


Il suffit d'avoir des noms de host avec un reverse DNS un peu long, et
leur affichage est tronqué. On s'en sort généralement avec "-n", mais
c'est vachement moins sympa.

--
Bertrand



1 2