"Open console" with custom command seems to pass %DIR argument wrongly

[geekoverdose]

JabRef 5.0-dev, JabRef--master--latest.jar from 2019.03.23

• [ x] I have tested the latest development version from http://builds.jabref.org/master/ and the problem persists

System details: Arch Linux, i3 window manager, no desktop environment. Java version:

java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

When using a custom command for "open terminal" the %DIR argument seems to be passed wrongly to the executed command. I've tested this with the following two configurations for the "Execute command" field for "Open console" in the settings, with details stated below:

A) "terminator --working-directory=%DIR"
B) "thunar %DIR"

A) is fault tolerant, hence also opens if the argument passed after the option is invalid. As a result, the terminal window is opened in the home directory, which is default with Terminator on my system. The interesting thing is that JabRef logs the correct commands to the logs:

INFO  org.jabref.gui.desktop.JabRefDesktop - Executing command "terminator --working-directory=/correct/path/to/library/directory"

When executing this command that JabRef logs outside JabRef in another terminal it correctly opens Terminator at the specified location.

B) is purely for debugging, as Thunar is not fault tolerant here. Thunar reports this error in a UI popup:

Error when getting information for file "/path/to/jabref-master-latest-directory/
%DIR": No such file or directory.

"/path/to/jabref-master-latest-directory/" in the directory where the nightly build of JabRef (JabRef--master--latest.jar) is located. The funny detail is that JabRef logs the correct command here too:

INFO  org.jabref.gui.desktop.JabRefDesktop - Executing command "thunar /correct/path/to/library/directory"...

Hence, the log of JabRef differs from what Thunar seems to get as an argument from JabRef. If the logged command is executed outside JabRef. it again correctly opens Thunar at the specified location. Seems that something causes the log to be different from what actually is passed to the specified external program.

Steps to reproduce the behavior:

1. In case the bug is Linux related: use JabRef on a Linux system.
2. Configure the command to be used for "open terminal" to one of options A) or B) above and have the corresponding software installed (Terminator, Thunar) on your system.
3. In any opened library in JabRef execute "open terminal" --> logs correct command, seems to execute different command.

[deepakkumar96]

Okay So, I looked into "open console" code so the issue here is:

1. While logging command, the code does replace %DIR with the actual path,
2. But while actually executing the command, the code does not replace %DIR with the actual path.
   (so the command is executed as it is, provided by the use)

As you can see this in code below:

if (!command.isEmpty()) {
                command = command.replaceAll("\\s+", " "); // normalize white spaces
                String[] subcommands = command.split(" ");

                // replace the placeholder if used
                String commandLoggingText = command.replace("%DIR", absolutePath);

                JabRefGUI.getMainFrame().output(Localization.lang("Executing command \"%0\"...", commandLoggingText));
                LOGGER.info("Executing command \"" + commandLoggingText + "\"...");

                try {
                   new ProcessBuilder(subcommands).start();
                } catch (IOException exception) {

Here variable 'commandLoggingText' is getting used only for logging purpose not for executing.
while this variable 'subcommand' (which is getting executed) still contains %DIR instead of the actual path.

jabref/src/main/java/org/jabref/gui/desktop/JabRefDesktop.java

Line 246 in 6c61664

new ProcessBuilder(subcommands).start();

[deepakkumar96]

I'll work on this issue whenever I get time.

[geekoverdose]

@deepakkumar96 Thanks, the code explains the issue well. My suggestion would be to do the %DIR replacement directly after whitespace normalization, before anything is "split" towards logging or execution.

[Siedlerchr]

Fixed by 3d770b8

[geekoverdose]

I can confirm, this successfully solved the issue. Good work again!