Is that possible to have access to an option menu to have several sessions and set the font size, I would be happy to be able to set a smaller font to show more information or have possibility to remove the end message.
Thanks.
Oh, OK, it was well hidden. I never tried to do this since I read somewhere your terminal emulator were based on the Terminal Emulator from jackpal, so I tried to find the same features.
And waht about the end message, when you exit the shell?
By removing the end message, do you mean that you want to close the terminal directly when the session finishes?
Yes, this is what I mean. When I think about it, I'm sure you will tell me to edit the bash_logout file or something basic and obvious.
:). It's actually not possible to do at the moment - Termux always needs input to close a finished session.
The main reason for this is that a user may have broken his environment so that the session ends directly, in which case we do not want to close the app directly when trying to start a session, but instead leave it open with the error message visible and the ability to start a failsafe session by long-pressing on the New Session button.
There are to foolprof this, so leaving the issue open!
You could only show the message when the return code is not 0.
@Almtesh If the user adds exit to the .bashrc the return code will be 0. This leaves no way to fix the termux environment short of reinstalling the app or clearing the app data.
@fornwall I've been thinking of ways to solve this:
/sdcard/.termux_auto_close exists. This way users that really require this feature can create that file. If the user breaks his environment the file can be removed with an external file manager, since it's not in $HOME. @Neo-Oli indeed, I forgot about that.
And you're right, Termux misses a real setting screen, where you could set all the options, including default interpreter, for instance.
@Almtesh I like the current way of configuration a lot. A settings screen would only really work in this instance as an external app, since you want termux to exit when the last session exits. This would also leave you with no way of accessing the settings screen if your session always exits immediately. If the notification switch from my last example would just write into that file, all the settings could still be edited via the file, making it easier to synchronize or kickstart termux environment, because you can just symlink or copy the settings file to the directory and all the settings are set.
How about this: If the process terminates _itself_ with SIGHUP (signal 1), then close the terminal session without waiting for [Enter]. So the user could simply put
kill -s HUP $$
at the end of a widget script or of .bash_logout. (I guess it's a little unconventional for the process to communicate "loss of terminal" _to_ the terminal, instead of the other way around. OTOH that should mean it won't happen by accident in regular programs.)
I'd be very in favor for having a way to opt out of the [Process completed - press Enter to close] message. My idea (from issue #14) was to have an environment variable that would change this behavior. Something like TERMUX_AUTO_CLOSE=1 could be (1) set in a script on-demand or (2) set in a user's dotfiles so that it sticks. I'm not sure if this is a possible solution, but it would seem to hit a couple of important use cases.
One of the reasons I want it: I have a couple of "shortcut" scripts that I run from the Termux widget that pop up a dialog for input. After filling in the dialog and hitting "OK", I still have to wait for the rest of the script to finish and hit the enter key on my keyboard to close the Termux session. It would be nice to just fill in the dialog and then not have to interact anymore, at least in this situation.
@benjaminoakes The problem with your suggestion is that it could still cause a users environment to break. Normally when you have a broken environment you can still open a no-dotfiles sh session by long pressing the "New Session" in the left drawer and tapping "Failsafe".
As per your suggestion, if a User has the following two lines somewhere in hist .profile/.bashrc/.zshrc it would break his environment.
TERMUX_AUTO_CLOSE=1
exit
This would be leaving him unable to open a new session (because it closes straight away) and unable to launch a failsafe session (because the main termux app closes straight away). There is now no way to access the files in the $HOME directory with the only solution being clearing the App Data which could cause a user to loose valuable data.
But I do like your suggestion because it can be set on-demand. There just needs to be some kind of practical failsave and foolproof mechanism to fix a broken environment.
For me, the issue is closed.
It feels like we should maybe have an issue for the [Process completed - press Enter to close] discussion, either reopening this one or creating a new one.
An idea I just had: have two entries in the app drawer to start Termux (which I think you can do in Android). Normal "Termux" and "Termux Safe Mode". The latter wouldn't respect the value of TERMUX_AUTO_CLOSE so that a broken environment could be fixed if necessary.
I am reopening this issue because it has the most discussion and ideas about the Process completed message.
@Almtesh In case you closed the issue to stop receiving emails about it, you can click the Unsubscribe button on the right.
If a user breaks his session, he can still edit the file that broke it. No need to force termux to stay open when all it is doing is waiting for a user to press return.
@voidzero If the problem file is in the termux home driectory (something like .bash_profile) then you can not edit it without termux working, since only termux is allowed to access the termux home directory (without root). So a (unrooted) user can not edit the file that broke it. Keeping termux open allows such a user to access a failsafe session (longtap on new session), which starts sh without processing any user environment.
As this discussion is still going on, my solution to start a service on boot might be somewhat out of the box but it works for unrooted devices.
I am on MarshMallow, I use one of the many apps with monitor capability and option to start termux on boot, in my case it's automateit pro. As I am using the powerfull ZSH I just edited the zshrc and added
if [ -z "ps ax | grep -v grep | grep \/sshd" ] ;
then
echo "starting service SSHD" > $HOME/.sshdlog
sshd
fi
ignore the echo that was for testing purposes only. Works like a charm. The reason why I want the sshd available is simple, I have a phone with Google Apps and one without. As should you.
CU
Seems like no progress on this issue?
I've updated pull request #94, which implements this feature.
PR from rustybird still not merged, so issue is not resolved
I have a script to enter deep doze mode immediately( including turning off the screen), so I do not want the termux around after tapping the menu.
In this specific case, automatically closing termux is very useful.
Termux-widget catches all signals, now even
"kill -9 $$" at the end of script cannot terminate the process. any alternatives?
Edit: Now I put "killall com.termux" at the end of the script.
If you are simply interested in a quicker way to quit/exit than typing exit every time you wish to exit a session, add the following to your .bashrc
alias e='exit'
alias q='exit'
Do not forget to start a new session for the changes to take effect 🎈
torappinfo:
Edit: Now I put "killall com.termux" at the end of the script.
That works if you only have one shell running in termux.
I've whipped this "exit" one liner command together after seeing @torappinfo mention the killall method:
[ $(ps | grep -c '[b]in/bash') -eq 2 ] && killall com.termux || exit
It's not ideal but it works. It wont kill any other running panes. But if the current pane is the only one left it will stop termux without the enter problem.
One problem it has is that it will also kill any background things you have running. E.g sshd run from a task shortcut. You could tweak it to account for that though but probably not as a one liner. It will probably also have more issues. It's a pity the fix for this enter problem was never merged.
Im no expert but this is roughly how it works for anyone interested:
So all panes are killed if only 1 is left. Otherwise it simply runs exit.
The killall com.termux method doesn’t work on my Android 8.1, ps doesn’t show a com.termux process under the app's user. Haven't found an alternative yet.
hi I wanna to make the session to show more information or line there is any command to do this
for example : gem list -r
the termux show some of result
Found an alternative for my Android 8.1! As I said before killall com.termux didn't work because it doesn’t show up as a process.
My alternative is to kill the ppid of the shell. Something like kill `/system/bin/ps -p $$ -o ppid= | tr -d " \n"` will kill the parent process of the shell, presumably Termux. The parent doesn’t show on ps or /proc but we can still kill it. For it to work on subshells we need to find the top parent, like what I'm now using on my dotfiles repo.
Would a timeout be a solution? When there was a session with user input: close directly. When there was no user input, wait 15 seconds before closing while showing a cancel button (which cancels the closing).
@l-jonas
A timeout would be almost the same as the last suggestion in comment 8 by Neo-Oli.
A lingering notification would be nicer than a lingering window though IMO. Especially if it was as long as 15 seconds.
@fornwall have you had any ideas on how this should be achieved? ~/.shortcuts/tasks is great but won't do for user input or anything that needs to display more than snippets of information via toasts.
IMO the lingering notification or an additional shortcut for failsafe mode would be the most intuitive and least intrusive.
This thing have moved from a minor pain to a real flaw. Since upgrading my phone to Oreo termux no longer recognizes the enter key from my Samsung keyboard once I exit the session. It remains running with [Process completed - press Enter to close] and no way to close it short of shutdown or forcefully killing it using app settings. Galaxy S7 running Samsung keyboard. Oreo also seems to be causing a few other quirks with the keyboard, depending on which keyboard app is running. The quirks vary from minor to real PIAs.
Same problem as @ejaquay
I have two samsung devices with android 8 - I was considering migrating to terminux from another terminal program. Really liked termux, purchased the widgets addon. But then run into this. every time I try to exit a session, it gets stuck b/c there is no way to "Press Enter". And i couldn't find a way to kill all the stale terminals, they keep accumulating! it's bizarre
Please add a menu option to do this, or a way to kill a session that got stuck like this.
@goncalomb : is your solution working? I created a small script in ~/.shortcuts, like so
ssh user@some_ip -t 'someCommand; bash -l'
If the solution works, how could I integrate it into the script? thanks!
@arigit On my Nokia 8 with Android 8.1 I don't have that problem, I can press enter to close a terminal, but I don't like that specially when running scripts from the widget. On Android 6 you could put killall com.termux at the end of the scripts to kill Termux. For Android 8 kill `/system/bin/ps -p $$ -o ppid= | tr -d " \n"` works. Just put that at the end, because it kills the Termux app it also closes all the terminals.
If you want to kill Termux from a running shell, copy this kill-termux function to your .bashrc then you can run kill-termux to kill everything.
Try installing the Hacker's Keyboard, might fix with your Enter problem.
I wonder if we can at least implement an per-session exit button. Currently long-pressing on a session shows a pop-up for session name setting, where we can have the exit button. (Swipe-closing could be cool as well.)
Not having problem with the Enter key here either with the Xperia Chinese keyboard on Android O though. (The keyboard has always been a reason for me to have stuck with Xperias anyway <3)
Actually if the session is aware of whether all attached processes have gone already (which seems to be the case, judging by the strking through of the session index), perhaps we can even make short-press on such session as exit.
Thanks @goncalomb
I found a workaround to the Samsung / Oreo keyboard issue, so that the "enter" key can be pressed: activate the extended keyboard/"arrows" by long-pressing "Keyboard" in the side panel. Then enter "long text entry model" by swiping right-to-left on it. After entering this mode, the enter key becomes functional, for whatever reason :), even after exiting the mode and going back to the normal keyboard, the Enter key remains functional for as long as Termux remains open.
Ideally though, agreed with @tomty89 that have an "Exit" (or Terminate Session) option when long pressing on a session in the side pane would be best / is needed.
Exiting Termux from the notification panel works as well, and forces a termination however this terminates all active sessions. I couldn't find any way to terminate a specific session e.g. the stalled ones.
Since https://github.com/termux/termux-app/pull/793 was merged (but we still don't have a new release of Termux containing it) shouldn't this issue be closed? @xeffyr
This feature appears very useful for development, and I can also understand why a typical user who is not interested in development might want the exit code feature turned off when exiting a Termux session. A better solution might be one which only displays nonzero error codes:
if [[ "$RV" != 0 ]] ; then
printf "\\a\\e[0;32m%s %s \\a\\e[0m$versionid\\e[1;34m: \\a\\e[1;32m%s %s\\e[0m\\n\\n\\a\\e[0m" "${0##*/}" "$args" "(Exit Signal $RV)" "DONE 🏁 "
printf "\033]2; %s: %s %s \\007" "${0##*/} $args" "(Exit Signal $RV)" "DONE 🏁 "
fi
Referencing https://github.com/sdrausty/TermuxArch/blob/master/setupTermuxArch.sh#L530&&#L536 which only displays nonzero exit codes.
What is the option to turn displaying nonzero exit codes on? Can the user turn this option on and off?
@msdos I can't close this issue, but @Grimler91 or @fornwall can.
@xeffyr Don't you have admin rights on this repo? Which of the repos do you have admin rights on?
Which of the repos do you have admin rights on?
@Grimler91 In this: https://github.com/termux/x11-packages.
@sdrausty I recommend you to open another issue with your question.
I thought this issue was for discussing the removal of the process completed message?
The current commit is good and I like it. But I still want the full removal. Its just so much cleaner for oneshot scripts.
If that discussion is no longer to be here, then where should those still hoping for the proper removal go?
A better solution might be one which only displays nonzero error codes:
But I still want the full removal. Its just so much cleaner for oneshot scripts.
@cgarz I am just curious why you want nonzero exit codes hidden also.
@sdrausty I just want to be able to have scripts do a task then fully close. I'm not too bothered with the exit codes so far. But I thought the resistance to the full implementation argued that exit codes were insufficient to protect user error induced lockout.
An option that causes nonzero to always mean don't auto close is good too though.
I'm also following this issue hoping for a way to completely remove the process completed message.
I think the SIGHUP solution (referenced above) is the best: https://github.com/cvirostek/termux-app/commit/cfdddcca45ed062fc70f60f292e8808951914c88
A new option on termux.properties could be added to enable it.
Ultimately it all comes back to finding a way that doesn't lock the user and allows to start a failsafe session. Honestly I probably could lock myself right now by adding a killall to .bashrc. I don't think adding some solution based on signals increases the chance of a user lockout.
Also adding a shortcut (long press app icon, https://developer.android.com/guide/topics/ui/shortcuts/) to create failsafe session could also the a good addition.
Yes, this issue is really annoying. I made an analog volume control with the Termux Widget (see here). Every time I change the volume I have to confirm the massage.
@ChristophHeilmann I disabled it for secondary sessions here: https://github.com/termux/termux-app/pull/793 - but this will be available only on next termux-app version (v0.66).
It is not possible to completely disable it - Termux uses a custom environment which can be easily broken and prevent user from accessing his files, so we need to make user able to launch failsafe shell.
Thank you for the commit.
I'm not a developer. When the environment breaks I will install Termux once more. And I suppose that most of the Termux users will also be no developers. So it would be good if the user can decide if he needs a failsafe shell.
This could work for me. Any idea when 0.66 will be on google play store?
On Sat, Oct 6, 2018, 12:46 Leonid Plyushch notifications@github.com wrote:
@ChristophHeilmann https://github.com/ChristophHeilmann I disabled it
for secondary sessions here: #793
https://github.com/termux/termux-app/pull/793 - but this will be
available only on next termux-app version (v0.66).It is not possible to completely disable it - Termux uses a custom
environment which can be easily broken and prevent user from accessing his
files, so we need to make user able to launch failsafe shell.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/termux/termux-app/issues/56#issuecomment-427588574,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVFFNIs5j0Qd5vWL5-M8zvrMXGK0sQsXks5uiN5vgaJpZM4HeZCq
.
We definitely should have some way to fully close it programatically. Fear of locking out shouldn't be given so much priority in my opinion.
Especially since as things are now, you can already lock yourself out.
So a proper failsafe for full scripted closing would save anyone from the ways you can already lock yourself out.
There have been multiple ways suggested to achieve this safely:
Lingering notification
File on internal storage
Long press app shortcut
Separate failsafe app shortcut
So why are they never considered? Frankly If I had to choose between super safety and no full auto close, or no safety with full auto close, I'd choose no safety any day. As I'm sure many who have complained about this would.
I feel responsibility should be placed on the user to manage their environment properly. If they lock themselves out, and are unrooted. They are the one at fault, not Termux.
So perhaps if a proper safe method is too much work, we could have a quick and dirty option to opt in to the unsafe close with a stern disclaimer? Please? =D
I think the commit is important enough to release a new version of Termux.
@ChristophHeilmann Possible, that new Termux version is not released due to https://github.com/termux/termux-app/pull/650 (configurable extra keys overlay) - it introduce some changes that should be properly tested & improved if bugs found, e.g. https://github.com/termux/termux-app/pull/886.
What about these
Fear of locking out shouldn't be given so much priority in my opinion.
I had to choose between super safety and no full auto close, or no safety with full auto close, I'd choose no safety any day. As I'm sure many who have complained about this would.
I feel responsibility should be placed on the user to manage their environment properly. If they lock themselves out, and are unrooted.
So perhaps if a proper safe method is too much work, we could have a quick and dirty option to opt in to the unsafe close with a stern disclaimer? Please? =D
- I'm against completely disabling 'Failsafe shell' since there always should be way to access environment in case of script or binary failure. Termux is just like a PC in that case: if OS failed to boot, user can always perform recovery, access his data via live CD or just plugging hdd to something else...
If someone don't agree with that - feel free to fork Termux and introduce your changes, but only in fork =)
So current solution is only https://github.com/termux/termux-app/pull/793. All other solutions are subject for future since not every one is suitable for all supported Android versions.
I'm against completely disabling 'Failsafe shell' since there always should be way to access environment in case of script or binary failure. [...]
If someone don't agree with that [...]
Oh no I absolutely do agree that should be the recommended and default configuration. It's very sensible.
It's just that many people, including myself, have scripts that they would like to fire, interact and forget. (Interact since just fire and forget can be implemented in a ~/.shortcuts/tasks script.)
Ideally we would like a less intrusive way to launch the failsafe shell that doesn't get in the way of that, while keeping the failsafe accessible. Like some of the options discussed.
But there are many who have root and/or recovery who would be just as happy (and safe) with an option to disable it. Generally this power user group are the ones who on average are more likely to actually be the ones customizing things like .bashrc and/or fire, interact and forget scripts anyway.
Obviously not suitable for pure vanilla users hence why I said a stern disclaimer would be needed. It was more about it probably being much easier to implement than one of the nice, best of both worlds methods. And also about user choice. Even if for them its the choice to shoot themselves in the foot lol.
So current solution is only #793. All other solutions are subject for future since not every one is suitable for all supported Android versions.
I see. Is this why they have never been implemented? Could you elaborate on what problems some of them have?
[...] - feel free to fork Termux and introduce your changes, but only in fork =)
Regrettably I have no experience/skill in Android or even Java coding lol. My code also tends to be messy and ugly so Its probably best to leave Termux to the pros. If I had the skill I would go for a PR on one of the methods that give everyone what they want. But I didn't even know they would sometimes be version specific so its pretty above me =(
I only need the auto-close when invoking specific scripts from widgets, which I think is a common case. If Termux could distinguish between widget launches and direct launches and use that (hopefully with some setting) to fully exit when the shell terminates, that would solve the problem.
Another idea would be to have a timeout on the "press enter" prompt. Set a one-minute minimum if you're paranoid, but at least things would go away on their own.
Get to your sbin than hit mkfs -V
..lol
Hi! Until no fix released. previously I was add this line to .bash_logout:
[ $(ps -ef | grep -c '/system/bin/sh /data/data/com.termux') -eq 2 ] && killall "com.termux
it kills com.termux immediately if no other terminal opened.
But now i added line instead to automate input of Enter key:
nohup /system/bin/input keyevent 66 2> /dev/null&
Combination of these two lines may give temporary workaround.
i added line instead to automate input of Enter key:
nohup /system/bin/input keyevent 66 2> /dev/null&
Thanks for sharing, a great workaround. I'm now using this =D
However for me at least using input requires root. Which requires a little extra time to authorize from Magisk, leaving a little pause at the end of each session. Not ideal but a good compromise until a proper fix is created. Hopefully this issue can finally be put to rest soon though. Coming up on 3 years next month =S
Anyway the root change makes the command:
nohup su -c 'input keyevent 66' &>/dev/null &
I also changed the redirect to &> to silence both stdout and stderr. Otherwise nohup was creating a nohup.out file.
The kill command just kills the bash shell, which is a fine way to terminate the parent from a script if you need to, but I have my widgets exec a script so that there's no stray shell left over at the end.
As to using /system/bin/input to send the return key, it takes some work.
First, I have to set the path: export PATH=${PATH}:/system/bin
Then I get the error:
CANNOT LINK EXECUTABLE "app_process": cannot locate symbol "XzUnpacker_Construct" referenced by "/system/lib64/libunwind.so"...
Aborted
This is fixed by updating the library path:
export LD_LIBRARY_PATH=/system/lib64:$LD_LIBRARY_PATH
Now input keyevent 66 does send an extra return.
But the trick is to send that key after the shell has terminated. This line does that:
(sleep .1;input keyevent 66) & exit
This does not require root (I don't have it). I'm running the latest Termux from F-Droid on a Galaxy S8 if it makes any difference. Now I just need to add the three lines to the end of my widget scripts (on the success exit path), and I'm all good.
But does the key get sent correctly if I have the app running in the background?
Nope: sleep 15;(sleep .1;input keyevent 66) & exit and then switch to another app, and Termux won't exit. The good news is that the key doesn't get sent to the other app (I had the keyboard open editing a note when the timer ran out).
So this is a partial workaround, but there's still no solution if Termux is running a script in the background.
It seems for me, Termux nukes all child processes when a session ends. So it's essential to call input with nohup, and also give it some time to spawn, so nohup can trap and disable signals before Termux nukes it.
Additionally, input, and the tool it's calling weren't in my PATH. So here's what works for me:
export PATH="/system/bin:$PATH"
export LD_LIBRARY_PATH="/system/lib:$LD_LIBRARY_PATH"
nohup bash -c 'sleep 0.2; input keyevent 66' >/dev/null &
sleep 0.1 # give above time to spawn (?!?)
It's very unfortunate that such a simple feature requires ugly workarounds to make it possible at all.
Even with nohup it doesn't work if Termux is in the background.
Thanks @pcrow, importing does make it work without root. This has cut the uncomfortable delay slightly.
My. bash_logout is now:
export LD_LIBRARY_PATH=/system/lib:$LD_LIBRARY_PATH
export PATH=${PATH}:/system/bin
nohup input keyevent 66 &>/dev/null &
On another note, I don't know how I missed it, but this issue is closed?!
This issue is definitely not fixed. The best we ever got was less press enter, but the issue is clear though that we want ZERO press enter messages.
@grimler91 @fornwall @xeffyr can one of you please reopen this issue. It's still not fixed.
Well it took more than 3 years but it's finally a thing! :tada: :balloon: :confetti_ball:
Fixed via PR #1028.
Sorry if it's a silly question, but how exactly do I use this feature @cgarz ?
Well, https://github.com/termux/termux-widget/issues/9 is just what I needed!
[…] how exactly do I use this feature […]
It will automatically close sessions so long as the last exit code is 0 or 130 and Termux has been updated to v0.70 or above.
This is most useful in the case of scripts for Termux:Widget that are stored in ~/.shortcuts. As they can now run and be visible for feedback/interaction as usual. But then fully close in whatever way the user scripts without the press enter to close message halting a full close.
Scripts in ~/.shortcut/tasks keep the different behaviour of full background operation with no user interaction/feedback via the console available.
Most helpful comment
I'd be very in favor for having a way to opt out of the
[Process completed - press Enter to close]message. My idea (from issue #14) was to have an environment variable that would change this behavior. Something likeTERMUX_AUTO_CLOSE=1could be (1) set in a script on-demand or (2) set in a user's dotfiles so that it sticks. I'm not sure if this is a possible solution, but it would seem to hit a couple of important use cases.One of the reasons I want it: I have a couple of "shortcut" scripts that I run from the Termux widget that pop up a dialog for input. After filling in the dialog and hitting "OK", I still have to wait for the rest of the script to finish and hit the enter key on my keyboard to close the Termux session. It would be nice to just fill in the dialog and then not have to interact anymore, at least in this situation.