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
y a t'il un moyen de changer ça, une var d'environnement ?
RTFM man ps, c'est l'argument -w qu'il faut suppromer... -- une bévue
Eric Levenez
Le 7/10/06 8:02, dans <1hmtvl1.3flwlq9qayx3N%, « Une bévue » a écrit :
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.
Bien sûr tu as fais "man ps" avant de poster ici ta question et bien sûr tu as vu la limite que -w donne, et bien sûr tu as vu que tu pouvais faire -ww pour avoir une taille illimitée, et bien sûr tu comprends que la commande ps n'a rien à voir avec le titre de ton message qui parle d'une taille max de ligne sous shell. Hein, n'est-ce pas ? :-)
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 7/10/06 8:02, dans <1hmtvl1.3flwlq9qayx3N%pere.noel@laponie.com.invalid>,
« Une bévue » <pere.noel@laponie.com.invalid> a écrit :
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.
Bien sûr tu as fais "man ps" avant de poster ici ta question et bien sûr tu
as vu la limite que -w donne, et bien sûr tu as vu que tu pouvais faire -ww
pour avoir une taille illimitée, et bien sûr tu comprends que la commande ps
n'a rien à voir avec le titre de ton message qui parle d'une taille max de
ligne sous shell. Hein, n'est-ce pas ? :-)
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 7/10/06 8:02, dans <1hmtvl1.3flwlq9qayx3N%, « Une bévue » a écrit :
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.
Bien sûr tu as fais "man ps" avant de poster ici ta question et bien sûr tu as vu la limite que -w donne, et bien sûr tu as vu que tu pouvais faire -ww pour avoir une taille illimitée, et bien sûr tu comprends que la commande ps n'a rien à voir avec le titre de ton message qui parle d'une taille max de ligne sous shell. Hein, n'est-ce pas ? :-)
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
pere.noel
Eric Levenez wrote:
Bien sûr tu as fais "man ps" avant de poster ici ta question et bien sûr tu as vu la limite que -w donne, et bien sûr tu as vu que tu pouvais faire -ww pour avoir une taille illimitée, et bien sûr tu comprends que la commande ps n'a rien à voir avec le titre de ton message qui parle d'une taille max de ligne sous shell. Hein, n'est-ce pas ? :-)
reqarques que je me suis auto-répondu... -- une bévue
Eric Levenez <news@levenez.com> wrote:
Bien sûr tu as fais "man ps" avant de poster ici ta question et bien sûr tu
as vu la limite que -w donne, et bien sûr tu as vu que tu pouvais faire -ww
pour avoir une taille illimitée, et bien sûr tu comprends que la commande ps
n'a rien à voir avec le titre de ton message qui parle d'une taille max de
ligne sous shell. Hein, n'est-ce pas ? :-)
reqarques que je me suis auto-répondu...
--
une bévue
Bien sûr tu as fais "man ps" avant de poster ici ta question et bien sûr tu as vu la limite que -w donne, et bien sûr tu as vu que tu pouvais faire -ww pour avoir une taille illimitée, et bien sûr tu comprends que la commande ps n'a rien à voir avec le titre de ton message qui parle d'une taille max de ligne sous shell. Hein, n'est-ce pas ? :-)
reqarques que je me suis auto-répondu... -- une bévue
Eric Levenez
Le 7/10/06 10:30, dans <1hmu2i0.1yvvqoe1nifrN%, « Une bévue » a écrit :
reqarques que je me suis auto-répondu...
En disant qu'il fallait supprimer le w alors qu'il fallait le doubler...
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 7/10/06 10:30, dans
<1hmu2i0.1yvvqoe1nifrN%pere.noel@laponie.com.invalid>, « Une bévue »
<pere.noel@laponie.com.invalid> a écrit :
reqarques que je me suis auto-répondu...
En disant qu'il fallait supprimer le w alors qu'il fallait le doubler...
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 7/10/06 10:30, dans <1hmu2i0.1yvvqoe1nifrN%, « Une bévue » a écrit :
reqarques que je me suis auto-répondu...
En disant qu'il fallait supprimer le w alors qu'il fallait le doubler...
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
pere.noel
Eric Levenez wrote:
En disant qu'il fallait supprimer le w alors qu'il fallait le doubler...
ouais mais ça m'a suffit, en fait j'ai été troublé non pas par man:ps mais par la sortie sur la "console" TextMate qui donne (du point de vue de la longueur des lignes) un résultat différent de ce que donne le terminal et je me suis énervé après ça voila tout... -- une bévue
Eric Levenez <news@levenez.com> wrote:
En disant qu'il fallait supprimer le w alors qu'il fallait le doubler...
ouais mais ça m'a suffit, en fait j'ai été troublé non pas par man:ps
mais par la sortie sur la "console" TextMate qui donne (du point de vue
de la longueur des lignes) un résultat différent de ce que donne le
terminal et je me suis énervé après ça voila tout...
--
une bévue
En disant qu'il fallait supprimer le w alors qu'il fallait le doubler...
ouais mais ça m'a suffit, en fait j'ai été troublé non pas par man:ps mais par la sortie sur la "console" TextMate qui donne (du point de vue de la longueur des lignes) un résultat différent de ce que donne le terminal et je me suis énervé après ça voila tout... -- une bévue
bertrand.NOSPAM.lupart
le titre de ton message qui parle d'une taille max de ligne sous shell. Hein, n'est-ce pas ? :-)
[Rien à voir avec ps, mais en rapport avec le sujet]
Certains softs en cli utilisent la variable d'environnement COLUMNS pour connaître le nombre de colonnes et adapter l'affichage. Lynx et fink/dpkg par exemple. Je n'ai pas d'exemple en tête de softs livrés en standard qui le fassent (s'il y en a).
# dpkg -l |grep freetype219- ii freetype219-sh 2.1.9-1 TrueType font rendering library, shared libs ---->8---->8---->8---->8----
Affichage 100 colonnes: ----8<----8<----8<----8<---- # COLUMNS0 dpkg -l |grep freetype219- ii freetype219-shlibs 2.1.9-1 TrueType font rendering library, shared libs ---->8---->8---->8---->8----
Cette variable est mise à jour avec le redimensionnement des fenêtres de Terminal.app.
-- Bertrand
le titre de ton message qui parle d'une taille max de
ligne sous shell. Hein, n'est-ce pas ? :-)
[Rien à voir avec ps, mais en rapport avec le sujet]
Certains softs en cli utilisent la variable d'environnement COLUMNS pour
connaître le nombre de colonnes et adapter l'affichage.
Lynx et fink/dpkg par exemple. Je n'ai pas d'exemple en tête de softs
livrés en standard qui le fassent (s'il y en a).
le titre de ton message qui parle d'une taille max de ligne sous shell. Hein, n'est-ce pas ? :-)
[Rien à voir avec ps, mais en rapport avec le sujet]
Certains softs en cli utilisent la variable d'environnement COLUMNS pour connaître le nombre de colonnes et adapter l'affichage. Lynx et fink/dpkg par exemple. Je n'ai pas d'exemple en tête de softs livrés en standard qui le fassent (s'il y en a).
# dpkg -l |grep freetype219- ii freetype219-sh 2.1.9-1 TrueType font rendering library, shared libs ---->8---->8---->8---->8----
Affichage 100 colonnes: ----8<----8<----8<----8<---- # COLUMNS0 dpkg -l |grep freetype219- ii freetype219-shlibs 2.1.9-1 TrueType font rendering library, shared libs ---->8---->8---->8---->8----
Cette variable est mise à jour avec le redimensionnement des fenêtres de Terminal.app.
-- Bertrand
Eric Levenez
Le 10/10/06 15:05, dans <1hmyi4k.69lmbby4i2dqN%, « Bertrand LUPART » a écrit :
le titre de ton message qui parle d'une taille max de ligne sous shell. Hein, n'est-ce pas ? :-)
[Rien à voir avec ps, mais en rapport avec le sujet]
Certains softs en cli utilisent la variable d'environnement COLUMNS pour connaître le nombre de colonnes et adapter l'affichage. ... Cette variable est mise à jour avec le redimensionnement des fenêtres de Terminal.app.
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.
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).
Mais bon tout cela n'a pas beaucoup de rapport avec le sujet car celui-ci parle d'un interpréteur en ligne de commande ("cli" sic), et que "ps" n'est pas un interpréteur. Et même si "ps" cale son affichage en fonction de la largeur de fenêtre, il ne le fait pas par COLUMNS mais par un ioctl de type TIOCGWINSZ (comme tout logiciel moderne).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 10/10/06 15:05, dans
<1hmyi4k.69lmbby4i2dqN%bertrand.NOSPAM.lupart@free.fr.invalid>, « Bertrand
LUPART » <bertrand.NOSPAM.lupart@free.fr.invalid> a écrit :
le titre de ton message qui parle d'une taille max de
ligne sous shell. Hein, n'est-ce pas ? :-)
[Rien à voir avec ps, mais en rapport avec le sujet]
Certains softs en cli utilisent la variable d'environnement COLUMNS pour
connaître le nombre de colonnes et adapter l'affichage.
...
Cette variable est mise à jour avec le redimensionnement des fenêtres de
Terminal.app.
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.
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).
Mais bon tout cela n'a pas beaucoup de rapport avec le sujet car celui-ci
parle d'un interpréteur en ligne de commande ("cli" sic), et que "ps" n'est
pas un interpréteur. Et même si "ps" cale son affichage en fonction de la
largeur de fenêtre, il ne le fait pas par COLUMNS mais par un ioctl de type
TIOCGWINSZ (comme tout logiciel moderne).
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 10/10/06 15:05, dans <1hmyi4k.69lmbby4i2dqN%, « Bertrand LUPART » a écrit :
le titre de ton message qui parle d'une taille max de ligne sous shell. Hein, n'est-ce pas ? :-)
[Rien à voir avec ps, mais en rapport avec le sujet]
Certains softs en cli utilisent la variable d'environnement COLUMNS pour connaître le nombre de colonnes et adapter l'affichage. ... Cette variable est mise à jour avec le redimensionnement des fenêtres de Terminal.app.
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.
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).
Mais bon tout cela n'a pas beaucoup de rapport avec le sujet car celui-ci parle d'un interpréteur en ligne de commande ("cli" sic), et que "ps" n'est pas un interpréteur. Et même si "ps" cale son affichage en fonction de la largeur de fenêtre, il ne le fait pas par COLUMNS mais par un ioctl de type TIOCGWINSZ (comme tout logiciel moderne).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
bertrand.NOSPAM.lupart
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? Lorsque X11 est lancé, toutes les instances de Terminal.app seraient averties de la valeur du nouveaux display.
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).
Mais bon tout cela n'a pas beaucoup de rapport avec le sujet car celui-ci parle d'un interpréteur en ligne de commande ("cli" sic), et que "ps" n'est pas un interpréteur. Et même si "ps" cale son affichage en fonction de la largeur de fenêtre, il ne le fait pas par COLUMNS mais par un ioctl de type TIOCGWINSZ (comme tout logiciel moderne).
Effectivement, dans un terminal 80 colonnes "ps" et "COLUMNS%0 ps" donnent le même résultat.
Par contre, "lynx", "top", "fink" réagissent aux valeurs de COLUMNS et de LINES. J'en déduit qu'ils n'utilisent pas le mécanisme que tu décrits.
"netstat" quant à lui semble afficher sur 80 colonnes, quoi qu'il arrive.
-- Bertrand
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?
Lorsque X11 est lancé, toutes les instances de Terminal.app seraient
averties de la valeur du nouveaux display.
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).
Mais bon tout cela n'a pas beaucoup de rapport avec le sujet car celui-ci
parle d'un interpréteur en ligne de commande ("cli" sic), et que "ps" n'est
pas un interpréteur. Et même si "ps" cale son affichage en fonction de la
largeur de fenêtre, il ne le fait pas par COLUMNS mais par un ioctl de type
TIOCGWINSZ (comme tout logiciel moderne).
Effectivement, dans un terminal 80 colonnes "ps" et "COLUMNS%0 ps"
donnent le même résultat.
Par contre, "lynx", "top", "fink" réagissent aux valeurs de COLUMNS et
de LINES. J'en déduit qu'ils n'utilisent pas le mécanisme que tu
décrits.
"netstat" quant à lui semble afficher sur 80 colonnes, quoi qu'il
arrive.
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? Lorsque X11 est lancé, toutes les instances de Terminal.app seraient averties de la valeur du nouveaux display.
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).
Mais bon tout cela n'a pas beaucoup de rapport avec le sujet car celui-ci parle d'un interpréteur en ligne de commande ("cli" sic), et que "ps" n'est pas un interpréteur. Et même si "ps" cale son affichage en fonction de la largeur de fenêtre, il ne le fait pas par COLUMNS mais par un ioctl de type TIOCGWINSZ (comme tout logiciel moderne).
Effectivement, dans un terminal 80 colonnes "ps" et "COLUMNS%0 ps" donnent le même résultat.
Par contre, "lynx", "top", "fink" réagissent aux valeurs de COLUMNS et de LINES. J'en déduit qu'ils n'utilisent pas le mécanisme que tu décrits.
"netstat" quant à lui semble afficher sur 80 colonnes, quoi qu'il arrive.
-- Bertrand
Eric Levenez
Le 11/10/06 14:50, dans <1hn1rhn.1ivvxh91kmidzmN%, « Bertrand LUPART » a écrit :
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.
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.
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).
Mais bon tout cela n'a pas beaucoup de rapport avec le sujet car celui-ci parle d'un interpréteur en ligne de commande ("cli" sic), et que "ps" n'est pas un interpréteur. Et même si "ps" cale son affichage en fonction de la largeur de fenêtre, il ne le fait pas par COLUMNS mais par un ioctl de type TIOCGWINSZ (comme tout logiciel moderne).
Effectivement, dans un terminal 80 colonnes "ps" et "COLUMNS%0 ps" donnent le même résultat.
Par contre, "lynx", "top", "fink" réagissent aux valeurs de COLUMNS et de LINES. J'en déduit qu'ils n'utilisent pas le mécanisme que tu décrits.
De vieux programmes ou pas au goût du jour. "top" réagit quand même au SIGWINCH, même s'il le fait bizarrement si COLUMNS a été forcé. Pour "fink" et "lynx", je n'ai pas regardé.
"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. Et c'est une bonne chose car la troncature des affichages est très emmerdante je trouve.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 11/10/06 14:50, dans
<1hn1rhn.1ivvxh91kmidzmN%bertrand.NOSPAM.lupart@free.fr.invalid>, « Bertrand
LUPART » <bertrand.NOSPAM.lupart@free.fr.invalid> a écrit :
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.
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.
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).
Mais bon tout cela n'a pas beaucoup de rapport avec le sujet car celui-ci
parle d'un interpréteur en ligne de commande ("cli" sic), et que "ps" n'est
pas un interpréteur. Et même si "ps" cale son affichage en fonction de la
largeur de fenêtre, il ne le fait pas par COLUMNS mais par un ioctl de type
TIOCGWINSZ (comme tout logiciel moderne).
Effectivement, dans un terminal 80 colonnes "ps" et "COLUMNS%0 ps"
donnent le même résultat.
Par contre, "lynx", "top", "fink" réagissent aux valeurs de COLUMNS et
de LINES. J'en déduit qu'ils n'utilisent pas le mécanisme que tu
décrits.
De vieux programmes ou pas au goût du jour. "top" réagit quand même au
SIGWINCH, même s'il le fait bizarrement si COLUMNS a été forcé. Pour "fink"
et "lynx", je n'ai pas regardé.
"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. Et c'est une bonne chose car la troncature
des affichages est très emmerdante je trouve.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 11/10/06 14:50, dans <1hn1rhn.1ivvxh91kmidzmN%, « Bertrand LUPART » a écrit :
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.
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.
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).
Mais bon tout cela n'a pas beaucoup de rapport avec le sujet car celui-ci parle d'un interpréteur en ligne de commande ("cli" sic), et que "ps" n'est pas un interpréteur. Et même si "ps" cale son affichage en fonction de la largeur de fenêtre, il ne le fait pas par COLUMNS mais par un ioctl de type TIOCGWINSZ (comme tout logiciel moderne).
Effectivement, dans un terminal 80 colonnes "ps" et "COLUMNS%0 ps" donnent le même résultat.
Par contre, "lynx", "top", "fink" réagissent aux valeurs de COLUMNS et de LINES. J'en déduit qu'ils n'utilisent pas le mécanisme que tu décrits.
De vieux programmes ou pas au goût du jour. "top" réagit quand même au SIGWINCH, même s'il le fait bizarrement si COLUMNS a été forcé. Pour "fink" et "lynx", je n'ai pas regardé.
"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. Et c'est une bonne chose car la troncature des affichages est très emmerdante je trouve.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Vincent Lefevre
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). En tout cas, il y a une différence sous Linux (par exemple pour "ps -aef" et "ps -aef | cat"), mais pas sous Mac OS X!
Dans l'article <C151A960.871AA%news@levenez.com>,
Eric Levenez <news@levenez.com> é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). En tout cas, il y a une différence sous
Linux (par exemple pour "ps -aef" et "ps -aef | cat"), mais pas sous
Mac OS X!
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). En tout cas, il y a une différence sous Linux (par exemple pour "ps -aef" et "ps -aef | cat"), mais pas sous Mac OS X!
