Thanks! Will look into this and try it out.

rebased against current master

Should I improve something in this pull request? For example, I could remove the Simplify removeFinishedSession() commit if you think it does not belong here.

(FWIW, no bugs so far in my daily usage.)

@rustybird Sorry for the delay in feedback!

I'm not sure what the best course of action is here. After talking with some people using the app, perhaps it's best just to close sessions automatically on exit code 0, and let everything else (other exit codes and signals) cause the current behaviour where Enter is needed to proceed.

The rare case where someone messes up the startup (as in exit 0 in ~/.profile) could be handled by having a separate shortcut to a failsafe session.

What do you (and others) think about that?

To be honest, tapping enter just isn't that big of a deal.

It might be worth skipping enter for ~/.shortcuts (perhaps a termux specific commandfor scripts) but again, I just don't find it that troublesome..

@fornwall:

After talking with some people using the app, perhaps it's best just to close sessions automatically on exit code 0, and let everything else (other exit codes and signals) cause the current behaviour where Enter is needed to proceed.

Sounds good to me, closing on exit status 0 is more intuitive than SIGHUP for sure. Should I push an updated commit?

The rare case where someone messes up the startup (as in exit 0 in ~/.profile) could be handled by having a separate shortcut to a failsafe session.

Maybe a double tap (or some other gesture) on Termux widgets?

Love termux but find having to press Enter after pressing ^D annoying. On any unix like system users can break their accounts with buggy init files and a dozen other ways, With termux there is no admin to save users from their mistakes but pretty much anything a user can do to screw up his environment (buggy .profile, .bashrc, etc) can be fixed by either clearing termux data or re-installing it. I would add an option in termux.properties to disable the prompt for Enter and advise users to periodically backup their work, maybe even provide a pair of scripts to do backup/restore to/from shared storage. The restore script could also rename termux.properties as additional protection.

I think the best approach would be an option in tasker that can be switched on/off by the user. Maybe a check box in the long-press menu? If the user's profile is somehow corrupted or messed up, it can always be fixed by editing the files using another app or adb.

I agree that if your just casually using termux pressing enter is no big deal.

I am not however. I have it as an ssh server itself and a remote task starter for my server at home. Using the .shortcut folder and widgets.

I have a large list of shortcuts and I often have to press a few.

Since it can't be closed programmatically I either have to:
Activate the shortcuts one by one. Which is painfully slow.
or:
tab out and press the next while the others are running. Creating a situation where I have to go back later and press enter sometimes as many as 10 times in a row.

Sheltering noobs is fine. But not at the expense of encumbering those who could easily fix simple problems like a bad .bashrc config.

I think any solution to this would make this already versatile and fantastic app much better.

IMO The seperate failsafe shortcut idea sounds the most noob friendly.

Maybe this should be configurable in the ~/.termux/termux.properties file.

@fornwall any resolution on this?

Just found out you can put items in ~/.shortcuts/tasks/ and then they won't open the terminal at all. Awesome!

@alexlance is right. No more enter spamming! yey! Thanks for sharing :-) The shortcut widget prefixes the shortcut with task/ so some of my shortcut names are a little truncated. And the Termux window doesn't show at all so any info you might want to display while the shortcut is running will need to be changed to toasts. Really happy with this regardless. Would still like to have the window show with a no enter needed option as well though. For long messages toasts aren't ideal.

Further tested the .shortcut/tasks method - since termux doesn't show at all any script that needs user input via read command or similar won't work. Just realized when testing my home light control script which runs a script on my server via ssh and has a menu using the read command. So still stuck with press enter in this case.

The rare case where someone messes up the startup (as in exit 0 in ~/.profile) could be handled by having a separate shortcut to a failsafe session.

There's always ways to break things. kill $(cut -d' ' -f4 /proc/$$/stat) (kill parent of current process; written this way because this busybox's ps does not seem to do -p) is a way to just kill the entire termux app on startup, and I don't see a way to recover from having that in shell initialization, aside from a separate failsafe shortcut.

Very good point. I was also going to suggest a separate failsafe shortcut, or some way to start the app in "failsafe" mode.

Also i'd like to point out that the majority of termux users will be using a rooted device, so in this case it's always possible to remove the offending/broken script without losing any other data. So the "broken beyond repair" argument really only applies to the small minority of non-rooted ROM's or devices, which tbh i don't understand why such users would be using termux in the first place.

Plus, waiting for Enter before closing the window/session just shows you (in some cases) what's going on, and doesn't really accomplish anything in terms of fixing it.

@delt01 the waiting for enter enables you to open the left drawer and open a failsafe session by long-pressing "new session", so it at least enables you to fix the problem (without root).
But I agree that a separate failsafe shortcut would be nice instead.

As a side note, I think termux has lots of uses even without root. I seldom use root even though my devices are rooted.

I'm closing this. Anyone still interested: Feel free to take the code, rebase it on master again, and open a new pull request.