FORUMS
Remove All Ads from XDA
Honor View 10

Terminal emulator size after upgrade Android 4.3

12 posts
Thanks Meter: 2
 
By alf_tux, Junior Member on 30th July 2013, 07:30 PM
Post Reply Email Thread
Hi,

I'm having an issue with all terminal emulators (Android Terminal Emulator, ConnectBot, ...) after upgrading my Nexus 10 from Android 4.2.2 to 4.3.
The terminal is not recognizing the actual size of the screen and it is fixed to 80 columns and 20 rows. I can temporarily fix it typing "stty cols 180 rows 35", but those values depend on the screen rotation, font size, etc.
This is really weird, and I wasn't having this issue before the upgrade.

Anyone else has this problem or know how to solve it?

Thanks!
 
 
31st July 2013, 05:29 PM |#2  
OP Junior Member
Thanks Meter: 2
 
More
Prompt
Ok, i've been doing some tests.
It seems to be a 'su' bug, it is not receiving the SIGWINCH signal.
If I type without su:
trap 'echo sigwinch' SIGWINCH
It is executed every time I rotate the tablet or popup the keyboard.
But, under su, the same command is not working.

It may be a permission issue.

Any ideas?
The Following User Says Thank You to alf_tux For This Useful Post: [ View ] Gift alf_tux Ad-Free
1st August 2013, 12:38 PM |#3  
Junior Member
Thanks Meter: 0
 
More
I can confirm having the same issue with my Nexus 10 and android 4.3. As soon as I run su - from the terminal (Android Terminal Emulator) the lines start wrapping at 80 characters.
1st August 2013, 04:42 PM |#4  
OP Junior Member
Thanks Meter: 2
 
More
Prompt
Hi,

i've been working on this trying to find a solution.
Here is what I saw:
Every time I enter su or enter chroot (i have a chrooted debian), the tty number is changed to another one. That isn't the usual tty behavior!
So, if the normal user is in /dev/pts/0 , root could be in /dev/pts/1 and chroot in /dev/pts/2.
If I rotate the screen /dev/pts/0 cols and rows are changed even if I am as root, I can verify that by typing:
stty -F /dev/pts/0 -a

But, if I am at /dev/pts/1 i'm not receiving that SIGWINCH signal. In common linux distributions, that is not happening as pts number doesn't change.

Here is my (not so perfect) solution for the chrooted debian:
Write a fix_stty.sh script as root:

#!/bin/bash
sttypath=/bin
tty0=$(ls --sort time /dev/pts/ | head -n 1 | awk '{print $1}')
stty0=$($sttypath/stty -F /dev/pts/$tty0 -a | head -n1)
rows=$(echo $stty0 | sed -e 's:.*rows\ \([0-9]\+\).*:\1:g')
cols=$(echo $stty0 | sed -e 's:.*columns\ \([0-9]\+\).*:\1:g')
$sttypath/stty rows $rows cols $cols

Save it in /usr/local/bin
Make it executable:
chmod +rx /usr/local/bin/fix_stty.sh

Add to ~/.bashrc this line:
trap '/usr/local/bin/fix_stty.sh' DEBUG

Or if you use non-root users:
trap 'sudo /usr/local/bin/fix_stty.sh' DEBUG
And add to sudoers file:
%sudo ALL = (ALL) NOPASSWD: /usr/local/bin/fix_stty.sh

Logout and login again, and it will fix the rows and columns before each command.

----

For su, outside the chrooted linux write a script fix_stty.sh:

sttypath=/system/xbin
tty0=$(/system/xbin/busybox ls -t /dev/pts | head -n1)
stty0=$($sttypath/stty -F /dev/pts/$tty0 -a | head -n1)
rows=$(echo $stty0 | sed -e 's:.*rows\ \([0-9]\+\).*:\1:g')
cols=$(echo $stty0 | sed -e 's:.*columns\ \([0-9]\+\).*:\1:g')
$sttypath/stty rows $rows cols $cols

Save it to /system/xbin
(You should remount /system as rw: mount --remount -orw /system)

Then, make it exec:
chmod 755 /system/xbin/fix_stty.sh

And, finally you should type at each su login:
trap '/system/xbin/fin_stty.sh' SIGINT
(i don't know why DEBUG isn't here)
So you have to press Ctrl+C to fix it.

----

Alternatively, you can write an infinite loop or a simple daemon to fix it, but i don't like daemons on my tablet.

If anyone has a better solutions, please post it.
The Following User Says Thank You to alf_tux For This Useful Post: [ View ] Gift alf_tux Ad-Free
6th August 2013, 10:01 AM |#5  
tan-ce's Avatar
Member
Singapore
Thanks Meter: 6
 
More
Hi all. I've been mulling over this problem as well. I believe the issue is because in 4.3, SuperSU now uses a "proxy", where commands are sent form the process which called su to daemonsu, which is launched at system startup. Chainfire explains a bit more in his G+ posts the reasons for doing this, but I think the key here is that root processes are now launched on a different tty, because they are launched by a different process (namely, daemonsu). Starting a root shell (whether system shell or ubuntu/debian chroot) now results in the creation of three pts devices, as opposed to the usual one. However, other shells not launched locally are fine. For example, starting the SSH server in my chroot and logging in via SSH is always fine.

