I would find this more useful as a separate button, unless I could make a script to change the behavior mid-session. Still would be useful, though.

Hi @Quasic,
You should be able to use termux-reload-settings and sed to implement the script, but that may be awkward.
I've implemented a WIP UI-driven approach at Edontin/termux-app@1d277b2 (for now requires creating a new named session or pressing CTRL+ALT+O).
My preference is still toward having it as a property, since most tabbed terminal emulators default to this behaviour e.g. Konsole, Terminal.app, GNOME Terminal

Fairly easy was able to get this:

To reproduce:

1. mkdir ~/test
2. cd ~/test
3. Open new session and rm -rf ~/test.
4. Open new session.

GNOME terminal in this case opens $HOME.

@Edontin, thanks for trying the checkbox, but go ahead and focus on the basic feature, first. It looks like it just needs to check that the path exists before using it instead of home.

I don't want to complicate things. I do find it harder to cd home on the touchscreen keyboard, but it's not as bad as retyping or copy-pasting a path. I could always make an alias cdhome or something...

Hmm, the simplest solution would be to ensure that we aren't resolving the same path as the one we just checked and tried to canonicalize.
However, an alternative solution would be to call readlink via JNI and then verify that path exists before returning. Although, I'm not sure which you'd prefer? I believe that the former may be better due to the reduction in race conditions.

Also, cd without any parameters will return home.

@Edontin, wow, thanks, I can't believe I overlooked that. I also use DOS, (which prints the cwd when given no parameters.) So I learned to always supply a path for better consistency.

Use the simplest solution. I was speaking more generally. I almost edited my comment because I wasn't sure that was the exact check needed, but I figured you would know.

@xeffyr thanks for picking up that issue. I've just pushed a fix now.
I've also tested it with multiple levels of symlink indirection on Android 8.0.0 e.g.
mkdir test; ln -s test test2; ln -s test2 test3; cd test3
Removing ../test will result in the new session having the default cwd, otherwise using the original test directory.

It might be good to try to actually cd to the /proc/.../cwd for the current session's shell pid before opening the new session. I doubt it would matter in practice, but it's good to test the edge cases.

Just verified that this still canonicalizes the previous path, resolving all symlinks.

Within shell 1:

% mkdir test; cd test; cd /proc/11475/cwd
% pwd
/proc/11475/cwd

Within a new shell:

% pwd
/data/data/com.termux/files/home/test

Upon doing the same with the test directory removed, after the second cd, shell 2 goes to Termux's home.

Thanks, now it works fine.

@Edontin Thanks a lot, and sorry for the delay here!

Merged as e28be01, this is part of version 0.86 of the app which has now been released. This has the behaviour unconditionally - let's try that and add settings for opting in (or out) if necessary.

Oh no please. Why would you do something like this...
I thought it was some bug when I find the pwd of another session "leaks" to another session (and it seem to work "randomly" under some circumstances).

This is such a nasty "convenience" and the behavior is utterly unexpected. No offense but I really find this unacceptable. (A new session is supposed to be a new session and needing to "cd back to home" is essentially insane).

Please do not make this the default behavior. Please. Please. Please.

P.S. Seriously, I have never seen such behavior elsewhere. Not gnome-terminal. Not tmux. At the very least not as default. The only thing similar I ever saw I think is that you can open a terminal from nautilus (the GUI file manager of GNOME) that will have the same PWD as it does. (And that's hardly a relevant case...)

I agree with tomty89, this behavior (if I understand it correctly) is just kind of bizarre....

If I start a new session using the global Termux GUI, I expect the working directory to be something constant like $HOME.

If the new session is created via some special Termux shell command, then it might make sense for the initial working directory to be that of the command.

For the record, I don't think this even worths cramming the side bar with another button. If anyone thinks this even worth preserving, it should just be done via a configuration file option. (Well, or maybe the more menu. I wouldn't really like it though.)

P.S. Though doing it in the "open new session from here when I want" approach would makes more of a point than a generally "from last anyway" approach...

Hi @tomty89,

I thought it was some bug when I find the pwd of another session "leaks" to another session (and it seem to work "randomly" under some circumstances).

Could you please provide information about the circumstances for the random behaviour to occur?
Are symlinks involved?

P.S. Seriously, I have never seen such behavior elsewhere. Not gnome-terminal. Not tmux. At the very least not as default. The only thing similar I ever saw I think is that you can open a terminal from nautilus (the GUI file manager of GNOME) that will have the same PWD as it does. (And that's hardly a relevant case...)

The behaviour is similar to GNOME Terminal and Konsole's behaviour upon creating a new tab, to reduce the need to cd into deep directory structures.

I can see why it would be unpleasant if you're having to cd home regularly.

The opt-in/opt-out config approach would be the most straightforward to add.

The opt-in/opt-out config approach would be the most straightforward to add.

What about new button for context menu? E.g. "Open session in current directory".

@Edontin I am not really sure if it was really bugged. Maybe it merely seemed random to be because I didn't even imagined it could be a new "feature"/"convenience". Either way I am not really interested in investigating that as it's not really of my concern. It's not rational to me anyway.

Again, I've never seen gnome-terminal do that for either new tab or new window. My guess would be some shell "enhancement" you got somewhere. (And I am not interested in investigating that either.)

It's not really about what I find pleasant. The reason this should not be the behavior is because, it assumes that the most frequent workflow of most users is to open another session from where he last changed to, base on essentially no ground. And even more importantly, action like "open a new session" should have consistent behavior (that's the real reason why it should always open from home or any place one configured otherwise, instead of "we usually do things under home"), so that it is not biased and/or causes surprises.

