[pacman-dev] -Qi output corrupted when using screen
Hi! It has been a looong time since I last posted here (or even read the list), so please forgive me if this is a known issue. I have a VPS on Linode and they have a tool called LISH which is a minimal environment that is accessible via logging in via ssh on the _host_. There is a screen session that shows the output from /dev/hvc0 (which is hardware tty in Xen), so you can access your system even if you locked yourself from accessing it via ssh. When doing pacman -Qi in that screen session I get corrupted output like this: <some text from the top of the host's tty buffer goes here first> Feb 2010 12:14:18 AM UTC Install Date : Sun 14 Feb 2010 02:21:13 PM UTC Install Reason : Explicitly installed Install Script : Yes Description : Utility programs used for creating patch files This happens only when doing -Qi. Any ideas about this? And if it's a known issue - how to fix it? -- Roman Kyrylych (Роман Кирилич)
On Fri, Feb 26, 2010 at 3:38 PM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Hi!
It has been a looong time since I last posted here (or even read the list), so please forgive me if this is a known issue.
I have a VPS on Linode and they have a tool called LISH which is a minimal environment that is accessible via logging in via ssh on the _host_. There is a screen session that shows the output from /dev/hvc0 (which is hardware tty in Xen), so you can access your system even if you locked yourself from accessing it via ssh.
When doing pacman -Qi in that screen session I get corrupted output like this: <some text from the top of the host's tty buffer goes here first> Feb 2010 12:14:18 AM UTC Install Date : Sun 14 Feb 2010 02:21:13 PM UTC Install Reason : Explicitly installed Install Script : Yes Description : Utility programs used for creating patch files
This happens only when doing -Qi.
Any ideas about this? And if it's a known issue - how to fix it?
from src/pacman/util.c : /* gets the current screen column width */ int getcols(void) { #ifdef TIOCGSIZE struct ttysize win; if(ioctl(1, TIOCGSIZE, &win) == 0) { return win.ts_cols; } #elif defined(TIOCGWINSZ) struct winsize win; if(ioctl(1, TIOCGWINSZ, &win) == 0) { return win.ws_col; } #endif return 0; } I don't know anything about this stuff, what the limitations of the above code are, etc... But it would be useful to know in which case you are in the above code, and what value is returned by that function. A quick google for TIOCGSIZE : http://www.ohse.de/uwe/software/resize.c.html this program demonstrates how complicated a simple task can be: the inquiry of the remote terminals window size. ...
Here is a simple POC to see what the output is. It calls ioctl twice with a 10 second delay for changing window sizes between calls. It doesn't use TIOCGSIZW as that is not defined in Linux, but rather BSD and maybe some others. I am not familiar with vps or linode. -- Jeff My other computer is an abacus.
I guess I should actually send it. ;) -- Jeff My other computer is an abacus.
On Fri, Feb 26, 2010 at 7:38 AM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Any ideas about this? And if it's a known issue - how to fix it?
Your terminal is configured wrong. What is $TERM set to? If you are in screen it should be screen (or some variant such as screen-bce)
Am 26.02.2010 22:01, schrieb Aaron Griffin:
On Fri, Feb 26, 2010 at 7:38 AM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Any ideas about this? And if it's a known issue - how to fix it?
Your terminal is configured wrong. What is $TERM set to? If you are in screen it should be screen (or some variant such as screen-bce)
"xm console" is a rather primitive terminal, not nearly as powerful as screen.
On Sat, Feb 27, 2010 at 01:38, Thomas Bächler <thomas@archlinux.org> wrote:
Am 26.02.2010 22:01, schrieb Aaron Griffin:
Your terminal is configured wrong. What is $TERM set to? If you are in screen it should be screen (or some variant such as screen-bce)
TERM is linux. Changing it does not help.
"xm console" is a rather primitive terminal, not nearly as powerful as screen.
Ah, didn't know this. I tried iptraf, and the output was a broken too (in another way), so it's not just pacman that experiences this problem. However, -Sy falls back gracefully, i.e. via lish (screen to /dev/hvc0): testing 14.5K 52.4K/s 00:00:00 core 36.1K 85.7K/s 00:00:00 extra 445.6K 60.8K/s 00:00:07 via ssh: testing 14.5K 56.2K/s 00:00:00 [#####################] 100% core 36.1K 91.1K/s 00:00:00 [#####################] 100% extra 152.0K 75.8K/s 00:00:03 [#######--------------] 34% -Ss is broken too. It looks like the breakage occurs on spaces after some column, so -Ql doesn't break even very long lines, because there is no space in package paths. It would be nice to have -Ss/-Si/-Qi usable too, but it seems like a very low priority (I don't know if there are many people who run pacman on such limited terminals as xm console) -- Roman Kyrylych (Роман Кирилич)
On Sat, Feb 27, 2010 at 10:39 AM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
On Sat, Feb 27, 2010 at 01:38, Thomas Bächler <thomas@archlinux.org> wrote:
Am 26.02.2010 22:01, schrieb Aaron Griffin:
Your terminal is configured wrong. What is $TERM set to? If you are in screen it should be screen (or some variant such as screen-bce)
TERM is linux. Changing it does not help.
"xm console" is a rather primitive terminal, not nearly as powerful as screen.
Ah, didn't know this.
I tried iptraf, and the output was a broken too (in another way), so it's not just pacman that experiences this problem.
However, -Sy falls back gracefully, i.e. via lish (screen to /dev/hvc0): testing 14.5K 52.4K/s 00:00:00 core 36.1K 85.7K/s 00:00:00 extra 445.6K 60.8K/s 00:00:07 via ssh: testing 14.5K 56.2K/s 00:00:00 [#####################] 100% core 36.1K 91.1K/s 00:00:00 [#####################] 100% extra 152.0K 75.8K/s 00:00:03 [#######--------------] 34%
-Ss is broken too. It looks like the breakage occurs on spaces after some column, so -Ql doesn't break even very long lines, because there is no space in package paths.
It would be nice to have -Ss/-Si/-Qi usable too, but it seems like a very low priority (I don't know if there are many people who run pacman on such limited terminals as xm console)
Define usable. Nothing you posted showed any sort of corruption whatsoever, it just linebreaked where you didn't expect. If you are using a crappy terminal that doesn't support queries for size, then use this as a workaround: pacman -Qi glibc | cat -Dan
On Sat, Feb 27, 2010 at 18:42, Dan McGee <dpmcgee@gmail.com> wrote:
Define usable. Nothing you posted showed any sort of corruption whatsoever, it just linebreaked where you didn't expect. We have a different understanding of "usable" in this case. :-) Perhaps it would be more correct to say "easily readable".
If you are using a crappy terminal that doesn't support queries for size, then use this as a workaround: pacman -Qi glibc | cat
Thanks, this does the trick. It wraps the output of -Qi on 80th column which is fine. -- Roman Kyrylych (Роман Кирилич)
On Sat, Feb 27, 2010 at 11:14 AM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
On Sat, Feb 27, 2010 at 18:42, Dan McGee <dpmcgee@gmail.com> wrote:
Define usable. Nothing you posted showed any sort of corruption whatsoever, it just linebreaked where you didn't expect. We have a different understanding of "usable" in this case. :-) Perhaps it would be more correct to say "easily readable".
If you are using a crappy terminal that doesn't support queries for size, then use this as a workaround: pacman -Qi glibc | cat
Thanks, this does the trick. It wraps the output of -Qi on 80th column which is fine.
It actually doesn't wrap at all; it leaves it up to the piped-to program to do the work. However, you will notice you now wrap package names and words mid-word instead of only splitting on spaces. -Dan
On Sat, Feb 27, 2010 at 19:26, Dan McGee <dpmcgee@gmail.com> wrote:
On Sat, Feb 27, 2010 at 11:14 AM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
On Sat, Feb 27, 2010 at 18:42, Dan McGee <dpmcgee@gmail.com> wrote:
If you are using a crappy terminal that doesn't support queries for size, then use this as a workaround: pacman -Qi glibc | cat
Thanks, this does the trick. It wraps the output of -Qi on 80th column which is fine.
It actually doesn't wrap at all; it leaves it up to the piped-to program to do the work. However, you will notice you now wrap package names and words mid-word instead of only splitting on spaces.
Wrapping occurs only when terminal's width is <80 columns, otherwise I always get the same output: Required By : attr bash bzip2 coreutils cracklib dcron dhcpcd diffutils eventlog expat file findutils gawk gcc-libs gdbm gen-init-cpio grep gzip initscripts iptables iputils kbd libcap libgpg-error libidn libjpeg libpcap libtasn1 mkinitcpio-busybox module-init-tools nano ncurses net-tools pam perl popt procinfo psmisc readline run-parts sudo sysfsutils sysstat sysvinit tar tcp_wrappers udev visitors wget which zlib -- Roman Kyrylych (Роман Кирилич)
On Sat, Feb 27, 2010 at 8:15 PM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Wrapping occurs only when terminal's width is <80 columns, otherwise I always get the same output: Required By : attr bash bzip2 coreutils cracklib dcron dhcpcd diffutils eventlog expat file findutils gawk gcc-libs gdbm gen-init-cpio grep gzip initscripts iptables iputils kbd libcap libgpg-error libidn libjpeg libpcap libtasn1 mkinitcpio-busybox module-init-tools nano ncurses net-tools pam perl popt procinfo psmisc readline run-parts sudo sysfsutils sysstat sysvinit tar tcp_wrappers udev visitors wget which zlib
Well Jeff and I are still waiting for some feedback on our original questions.. The behavior when piping the output has changed in master. Before it defaulted to 80 columns, but now it doesn't wrap anymore : See http://projects.archlinux.org/pacman.git/commit/?id=5dbd00faf7a27866ffc2a719...
On Sat, Feb 27, 2010 at 23:35, Xavier Chantry <chantry.xavier@gmail.com> wrote:
Well Jeff and I are still waiting for some feedback on our original questions..
Sorry for the delay. On Fri, Feb 26, 2010 at 22:39, Jeff <jeff@kcaccess.com> wrote:
Here is a simple POC to see what the output is. It calls ioctl twice with a 10 second delay for changing window sizes between calls. It doesn't use TIOCGSIZW as that is not defined in Linux, but rather BSD and maybe some others. I am not familiar with vps or linode.
So, I get rows: 0 columns: 0 rows: 0 columns: 0 instead of expected rows: 24 columns: 80 rows: 36 columns: 139 -- Roman Kyrylych (Роман Кирилич)
On Sun, Feb 28, 2010 at 10:24 AM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
On Sat, Feb 27, 2010 at 23:35, Xavier Chantry <chantry.xavier@gmail.com> wrote:
Well Jeff and I are still waiting for some feedback on our original questions..
Sorry for the delay.
On Fri, Feb 26, 2010 at 22:39, Jeff <jeff@kcaccess.com> wrote:
Here is a simple POC to see what the output is. It calls ioctl twice with a 10 second delay for changing window sizes between calls. It doesn't use TIOCGSIZW as that is not defined in Linux, but rather BSD and maybe some others. I am not familiar with vps or linode.
So, I get rows: 0 columns: 0 rows: 0 columns: 0 instead of expected rows: 24 columns: 80 rows: 36 columns: 139
So TIOCGWINSZ is defined, the ioctl call does not return any error, but it still just returns 0. Weird. By the way, how did you figure out the expected values ? In git master, after the commit I linked above, with your bogus ioctl call, or piping to cat, getcols() returns 0, and the callers treat that as no linewrap. So that could be a problem for you. I wonder if we should keep the fallback to 80 columns in this bogus situation. Or maybe we could fallback to that old unused code : - /* Original envvar way - prone to display issues - const char *cenv = getenv("COLUMNS"); - if(cenv != NULL) { - return atoi(cenv); I am curious to know if that's the only way that works for you.
On Sun, Feb 28, 2010 at 12:31, Xavier Chantry <chantry.xavier@gmail.com> wrote:
On Sun, Feb 28, 2010 at 10:24 AM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
On Sat, Feb 27, 2010 at 23:35, Xavier Chantry <chantry.xavier@gmail.com> wrote:
Well Jeff and I are still waiting for some feedback on our original questions..
Sorry for the delay.
On Fri, Feb 26, 2010 at 22:39, Jeff <jeff@kcaccess.com> wrote:
Here is a simple POC to see what the output is. It calls ioctl twice with a 10 second delay for changing window sizes between calls. It doesn't use TIOCGSIZW as that is not defined in Linux, but rather BSD and maybe some others. I am not familiar with vps or linode.
So, I get rows: 0 columns: 0 rows: 0 columns: 0 instead of expected rows: 24 columns: 80 rows: 36 columns: 139
So TIOCGWINSZ is defined, the ioctl call does not return any error, but it still just returns 0. Weird. By the way, how did you figure out the expected values ?
The "expected" are when executing Jeff's term_sz program while logged in via ssh (2nd pair is after I resized the window).
In git master, after the commit I linked above, with your bogus ioctl call, or piping to cat, getcols() returns 0, and the callers treat that as no linewrap. So that could be a problem for you. I wonder if we should keep the fallback to 80 columns in this bogus situation.
Or maybe we could fallback to that old unused code : - /* Original envvar way - prone to display issues - const char *cenv = getenv("COLUMNS"); - if(cenv != NULL) { - return atoi(cenv);
I am curious to know if that's the only way that works for you.
Perhaps if win.ts_cols is 0 after ioctl it should assume 80 or use getenv (if that doesn't cause extra issues), and to check if we are on a non-tty it should use isatty(). -- Roman Kyrylych (Роман Кирилич)
On Sun, Feb 28, 2010 at 4:31 AM, Xavier Chantry <chantry.xavier@gmail.com> wrote:
On Sun, Feb 28, 2010 at 10:24 AM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
On Sat, Feb 27, 2010 at 23:35, Xavier Chantry <chantry.xavier@gmail.com> wrote:
Well Jeff and I are still waiting for some feedback on our original questions..
Sorry for the delay.
On Fri, Feb 26, 2010 at 22:39, Jeff <jeff@kcaccess.com> wrote:
Here is a simple POC to see what the output is. It calls ioctl twice with a 10 second delay for changing window sizes between calls. It doesn't use TIOCGSIZW as that is not defined in Linux, but rather BSD and maybe some others. I am not familiar with vps or linode.
So, I get rows: 0 columns: 0 rows: 0 columns: 0 instead of expected rows: 24 columns: 80 rows: 36 columns: 139
So TIOCGWINSZ is defined, the ioctl call does not return any error, but it still just returns 0. Weird. By the way, how did you figure out the expected values ?
In git master, after the commit I linked above, with your bogus ioctl call, or piping to cat, getcols() returns 0, and the callers treat that as no linewrap. So that could be a problem for you. I wonder if we should keep the fallback to 80 columns in this bogus situation.
Or maybe we could fallback to that old unused code : - /* Original envvar way - prone to display issues - const char *cenv = getenv("COLUMNS"); - if(cenv != NULL) { - return atoi(cenv);
I am curious to know if that's the only way that works for you.
Honestly, why should we hack around terms that don't return valid values for us? Not wrapping seems perfectly reasonable in this situation. -Dan
On Sun, Feb 28, 2010 at 11:44:44AM -0600, Dan McGee wrote:
Honestly, why should we hack around terms that don't return valid values for us? Not wrapping seems perfectly reasonable in this situation.
Agreed. This seems to be a terminal problem, not a pacman problem, but it does make me curious if your terminal supports window size calculations and if so, what the user is supposed to do to get it. Someone said it was a broken terminal. While the term broken in this case might be an opinion, there is a real class of terminals known as dumb terminals. Yours might be one. There would be no true fix as the terminal is dumb by design. -- Jeff My other computer is an abacus.
participants (6)
-
Aaron Griffin
-
Dan McGee
-
Jeff
-
Roman Kyrylych
-
Thomas Bächler
-
Xavier Chantry