{sourcepath} bug in 10.+?

Help & Support
1

{sourcepath} seems to be inserting a double-quote character before the trailing '/' character.

Here's what's happening to me. I'm trying to change the F3 to open FileLocatorPro when pressed. I had this working in DOpus v9 with this binding for F3:

"C:\Program Files\Mythicsoft\FileLocator Pro\FileLocatorPro.exe" -dw

... where the "dw" argument for FileLocatorPro was "current working dir", which DOpus honored. In DOpus v10+ this is not working so I changed my command to:

"C:\Program Files\Mythicsoft\FileLocator Pro\FileLocatorPro.exe" -d {sourcepath}

"-d" in FLP is a directory argument. {sourcepath} is being replaced with correct directory , but there is a double-quote character (") before the trailing '\' character. In DOpus, if I'm in the dir
C:\Program Files\7-Zip
and press F3, {sourcepath} expands to this instead:
C:\Program Files\7-Zip"\

Can someone verify this or report it as a big if it is, or help me if I'm doing something wrong? :slight_smile: Thanks.

2

UPDATE:

The bug only occurs when the path has a space in it. The path is correct when it doesn't have a space in it.

3

Just put quotes around {sourcepath}. That should fix it.

"C:\Program Files\Mythicsoft\FileLocator Pro\FileLocatorPro.exe" -d "{sourcepath}"

Regards, AB

4

I can't reproduce this.

5

I can't reproduce what you're seeing with the double-quote char being inserted into the {sourcepath} either...

To your original reason for going this route... in v9, Opus may have defaulted to using the 'current' path in calls to external apps, such that your apps -dw argument would have picked up on it. A change was made in v10 defaults to work more securely on Vista and Win7 by changing the default current directory to C:\Windows\System32... so, aside from the puzzling behavior you're seeing with the extra dbl-quote, you can do one of the following to revert back to using your old -dw argument:

1.) change your hotkey to run cd {sourcepath} before running the external app (two separate commands, each on it's own line in the Command Editor for your hotkey if you switch it to "Advanced" mode). This is probably the preferred way of doing it for this particular app - though I'm curious how this will behave considering the dbl-quote thing you're seeing when passing {sourcepath} directly to your app...
2.) you might change the Preferences option: Miscellaneous->Advanced->def_func_cd_sourcedir, and set it to True. This is the advanced option that globally changes the new behavior I mentioned in v10 back to v9 behavior.

6

Thank you, this first option worked. :slight_smile:

7

This is because of how most command-line programs treat \" at the end of a command-line argument. They turn it into a literal ".

Using {sourcepath|noterm} would solve it.

1 Like
8

That also works. Thanks to you and everyone else. :slight_smile:

9

Thanks for this simple trick. I had problems with 1by1 directory player to accept the active folder (Source Lister). My original command would open only some folders properly, not all, and i had been wondering why. This thread offers a wealth of alternatives to try and also explanations to fix the problem.

WORKED SOMETIMES ONLY:

C:\Programme\1by1\1by1.exe {sourcepath}

WORKS WITH EVERY FOLDER:

cd {sourcepath} "C:\Programme\1by1\1by1.exe" "{sourcepath}"
Thank you very much, very resourceful!! :thumbsup:

10

{sourcepath} is automatically quoted if it contains a space, so adding extra quotes around it is a bit weird. It may still fix the issue by pure luck, but may also behave strangely depending on whether or not the path has a space.

Using {sourcepath|noterm} is a safer bet.

11

I killed the first line and changed the original 2nd line to...

...and it works for the "problematic" folders too, so i'll leave it like that!

Nice bet, thanks leo :=)