It's not like I don't see why one would want that sometimes, but only doing it with a session-based menu button will make sense. (Otherwise it would be just a "stupid-convenience", if you know what I mean.)

While personally I don't find it really worth a menu slot in the more menu, it makes more sense than some static toggle. (If someone don't mind bothering, a menu from long pressing the session item is better place than the more menu I think. Actually I wouldn't mind the name setting being replaced entirely. But some users might.)

@xeffyr @tomty89

If it should be something the user toggles on or off, it may make sense to introduce a profile mechanism. This would allow sessions to be created with a profile, or a profile to be applied onto existing sessions. The user can, as a result, pick groups of settings, including whether to spawn new sessions in the current working directory.

The only thing that may be a little difficult, conceptually, is handling the Android context-stored preferences e.g. text size, keep screen on.

The way GNOME Terminal has implemented creating sessions within the working directory, depends on an override for the shell's status line, provided in vte.sh. This only supports zsh and bash, so I would imagine there are a lot of configurations which prevent it from working.

The only things that could make sense is that, a new session only inherits the working directory of a specific existing session when the user instructed it to upon its creation, and that we provides a quickest way for a user to tell the decision at that moment. Otherwise it would be just clumsy and stupid (definitely not the one in KISS). It's simply not a deterministic thing. (You don't always just want or not want it in a certain single workflow. That's not even the lifestyle of a robot.)

I have no idea why you even started talking about other preferences, just like I don't have the faintest why @fornwall merged this (and not even in the way you wanted it).

Can you even point us to anything concrete (a code/script line, a screenshot of a setting/toggle...) which shows that vte/gnome-terminal/bash itself (as in, whatever upstream ships) has anything even remotely related to what you have proposed? (Like, a line in https://github.com/GNOME/vte/blob/mainline/src/vte.sh.in.) While I don't think it really matters in what we should/need to do here, I don't want to feel like discussing someone else's dream.

Here are a few terminal emulators which implement the behaviour of keeping the shell's working directory and how they function:

• libvte - Reads escape sequences from vte.sh to determine the current working directory.
  • GNOME Terminal - A setting to control the behaviour appears to have been added in GNOME/gnome-terminal@79b2291. Starting in the shell's working dir has existed since v2.5.0. Previously, was always on.
  • XFCE4 Terminal - Working directory configurable via settings. Defaults to current working dir.
• Kitty - Configurable as user-defined shortcut (ad-hoc).
• Konsole - Has the ability to change whether to spawn in a directory or the working dir. Configured per terminal profile. Defaults to on.
• QTerminal - Configurable via settings. Defaults to off.
• iTerm2 (macOS) - Has the ability to change whether to spawn in a directory or the working dir. Configured per terminal profile. Defaults to off.

By no means is this a representative sample of all terminal emulators, but it does indicate that the behaviour is possible to find, in some form, generally being configurable via a preference.

As for profiles, both GNOME Terminal and Konsole implement profiles as a group of settings which affect a session. This solves the problem of managing multiple workflows by allowing the user to specify settings, such as defining whether new sessions inherit the current session's working directory. (Therefore, providing the mechanism you are describing for ad-hoc session creation in various working directories.)

Below is how Konsole allows you to spawn new tabs or windows with a profile:

In Konsole's case, if you spawn a new session, using a profile where the shell's working dir is reused, then the new session will use the same working directory.

Session profiles can also be switched at runtime, within Konsole:

GNOME Terminal implements profile configurations much like Konsole:

I would imagine profiles could be defined the following way in Termux:

termux.properties

# All unprefixed settings are applied to a 'default' profile,
# these values are inherited by all other profiles.
exampleKey = value

# Profile keys are defined as profile.<profile-id>.<key> 
profile.exampleProfile.name = Example Session Display Name
# When using 'exampleProfile', 'exampleKey' is overridden to contain
# value2, rather than value1.
profile.exampleProfile.exampleKey = value2

The only issue with this definition is that the Android Context values (why I mentioned them in my previous comment) may be difficult to associate with profiles, given that they are not stored alongside within termux.properties.

I am not sure why you bring in the the profile idea, or why you think it need to be implemented like that. Is it because even you don't always want this behaviour so you think there should be a "runtime" mechanism to change it? Why not a simple setting and/or a toggle button if we have the space.

The thing is, isn't the easiest way to have it on-demand a "new session from" button as I proposed? And with that it won't stupidly just inherit the PWD from the last session but any specfic session you want to target at a specific point.

And even from your list of examples, it doesn't seem like it's a "default behavior of most TE". Not in my experience with vanilla (i.e. no silly distro "preferred enhancements") GNOME 3 Terminal and tmux, etc. either.

I don't mind it being implemented in any form (as I would really rather just cd again when I need to), but there should really be a way to turn it off, and I strongly opposed it being the default (I hardly see its sense / how it could smooth up workflow in most of the time; also note that in Termux we do not have both "new terminal" and "new tab", but only "new session").

P.S. I guess it might never be your intention to have it as default / always on. In any case the above opinion merely addresses the current behaviour (or even, problem).