"Open terminal here" working directory ignored (gnome-terminal)

[credmond]

JabRef version

5.9 (latest release)

Operating system

GNU / Linux

Details on version and operating system

Linux xxx-XPS-13-9360 5.19.0-42-generic #43~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Apr 21 16:51:08 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

Checked with the latest development build

• I made a backup of my libraries before testing the latest development version.
• I have tested the latest development version and the problem persists

Steps to reproduce the behaviour

1. Perform an "Open terminal here" on Linux
2. Note the working directory is not that of a library; it's your home directory

Bug

Look at org.jabref.gui.desktop.os.Linux, and note:

String[] cmd;
if (emulatorName.contains("gnome")) {
    cmd = new String[] {"gnome-terminal", "--working-directory=", absolutePath};
} else if (emulatorName.contains("xfce4")) {
    cmd = new String[] {"xfce4-terminal", "--working-directory=", absolutePath};
} else if (emulatorName.contains("konsole")) {
    cmd = new String[] {"konsole", "--workdir=", absolutePath};
} else {
    cmd = new String[] {emulatorName, absolutePath};
}

ProcessBuilder builder = new ProcessBuilder(cmd);

The problem is absolutePath (which is toString()'d) is handed is as an extra parameter, which leads to an unexpected version of the desired command.

It's hard to see this from Java debugging because if you dive right in and look at the byte array handed to the native method call ProcessImpl.forkAndExec() -- in your IDE for example -- it will look correct...e.g., "--working-directory=/whatever", because that's String's interpretation of it. But really, there's a 0 byte element in that array after the "=", which some native downstream code interprets as meaning "what's next is another parameter", and not a concatenation to the "=".

So what's really executed is this incorrect command:

gnome-terminal --working-directory= /whatever

Note the white-space. Very easy to reproduce this.

Fix

The fix is easy, do one of the following (obviously for the other shells too if applicable):

cmd = new String[] {"gnome-terminal", "--working-directory=" + absolutePath}; // concatonation, just one parameter

or...

cmd = new String[] {"gnome-terminal", "--working-directory", absolutePath}; // also accepted by gnome-terminal, no equals

Appendix

No response

[Siedlerchr]

Thanks for the investigation! I think the second option would be the better one, the one without the equals sign in case someone else takes a look at the code. Feel free to create a PR Regards Cormac Redmond ***@***.***> schrieb am So., 28. Mai 2023, 12:27:

…

JabRef version 5.9 (latest release) Operating system GNU / Linux Details on version and operating system Linux xxx-XPS-13-9360 5.19.0-42-generic #43 <#43>~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Apr 21 16:51:08 UTC 2 x86_64 x86_64 x86_64 GNU/Linux Checked with the latest development build - I made a backup of my libraries before testing the latest development version. - I have tested the latest development version and the problem persists Steps to reproduce the behaviour 1. Perform an "Open terminal here" on Linux 2. Note the working directory is not that of a library; it's your home directory Bug Look at org.jabref.gui.desktop.os.Linux, and note: String[] cmd; if (emulatorName.contains("gnome")) { cmd = new String[] {"gnome-terminal", "--working-directory=", absolutePath}; } else if (emulatorName.contains("xfce4")) { cmd = new String[] {"xfce4-terminal", "--working-directory=", absolutePath}; } else if (emulatorName.contains("konsole")) { cmd = new String[] {"konsole", "--workdir=", absolutePath}; } else { cmd = new String[] {emulatorName, absolutePath}; } ProcessBuilder builder = new ProcessBuilder(cmd); The problem is absolutePath (which is toString()'d) is handed is as an *extra* parameter, which leads to an unexpected version of the desired command. It's hard to see this from Java debugging because if you dive right in and look at the byte array handed to the native method call ProcessImpl.forkAndExec() -- in your IDE for example -- it will look correct...e.g., "--working-directory=/whatever", because that's String's interpretation of it. But really, there's a 0 byte element in that array after the "=", which some native downstream code interprets as meaning "another parameter", and not a concatenation on the the "=". So what's really executed is this incorrect command: gnome-terminal --working-directory= /whatever Note the white-space. Very easy to reproduce this. Fix The fix is easy, do one of the following (obviously for the other shells too if applicable): cmd = new String[] {"gnome-terminal", "--working-directory=" + absolutePath}; // concatonation, just one parameter or... cmd = new String[] {"gnome-terminal", "--working-directory", absolutePath}; // also accepted by gnome-terminal, no equals Appendix *No response* — Reply to this email directly, view it on GitHub <#9953>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACOFZCPVHDJSL4MLUCW72TXIMSCDANCNFSM6AAAAAAYRYEOW4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[credmond]

Ok, thanks -- I'll open a PR in the next day or so