GNOME Bugzilla – Bug 748293
cwd should be respected for custom commands
Last modified: 2020-04-01 10:49:45 UTC
This bug is essentially requesting the revert of https://git.gnome.org/browse/gnome-terminal/commit/?id=fc68d2735f8804d3c5d0d40635a27989727c3f9b (or adding some other workaround). I'm not sure what the logic for this change was (and there is no linked bug report with background information) but this breaks my use case. In particular, I have a terminal that runs 'jhbuild shell' as a custom command. When I open a new window of that, I want it to be in the same directory as the old window, just as much as a normal shell.
I totally agree. Chpe?
I don't agree, obviously :-) since I made that change. The 'cwd' is just a string that the running terminal application has sent us, so using it for the pwd of the new tab might be insecure if the command isn't a shell. I've thought about allowing this if the custom command is a shell (as defined by /etc/shells), but that wouldn't help with your case… maybe need a pref? Also, has something changed recently that exposed this problem for you? This commit has been in since before 3.8.0…
> I don't agree, obviously :-) since I made that change. The 'cwd' is just a > string that the running terminal application has sent us, so using it for > the pwd of the new tab might be insecure if the command isn't a shell. So are you worried about security-like issue? E.g. a malicious app emitting this escape seq causing you to open a new tab in an undesired directory? Well, on one hand, it might equally happen if the terminal launches a shell; who knows what commands you start from that shell. On the other hand, the worst that can happen is that you recognize the new tab is not in the directory you wished for. > I've > thought about allowing this if the custom command is a shell (as defined by > /etc/shells), but that wouldn't help with your case… maybe need a pref? Shells are not the only apps that can benefit from the new way of setting the cwd. That's one of the greatest advantages over the old method, at least for me. E.g. I use my mc with a relevant patch (https://www.midnight-commander.org/ticket/3088), and it's reasonable for each file manager to also tell the directory to the terminal. The current UI option tells g-t to launch something other than the shell; but there's absolutely no sign that the behavior will differ in other aspects too, and it's really counterintuitive. IMO it's way too insignificant issue to have a pref (even if it's in dconf only without UI), and it'd be hard to understand. > Also, has something changed recently that exposed this problem for you? This > commit has been in since before 3.8.0… I don't have any profile with a "custom command". If I had, e.g. with mc, I'd wish to see Ryan's preferred behavior. (Also: even if the custom app doesn't change the directory, I'd like that to be preserved when I open yet another tab from there.) It's not new that we keep discovering bugs that have been in g-t since 3.8 or even way before that :P
I'd be fine with a pref that lets you set the initial working dir. There'd probably be a three-state chooser: previous tab's dir, home dir, or custom with a text entry for the path. But it should be independent from whether a custom command is run. There's plenty of room on the Command tab of profile prefs to implement this.
I guess I mixed up the old and the new tabs (which ones has a custom command). In certain situations (e.g. when the "custom app" is something that seldom uses the cwd, e.g. a web browser which offers to save files in cwd by default, or just coredumps there if crashes :)) running it from the home dir is probably better. In some others (e.g. when the "custom app" is a file manager) inheriting the cwd might be preferred.
(In reply to Christian Persch from comment #2) > Also, has something changed recently that exposed this problem for you? This > commit has been in since before 3.8.0… Nothing has changed. It has been bothering me for a long time but I didn't file a bug about it until now.
This seems to be a duplicate of bug #706927.
Let's use the other bug since it has patches attached to it. *** This bug has been marked as a duplicate of bug 706927 ***
Not a duplicate. Bug 706927 is just a bug, while this is more a design issue.
I'm not sure about the security risks of copying the working directory from one tab to another, but I find it hard to justify ignoring the `--working-directory` argument just because the default profile has a custom command (regardless of whether it's a shell or not). I'm using a .desktop file launching a terminal with 4 tabs, each with its own working directory. I was quite surprised when I set fish as a custom command and all my tabs started up in the home directory.
Created attachment 327540 [details] [review] screen: Add settings for initial working directory I'm attaching two patches to implement the suggestions from comment #4. I've also added a "default" setting which preserves the current behavior of only inheriting the working directory if no custom command is specified. Changing this setting to "inherit" also fixes Bug 706927.
Created attachment 327541 [details] [review] profile: Expose settings for initial working directory
Review of attachment 327540 [details] [review]: This patch looks good, and it would fix the issue for me. as an aside: I think it's particularly weird that we ignore working directory in non-OSC7 cases. The original change was made because we might be receiving escapes from non-trusted programs, but in the case that the user specifies the working directory explicitly (for example, on the commandline), we should *always* honour that. Perhaps it makes more sense to do the filtering in terminal_screen_get_current_dir() or even in action_new_terminal_cb() in terminal-window.c. ::: src/org.gnome.Terminal.gschema.xml @@ +247,3 @@ + <default>'default'</default> + <summary>Whether to inherit the working directory or use a fixed one</summary> + <description>Possible values are "default" to use "home" for custom commands and "inherit without custom commands, "inherit" to inherit the working directory from other tabs or nautilus when launched this way, "home" to set the working directory to the home directory, and "custom" to specify a custom working directory</description> You have an unbalanced quote here around "inherit
Does this fix #706927? There's even a stackexchange thread about it: https://unix.stackexchange.com/questions/346008/nautilus-open-folder-in-terminal-when-using-tmux
(In reply to Yury Bulka from comment #14) > Does this fix #706927? If you change the 'working-directory-policy' setting that my patch introduces to 'inherit' in the profile, then yes, that should fix bug 706927. But I'm not sure if the patch is the preferred solution for this problem or if one of Allison's suggestions would be a better approach here. It would be nice to get a comment from the terminal developers about this.
Isn't this a duplicate of https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/126 Now that the issue was addressed by commit 79b2291b12cfa106149437d63394deddddbc7dca, shouldn't this bug be closed?