Proper solution to figure out terminal size inside of a subshell

[purpleP]

My recent investigation about my binary size have led me to the fact that crossterm wastes 10K to call tput to determine terminal size in a subshell.

I've found the discussion.

It hurts my feelings that such things are merged into master especially without even tracking issue to make proper solution.

I've created a question to debug tput inside of a subshell.

@Canop when running inside gdb it should count as a subshell, right?

--with-install-prefix=/tmp/delme/tmp/delme/bin/tputSYS_ioctl(2, 0x5401, 0x7ffda84b6480, 0x55ec6d0d4010)             = 0
SYS_ioctl(2, 0x5401, 0x7ffda84b64b0, 0x55ec6d0d4010)             = 0
SYS_ioctl(2, 0x5401, 0x7ffda84b64b0, 0x55ec6d0d4010)             = 0
SYS_ioctl(2, 0x5401, 0x7ffda84b6410, 0x55ec6d0d4010)             = 0
SYS_ioctl(2, 0x5413, 0x7ffda84b64d0, 0x55ec6d0d4010)             = 0
env TERM=xterm-kitty gdbserver localhost:2345 progs/tput cols(ins)(gdb) b tput_cmd
Breakpoint 1 at 0x555555556dd0
(ins)(gdb) c
Continuing.
Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target...
Reading /lib/x86_64-linux-gnu/libc-2.30.so from remote target...
Reading /lib/x86_64-linux-gnu/.debug/libc-2.30.so from remote target...
Reading /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.30.so from remote target...
Reading /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.30.so from remote target...

Breakpoint 1, 0x0000555555556dd0 in tput_cmd ()
(ins)(gdb) l
1       ../sysdeps/unix/sysv/linux/x86_64/init-first.c: No such file or directory.
(ins)(gdb) l
1       in ../sysdeps/unix/sysv/linux/x86_64/init-first.c
(ins)(gdb) l
1       in ../sysdeps/unix/sysv/linux/x86_64/init-first.c
(ins)(gdb) n
Single stepping until exit from function tput_cmd,
which has no line number information.
0x00005555555569fe in main ()
(ins)(gdb)
ltrace -S bash -c 'tput cols' 2>&1 | tail -n20
SYS_stat("/etc/terminfo", 0x562b5cb264d0)        = 0
SYS_stat("/lib/terminfo", 0x562b5cb26560)        = 0
SYS_stat("/usr/share/terminfo", 0x562b5cb265f0)  = 0
SYS_access("/etc/terminfo/x/xterm-256color", 04) = -2
SYS_access("/lib/terminfo/x/xterm-256color", 04) = 0
SYS_openat(0xffffff9c, 0x7ffd9a2a57a0, 0, 0)     = 3
SYS_fstat(3, 0x7ffd9a295530)                     = 0
SYS_read(3, "\036\002%", 32768)                  = 3503
SYS_read(3, "", 28672)                           = 0
SYS_close(3)                                     = 0
SYS_ioctl(0, 0x5401, 0x7ffd9a2a6720, 0x562b5cb26010) = 0
SYS_ioctl(0, 0x5401, 0x7ffd9a2a6750, 0x562b5cb26010) = 0
SYS_ioctl(0, 0x5401, 0x7ffd9a2a6750, 0x562b5cb26010) = 0
SYS_ioctl(0, 0x5401, 0x7ffd9a2a66b0, 0x562b5cb26010) = 0
SYS_ioctl(0, 0x5413, 0x7ffd9a2a6770, 0x562b5cb26010) = 0
SYS_fstat(1, 0x7ffd9a2a5ef0)                     = 0
SYS_write(1, "106\n", 4106
)                         = 4
SYS_exit_group(0 <no return ...>
+++ exited (status 0) +++

It seems like tput isn't doing anything except invoking ioctl.

Have anyone built minimal reproducible example using ioctl which gives incorrect answer in a subshell? Is there a test that shows that it doesn't work?

[TimonPost]

@purpleP I am getting a bit tired of the way you are communicating even after this was made clear and we ignored those bad communication styles. I think we all agreed on the fact that the subprocess call is a bad idea however you keep the sticking finger up. We are here to work on a solution, and we do this all in our free time, it is not only your precious time. I will not discuss further here.

Anyhow, I open a new issue, delete this whole issue and go on with @sharnoff his last comment. And suggest not to comment there unless you really want to help and get this part improved. At least thanks for bringing it up.

New issue: #422