yashsingh1/xdaforums huggingface dataset:
[General Questions and Answers] alf_tux:
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!
[General Questions and Answers] alf_tux:
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?
[General Questions and Answers] icebox1701:
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.
[General Questions and Answers] alf_tux:
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.
[General Questions and Answers] tan-ce:
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.
[General Questions and Answers] tan-ce:
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.
[General Questions and Answers] 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.

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.
[General Questions and Answers] tan-ce:
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.

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.
[General Questions and Answers] 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.
[General Questions and Answers] alf_tux:
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.
[General Questions and Answers] tan-ce:
Oh yeah, I found the bug. Sorry, my bad. :o 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

# 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.
[General Questions and Answers] alf_tux:
I don't think that was the the bug:

u0_a68@manta:/ $ su

root@manta:/ # ls -l /data/pts

-rw------- root root 61 2013-08-28 19:09 passwd

srw-rw-rw- root root 2013-08-28 18:59 pts

root@manta:/ # chmod 0701 /data/pts

root@manta:/ # ls -l /data/pts

-rw------- root root 61 2013-08-28 19:09 passwd

srw-rw-rw- root root 2013-08-28 18:59 pts

root@manta:/ # ^D

u0_a68@manta:/ $ pts-shell /system/bin/sh

(pts-shell) /system/bin/sh

Could not connect to socket: Connection refused

255|u0_a68@manta:/ $

I have also tried:

chmod 0701 /data/pts/pts

And