I'm still trying to figure out a permanent solution to this problem. I still don't have a full understanding of the problem as I'm still trying to wrap my head around how Linux handles terminals and TTYs. I do have a few ideas floating around my head, though:
  • Change daemonsu and su to support full termios/line-discipline/whatever-we-need through the "pts bridge" that he is using
  • Create TTY(pts) pairs on demand, and have a modified Terminal Emulator connect to those directly when we want a shell
  • Have a background-ed process in the original terminal catch SIGWINCH and pass it to the root terminal

Still quite a bit a figure out though. I may just go through Terminal Emulator's source code to see how it work to get a better picture too. But that's gonna take time. I've also created a little native utility which creates two pts pseudo-TTYs and shuffles data between them. I'm still experimenting. Will post more as I learn more.
28th August 2013, 04:26 PM |#6  
tan-ce's Avatar
Member
Singapore
Thanks Meter: 6
 
More
Just to let you all know that I've got a system working for myself: http://blog.tan-ce.com/android-root-shell/

The way I'm doing it uses a daemon, much like the su daemons ChainFire and Koush are using. The benefit of doing it this way is that I'm not confined by the application container, which is good for security when used by applications, but is annoying when you are using the terminal itself. I remember having to do hacks with adb servers to get around those.

But if you don't want a daemon, you can still set one up manually, just look at the last section of the README on how to use pts-wrap and pts-exec.
29th August 2013, 12:51 AM |#7  
OP Junior Member
Thanks Meter: 2
 
More
I gave this a try.
First, I've noticed that pts-wrap and pts-exec symbolic links were missing.
And I don't think the line '/system/etc/install-recovery-2.sh' in pts-daemon-start file is needed at all.

I'm using ChainFire SuperSU and pts-shell is not working as expected or catching SIGWINCH signals. I just don't see any difference with the standard shell. Maybe I misunderstood how it works.
29th August 2013, 04:44 AM |#8  
tan-ce's Avatar
Member
Singapore
Thanks Meter: 6
 
More
Quote:
Originally Posted by alf_tux

I gave this a try.
First, I've noticed that pts-wrap and pts-exec symbolic links were missing.
And I don't think the line '/system/etc/install-recovery-2.sh' in pts-daemon-start file is needed at all.

My mistake, I forgot to create the symlinks for those two.

install-recovery-2.sh is an idea I took from CharinFire's SuperSU. Basically, it seems as if people are using install-recovery.sh to install startup scripts, and having the script try to call install-recovery-2.sh allows you to chain recovery scripts. For example, if you install this on a system with SuperSU, it will be installed as install-recovery-2.sh. If the system doesn't already have an install-recovery.sh, it'll install itself as install-recovery.sh.

Anyway, I've fixed and uploaded a new zip.

Quote:
Originally Posted by alf_tux

I'm using ChainFire SuperSU and pts-shell is not working as expected or catching SIGWINCH signals. I just don't see any difference with the standard shell. Maybe I misunderstood how it works.

Are you running pts-shell from a regular (non-root) shell, or from a root shell? It should be run from a non-root shell. (It will give you a root shell once it runs.) Only pts-passwd and pts-daemon is meant to be run as root.
29th August 2013, 05:38 AM |#9  
OP Junior Member
Thanks Meter: 2
 
More
Quote:
Originally Posted by tan-ce

Are you running pts-shell from a regular (non-root) shell, or from a root shell? It should be run from a non-root shell. (It will give you a root shell once it runs.) Only pts-passwd and pts-daemon is meant to be run as root.

Yes, here is my the terminal output:

u0_a68@manta:/ $ ps | grep pts
root 136 1 760 180 ffffffff 00000000 S /system/xbin/pts-daemon
u0_a68@manta:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Permission denied
255|u0_a68@manta:/ $ su pts-shell /system/bin/sh
root@manta:/ #

As you see, I can only run pts-shell as root.
29th August 2013, 05:45 AM |#10  
OP Junior Member
Thanks Meter: 2
 
More
Quote:
Originally Posted by alf_tux

Yes, here is my the terminal output:

u0_a68@manta:/ $ ps | grep pts
root 136 1 760 180 ffffffff 00000000 S /system/xbin/pts-daemon
u0_a68@manta:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Permission denied
255|u0_a68@manta:/ $ su pts-shell /system/bin/sh
root@manta:/ #

As you see, I can only run pts-shell as root.

Sorry, I realized that the correct command should be:

u0_a68@manta:/ $ su -c pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
(pts-shell) Enter your password:
root@manta:/ #

Anyway I can only run this as root.
29th August 2013, 07:50 AM |#11  
tan-ce's Avatar
Member
Singapore
Thanks Meter: 6
 
More
Oh yeah, I found the bug. Sorry, my bad. I've fixed it and uploaded a new copy of the update ZIP, but you don't have to upgrade if you don't want to. Running
Code:
# chmod 0701 /data/pts
should be sufficient to fix the problem. Then you should be able to run pts-shell from a regular (non-root) shell.
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes