Created attachment 301475 [details] Example output of eix-update The output of eix-0.23.9 contains garbage strings like "^[]0;eix-update: Finished^G" (with ^[ and ^G being the escape and bell characters, respectively). See attached session log. The problem didn't occur with eix-0.23.7.
What you call "garbage" are the ANSI escape sequences to set the status line which is obviously displayed falsely by your dumb terminal (here it works with xterm+tmux even if I set TERM=dumb). I do not know a reliable compatible way to check whether a terminal treats these escapes correctly, otherwise one could do some more automagic. You can use option -H or set NOSTATUSLINE=1 (e.g. in /etc/eixrc for a permanent change) to suppress output of a statusline.
(In reply to comment #1) > What you call "garbage" are the ANSI escape sequences to set the status line > which is obviously displayed falsely by your dumb terminal (here it works > with xterm+tmux even if I set TERM=dumb). You shouldn't send such xterm specific escape sequences to the terminal without testing for the TERM environment variable first. Otherwise it will fail everywhere else (e.g. in the Linux console, in an Emacs shell window, in screen). > I do not know a reliable compatible way to check whether a terminal treats > these escapes correctly, otherwise one could do some more automagic. Normally one would use terminfo(5) capabilities, i.e. ncurses for this. The terminal status line can be set with the hs, tsl, and fsl capabilities. For example, in the shell one would do: tput hs && { tput tsl; echo -n foo; tput fsl; } However, for some reason these caps aren't supported by the plain xterm terminfo entry. (They're supported with TERM=xterm+sl but I guess nobody is using this.) So AFAICS testing for TERM matching xterm* might be the best one can do. > You can use option -H or set NOSTATUSLINE=1 (e.g. in /etc/eixrc for a > permanent change) to suppress output of a statusline. The default behaviour should be that things are just working, without requiring any special tweaks of the configuration. Reopening.
(In reply to comment #2) > You shouldn't send such xterm specific escape sequences It is not xterm specific. It is understood by all terminals which support a status line - which is almost every terminal in X (I checked "only" rxvt, aterm, xterm, and konsole but would be surprised if it would be different for most other popular terminals under X like gnome-terminal), under screen, or under tmux; AFAIK even many hardware terminals (AFAIK this is where the name hardstatusline comes from). Already the X|screen|tmux terminals cover most probably the majority of use cases. > > I do not know a reliable compatible way to check whether a terminal treats > > these escapes correctly, otherwise one could do some more automagic. > > Normally one would use terminfo(5) capabilities, i.e. ncurses for this. As I said: I don't know a reliable compatible way. Using a library not available everywhere to check for a feature not available everywhere (and the library does not even always produce the correct result) is IMHO not a reliable compatible solution. > So AFAICS testing for TERM matching xterm* might be the best one can do. And one would already miss important cases like rxvt, aterm, konsole, screen, tmux (and I guess also eterm, gnome, ...). > The default behaviour should be that things are just working, > without requiring any special tweaks of the configuration. Yep. And making NOSTATUSLINE=false the default would make the status line not work. Even worse, practically no user could make it work, because he would not know that the possibility exists. On the other hand, a user with an exotic terminal can immediately see that something might need to be configured and can easily change it to make the output look nice also for his terminal. With defaults only guaranteed to work on every terminal, one would also have to make NOCOLORS=true and NOPERCENTAGE=true the default, because one can certainly find some exotic terminals which do not correctly treat the ANSI sequences needed for these.
I you don't know how to handle it properly, then the feature should be turned off by default. After all, having a status line is not so essential that it would justify such breakage. (In reply to comment #3) > It is not xterm specific. It is understood by all terminals which > support a status line - which is almost every terminal in X > (I checked "only" rxvt, aterm, xterm, and konsole but would be surprised > if it would be different for most other popular terminals under X like > gnome-terminal), under screen, or under tmux; AFAIK even many > hardware terminals (AFAIK this is where the name hardstatusline comes > from). Then check for these terminals. For example, portage checks for TERM matching the following regexp: ^(xterm|xterm-color|Eterm|aterm|rxvt|screen|kterm|rxvt-unicode|gnome|interix) Reopening.
(In reply to comment #4) > After all, having a status line is not so essential that it > would justify such breakage. After all, having a few confusing symbols displayed in a few cases is not so essential to justify breakage of the statusline output in most cases. (If the output is not a terminal, the problem does not occur at all, so in no case there is a real breakage of e.g. scripts). Essentially, it comes down to deciding the default of having a less convenient output in one case or in the other case. However, portage's approach to the problem appears to be a good compromise: This way the probability of a "correct" default is increased. I have implemented a similar idea (with a user-extendable list) in eix's git master (>=eix-0.23.10). Not sure yet, whether I should turn the current positive list into a negative list - I guess both will be rather large if somewhat complete.
(In reply to comment #5) > After all, having a few confusing symbols displayed in a few cases > is not so essential to justify breakage of the statusline output > in most cases. Except that one cannot tell what unknown escape sequences will do to a terminal. The ^G causes the Linux console to beep which is annoying enough. ;-)
Closing as the currrent heuristics is probably among the best one can do.