chmod 0701 /data/pts/*

I'm getting the same connection refused. Maybe you can send me a debug version, I can run it just to find what is going on.
[General Questions and Answers] tan-ce:
That's strange. Could you show me the output of ls -la? (The "a" is needed to see the permissions for /data and /data/pts itself)

After that, perhaps you could try "chmod 0711 /data/pts"

There isn't a debug version. The error message comes from the part of the code which tries to open a unix socket located at /data/pts/pts. For this to work, /data and /data/pts must have the execute bit set, and /data/pts/pts needs to have the readable and writable bit set for you. Otherwise you'll get a "permission denied".

Perhaps it might be easier for me to just move the socket to /dev like what koush does for Superuser... it's possible the permissions on my /data is non-standard.

On a side note, I'm also currently trying to contribute to koush's Superuser project to fix terminal handling. With any luck, I (or someone else?) will succeed and we won't really need my pts-multi tools anymore.
[General Questions and Answers] alf_tux:
Yes, I agree that fixing su would be better.

I don't have my tablet right know, i don't remember well /data /data/pts and /data/pts/pts read and exec bits. I will see better whan I have my tablet with me.
[General Questions and Answers] alf_tux:
Here is the output:

/data:

drwxrwx--x system system 2013-08-28 18:59 data

/data/pts:

drwxr-xr-x root root 2013-08-28 19:06 pts

u0_a68@manta:/ $ ls -la /data/pts

-rwxrwxrwx root root 61 2013-08-28 19:09 passwd

srwxrwxrwx root root 2013-08-28 18:59 pts

u0_a68@manta:/ $ pts-shell /system/bin/sh

(pts-shell) /system/bin/sh

Could not connect to socket: Connection refused

255|u0_a68@manta:/ $

I suppose it isn't a permission problem.
[General Questions and Answers] tan-ce:
You're probably right, my Nexus 10 could be a bit different because of the semi-botched update I went through. Well, good news on two fronts: First, I updated pts-multi (latest update zip here) to use /dev/pts-daemon as the socket instead of /data... It works on mine, and I think it should work on yours, because Superuser puts its socket there too.

Second, I finished some modifications to the su binary in Superuser (source code here), and I've submitted a pull request to Koush. He says he'll do a code review of my changes, and we'll see how it goes. :)
[General Questions and Answers] alf_tux:
T/hanks! I tried your new update and I think it's working!

Can you add a passwordless option? Or if password is blank just don't ask for it
[General Questions and Answers] tan-ce:
Ok, but I took the easiest way out... If you set the environment variable PTS_AUTH, pts-shell will read the password from there instead of prompting you for it. So, if you're writing a script to spawn a root shell, do:

#!/system/bin/sh
export PTS_AUTH="your password here"
pts-shell /system/bin/sh

The latest update zip is here.
[General Questions and Answers] alf_tux:
Thanks a lot tan-ce!!

It's working just as I expected!
[General Questions and Answers] tan-ce:
Glad to hear it. :)
[General Questions and Answers] _RaZziel_:
Hi everybody,

I ran into the issue described here today when I noticed that elinks in my chroot'ed Ubuntu does not notice that I change to portrait on my SGH-T699 running 4.3, which it does on my G2 running 4.2. I did not yet try the solution suggested here mostly because I can't make do without my phone right now if something goes wrong.

My question is whether I understood correctly that I would have to use the provided pts-shell instead of the usual /bin/sh if I want to have proper line wrapping? Or do I only have to flash the provided zip-file and never think about it again? Sorry if that's a noob's question... Is any update for SuperSU in sight that addresses this problem?

Update: I tried it and it works like a charm. I just have one issue: I have a programme that spawns a terminal emulator session, but it definitely uses "su" to gain root. Can I somehow force the programme to use the proper command? Or alternatively: Can I spawn a shell in a directory that's not "/"? No matter where I execute "pts-shell /system/bin/sh" it alsways starts in root.

I'm thankful for any advice.
[General Questions and Answers] tan-ce:
I'm not completely sure what you mean, but if you're asking about launching a root terminal I can describe my own setup. I use Terminal Emulator (the one by Jack Palevich). In preferences there's a setting for "Initial command" which I set to run a "startup script". This script prints a menu asking me whether I want a regular shell, root busybox shell, or my Linux chroot. Then, for example, if I choose the root busybox shell, the script then launches another script via pts-shell which appends /system/xbin to $PATH, sets $HOME, sets $PS1, changes the directory, then exec's the busybox shell. I'm then dropped into a properly set up shell with minimum fuss.

Launching anything with pts-shell will give you a root shell, because that's what it was designed for. Non-root shells generally don't have the same issue. You should think of pts-shell as an su for interactive terminal sessions.
[General Questions and Answers] _RaZziel_:
Thanks for your answer. To clarify what I meant: I use the programme "complete linux installer" that provides images and startup scripts for a chroot'ed ubuntu (among others). It also provides a widget that automatically opens a new window in terminal emulator (I use the same one like you), gains root via su and then executes a script to correctly set all enviromental variables. But I could not force this widget to use pts-shell instead, at least not without decompiling and recompiling it which I never ever did. Instead I wanted to execute said script myself. But everytime I spawned a root shell via pts-shell, I ended up in "/", so I had to manually cd to where the script was, which was a bit annoying.

Your answer helped a lot because I will now just do as you do. I feel kind of stupid right now because I did not think about executing a script as initial command which then sets up everything, although I script a lot on my desktop... Anyway, thanks again.
[General Questions and Answers] tan-ce:
No problem. Additionally, earlier today I made a change to pts-shell and pts-daemon so that they preserve the current working directory. So this might solve your issue without even using scripts, or at least it would be one less thing for your scripts to worry about. I've already uploaded and linked the new update.zip.
[General Questions and Answers] _RaZziel_:
Strange, I flashed the new zip and got something similar to:

execv() not found

...

failed to bind to pts-deamon

...

and the given command wasn't executed. I then flashed the old one and pts-shell worked again, wds were not preserved of course. I wanted to post the error here and therefore flashed the new zip again and now it's working and preserving wds. Perfect!
[General Questions and Answers] tan-ce:
That's really strange... you got that message when running pts-shell?
[General Questions and Answers] _RaZziel_:
Sorry for the long time since my last post here, I was kind of busy preparing the final viva for my studies.

Anyway. I just did not manage tu run a script with pts-shell. It works perfectly as an interactive session with both bash and sh, although I always have to specify the absolute path for the binary, but I'm fine with that since the new shell then knows the correct $PATH.

But I tried many things like pts-shell script.sh, or pts-shell "bash script.sh", but I always get that execv... error which appears to indicate that the respective binary to be executed cannot be found. The script definitely has the executable bit set and the first line reads "#!/system/bin/bash". So I don't know what's wrong. Do you know how to execute a script with pts-shell like I usually can do by typing "bash script.sh"? I probably just did not see something very easy.

Best Regards

Torsten
[General Questions and Answers] tan-ce:
Well, pts-shell is not exactly like su - it doesn't use a shell interpreter to launch a command, and so it isn't like the system() call in C. As you can guess from the error messages, I use execv() to launch the application, so it doesn't do a few things you'd expect su to do. I think the correct way to run it would be to invoke bash on the script file, ie. "pts-shell /system/bin/bash script.sh".

It would be possible to make pts-daemon do the right things to launch scripts, but that would start to be moving into su's domain, and there are some security issues to look into. (eg. su does a bit of checking before launching anything as root.)

Is your script interactive, by the way? I'm asking because unless it has something which needs correct window size handling, su would be more appropriate.
[General Questions and Answers] _RaZziel_:
Thanks for your quick answer. Yes, my script is indeed interactive, it sets up a chroot'ed ubuntu and spawns a shell in the end. But I'm happy as is because specifying the absolute path for both bash and the script did the trick. I however had to put "" around the two arguments, otherwise nothing happens until I ^C the shell. I only use pts-shell for things that need to be interactive, otherwise su is good.

Thanks for the help.
[General Questions and Answers] tan-ce:
Perhaps when I have time I can create a new frontend that behaves a lot more like su, or at least will make it less cumbersome to use. I didn't think about this earlier because in my use-case, my chroot is prep-ed and launched from menu driven script, so I always run pts-shell from scripts.

PS: I was just checking the scripts I use to launch my chroot and I noticed something strange - my invocation to pts-shell is

exec /system/xbin/pts-shell /absolute/path/to/a/script

which means execv should properly run a script if given the absolute path to a script. Have you tried "pts-shell /absolute/path/to/script"? Re-reading your previous post, it wasn't clear whether you've tried this, besides the relative paths to the scripts.
[General Questions and Answers] _RaZziel_:
I tried what you suggested but the only way I can get the script to be executed properly is exactly as I described earlier.

When trying:

pts-shell /sdcard/ubuntu.sh

I get at the point where the script created the loop-device

(pts-shell) /sdcard/ubuntu.sh
Failed to execv(): Permission denied
Initializing daemon
Attempting to bind to /dev/pts-daemon
Entering main loop
[26010] Starting service loop
Warning: pts_exec failed

pts-shell exited

which I also get when specifying the absolute path for pts-shell. Since exec only make the script being executed in the same shell, it does not change the result. The first line of the script reads

#!/system/xbin/bash

so I don't understand why pts-shell seems to be capable of running scripts without specifying the executing shell in your case but not in mine. Anyway, thanks to the power of bash functions and aliases, I changed my .bashrc so that I can use the terminal comfortably so I can perfectly well life with the current state.

I also noticed that I am unable to change any permissions irrespective of whether I got root via su or pts-shell. For instance

localhost ~ # ll ubuntu.sh
-rw-rw-r-- 1 root sdcard_r 8315 Oct 16 13:23 ubuntu.sh
localhost ~ # chmod 0777 ubuntu.sh
localhost ~ # echo $?
0
localhost ~ # ll ubuntu.sh
-rw-rw-r-- 1 root sdcard_r 8315 Oct 16 13:23 ubuntu.sh

Maybe that's related but I don't know. To change any permissions I need to boot into recovery and access the phone via adb because somehow I can't access the phone via adb when normally booted (it's a Samsung one,maybe that's why). Even when giving root-rights to adb, I get

razziel@RaZzPCLinux ~ $ sudo adb devices
[sudo] password for razziel:
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
40079347	offline

Sorry for the lengthy post...
[General Questions and Answers] tan-ce:
Ah... your scripts are on sdcard. Yes, you are right, it's related. On internal and external storage, the filesystem is mounted in such a way so that the execute bit can never be set. And if the execute bit is not set, none of the system calls will allow you to execute the file. I put my scripts and custom apps (eg. custom busybox) in /system/user_bin, because /system allows the execute bit to be set. It's normally mounted read-only, so you'll have to use

mount -o remount,rw /system

as root to make it writable. To make it read-only again, either restart your device or do

mount -o remount,ro /system

Hopefully this helps.

New versions of Android do not just trust any adb client that tries to connect to it, regardless of whether via TCP/IP or USB cable. Perhaps your version of adb is outdated. If you upgrade it to the latest version, what should happen when you plug it in is that your device will popup a message saying a PC wants debug access to your phone. It'll show you ADB's public key on the PC, and you'll be given the option to allow or disallow debugging access.

It's good, more like SSH with public keys now. I can leave USB debugging on and not worry some rouge PC will try to contaminate my device when I'm charging or doing MTP transfers.
[General Questions and Answers] _RaZziel_:
Thanks, that was exactly it. The version of adb I used on that computer is incredibly old (haven't used it in a while). Updating it helped.

I did not want to put my scripts anywhere where they'll get overwritten once I flash a new rom, which I do rather often (which would be the case for /system, if I'm not mistaken). But I can live with the current state. Now I only have to find out why some programmes that use ncurses (such as cmus, ncmpcpp) look great but others (elinks or the raspberry pi config script) do not render properly, but that has nothing to do with pts-shell as it also happens during normal ssh-sessions not started as root. My terminal emulator is probably misconfigured.
[General Questions and Answers] tan-ce:
Glad to hear your adb's working fine now.

Actually, I think if you install your ROMs via update.zip, it only replaces "well known" directories under /system such as /system/bin and /system/xbin. I remembered a long time ago when I was trying out ROMs on my Desire-Z, files were left over after each install. But then again, I'm not 100% sure, and things may have changed since then. If you install your ROMs by flashing via fastboot, though, that will definitely wipe out anything pre-existing in /system.

Good luck with your remaining terminal apps. If you figure out what's wrong with those other apps, do post it here.
[General Questions and Answers] _RaZziel_:
Since it's working without the executable bit, I leave it just the way it is (though it's good to know that the file being on the sdcard is the reason).

But it's probaly still as you said, that is, only well known files are overwritten. At least I remember people saying I had to manually format /system before upgrading to cm10.2 from stock on my galaxy s relay.

Anyway. I figured out what was wrong with the other terminal apps. Actually is was the terminal emulator on my phone which was stupidly not set to "default to utf-8". Now that that option is set, all ncurses programms run fine whether they're local or remote ones via ssh.

Sidenote: You just reminded me of my desire z (wifi's broken for some reason) that's lying around waiting to be tinkered with.
[General Questions and Answers] tan-ce:
Did you know there's an unofficial port of CM10.1 for the Desire-Z? Breathed new life into my old phone. It's now my backup phone.