Bonjour,

Le couple zsh et rxvt a un comportement bizarre à mon sens :
Soit le fichier toto.txt dont la dernière ligne ne comporte pas de CR.
On tape "cat toto.txt" dans une rxvt.

Lorsque le shell est bash (par ex.), sa ligne dernière s'affiche,
immédiatement suivie du prompt. S'agissant d'afficher verbatim des
caractères (aux possibilités de la console près), on s'y attendrait.

Mais si c'est zsh, cat toto.txt n'affiche pas la dernière ligne.

Et si le terminal est xterm, bash et zsh affichent la dernire ligne de
toto.txt sans problème ...

Quelqu'un aurait-il une idée du pourquoi de la chose (je sais, c'est
bateau comme expression, mais j'ai rien trouvé d'autre) ?
--
Hervé

Hervé Autret wrote in message
<pan.2006.10.26.22.13.56.415869@alussinan.org>:
> Soit le fichier toto.txt dont la dernière ligne ne comporte pas de CR.

LF, pas CR.

> Mais si c'est zsh, cat toto.txt n'affiche pas la dernière ligne.
>
> Et si le terminal est xterm, bash et zsh affichent la dernire ligne de
> toto.txt sans problème ...
>
> Quelqu'un aurait-il une idée du pourquoi de la chose (je sais, c'est
> bateau comme expression, mais j'ai rien trouvé d'autre) ?

zsh a plusieurs comportements possibles pour réagir à ce genre de
situations, dont un assez hackesque, crade, et peu robuste, mais qui
correspond à ce qui est probablement le plus pratique du point de vue de
l'utilisateur. Cf la doc des options PROMPT_CR et PROMPT_SP dans
zshoptions(1).

Nicolas George posta :

> LF, pas CR.

Ôtant pour moi (i.e je retire).

> le plus pratique du point de vue de

.... de celui qui a fait ce truc, non ?

> PROMPT_CR
Ok, merci. D'un autre côté, l'option n'a pas d'effet visible dans xterm...
Serait-ce que xterm ignore les CR quand il "voit" qu'ils auront pour effet
d'effacer des caractères déjà affichés ? Je dis ça, je ne vois rien
dans le man xterm qui se réfère à ce comportement (ou j'ai lu trop
vite)

> PROMPT_SP

Ah. Nous n'avons pas les mêmes variables...

Hervé Autret wrote in message
<pan.2006.10.27.22.00.40.809858@alussinan.org>:
> ... de celui qui a fait ce truc, non ?

Non, vraiment, le comportement actuel est vraiment le comportement
préférable, mais hélas, il est peu stable du point de vue de
l'implémentation.

>> PROMPT_CR
> Ok, merci. D'un autre côté, l'option n'a pas d'effet visible dans xterm...
> Serait-ce que xterm ignore les CR quand il "voit" qu'ils auront pour effet
> d'effacer des caractères déjà affichés ?

Non, jamais de la vie. Quel est ton protocole de test, et quels résultats
obtiens-tu exactement?

Hervé Autret wrote in message
<pan.2006.10.29.12.37.23.383444@alussinan.org>:
> Suivant quels critères ? ou pour répondre à quelle question ?

Suivant le critère de l'ergonomie et du principe de moindre surprise.

> Si "préférable" et "instable" sont liés, ça doit pas être
> tout-à-fait une bonne définition de ce qu'on peut appeler "préférable" ?

Le comportement serait préférable dans l'absolu, mais l'interface des
terminaux ne permet pas de l'implémenter fiablement. C'est plus clair comme
ça?

Maintenant, il faut évaluer le manque de fiabilité, et voir s'il justifie de
revenir à un comportement moins ergonomique dans l'absolu, mais
implémentable plus fiablement. Dans les circonstances usuelles (lien avec le
terminal relativement rapide, en particulier), je pense que non.

> bash-3.00$ cat .zshrc
> NO_PROMPT_CR=1

PROMPT_CR est une option, pas une variable. Cherche setopt dans la doc de
zsh.

Nicolas George posta :

> le comportement actuel est vraiment le comportement préférable,

Suivant quels critères ? ou pour répondre à quelle question ?

> mais hélas, il est peu stable du point de vue de l'implémentation.

Si "préférable" et "instable" sont liés, ça doit pas être
tout-à-fait une bonne définition de ce qu'on peut appeler "préférable" ?

> Quel est ton protocole de test, et quels résultats
> obtiens-tu exactement?

Tiens, c'est différent ! Peu stable, disais-tu... J'ai positionné
NO_PROMPT_CR=1 dans .zshrc, mais l'otion n'a plus d'effet ni dans un xterm
ni dans un rxvt.

<fichier toto.txt>
toto[CR]
titi[EOF]
</fichier toto.txt>

bash-3.00$ cat toto.txt
toto
titibash-3.00$

On voit que la seconde ligne a été affichée verbatim, ce que j'aurais
tendance à appeler "préférable", personnellement.
Cat c'est "cat", c'est pas "raconte-moi des salades".

bash-3.00$ cat .zshrc
NO_PROMPT_CR=1
...
bash-3.00$ zsh
jeronimo% cat toto.txt
toto
jeronimo%

Ici, on voit que zsh affiche son CR suplémentaire (option NO_PROMPT_CR
ignorée : pourquoi ?), et la dernière ligne du fichier n'est
pas visible.
Ce qui peut parfois jouer de très sales tours et/ou faire perdre un temps
considérable. D'où mon questionnement au sujet du "comportement
préférable".

à +
--
Hervé

[supersedes (salade CR/LF]
Bonjour Nicolas

> le comportement actuel est vraiment le comportement préférable,

Suivant quels critères ? ou pour répondre à quelle question ?

> mais hélas, il est peu stable du point de vue de l'implémentation.

Si "préférable" et "instable" sont liés, ça doit pas être
tout-à-fait une bonne définition de ce qu'on peut appeler "préférable" ?

> Quel est ton protocole de test, et quels résultats
> obtiens-tu exactement?

Tiens, c'est différent ! Peu stable, disais-tu... J'ai positionné
NO_PROMPT_CR=1 dans .zshrc, mais l'otion n'a plus d'effet ni dans un xterm
ni dans un rxvt.

<fichier toto.txt>
toto[LF]
titi[EOF]
</fichier toto.txt>

bash-3.00$ cat toto.txt
toto
titibash-3.00$

On voit que la seconde ligne a été affichée verbatim, ce que j'aurais
tendance à appeler "préférable", personnellement.
Cat c'est "cat", c'est pas "raconte-moi des salades".

bash-3.00$ cat .zshrc
NO_PROMPT_CR=1
...
bash-3.00$ zsh
jeronimo% cat toto.txt
toto
jeronimo%

Ici, on voit que zsh affiche son CR suplémentaire (option NO_PROMPT_CR
ignorée : pourquoi ?), et la dernière ligne du fichier n'est
donc pas visible.
Ce qui peut parfois jouer de très sales tours et/ou faire perdre un temps
considérable. D'où mon questionnement au sujet du "comportement
préférable".

à +
--
Hervé

Hervé Autret wrote in message
<pan.2006.10.29.15.25.51.522846@alussinan.org>:
> Je pense que le principe de "moindre surprise" n'est pas respecté dans le
> sens où une partie du fichier n'est pas affichée (par head, tail ou
> cat).

Tu retardes d'une génération, justement: je parle du comportement par
défaut actuel, qui l'affiche, cette dernière ligne incomplète, justement,
suivie d'un caractère spécial pour l'indiquer.