SUMMARY When launching an application via right-click -> "Open Folder With", it will be launched with a working directory that is not the selected folder, but rather its parent folder. This leads to various applications not opening the expected folder. STEPS TO REPRODUCE 1. Open the Menu Editor and create a new application entry with Program: sh Command-Line Arguments: -c "notify-send $(pwd)" (This will launch a shell script that reads the current working directory and outputs it via a desktop notification.) 2. Open Dolphin and navigate to your home-directory. 3. Right-click into empty space and select "Open Folder With" -> "Other Application..." 4. Select your previously created application entry. OBSERVED RESULT The notification shows a working directory of "/home". EXPECTED RESULT The notification should show a working directory of "/home/username". SOFTWARE/OS VERSIONS Linux distribution: openSUSE Tumbleweed 20221126 KDE Plasma Version: 5.26.3 KDE Frameworks Version: 5.100.0 Qt Version: 5.15.7 ADDITIONAL INFORMATION - It behaves similarly when you right-click on a folder instead of empty space. It also behaves this way in the Folder View desktop widget. - When an application entry specifies "%u" in its command-line arguments, that parameter is populated correctly, which is why e.g. Filelight or Dolphin do open the correct folder. - I can also reproduce this in Kubuntu 20.04.5 (Plasma 5.18.8, Frameworks 5.68.0, Qt 5.12.8). This behavior might be quite old. - I could imagine this bug being as simple as the "Open With" logic always assuming that it's opening a file, because the working directory for a file would be its parent folder.
I can confirm the behavior. Relevant line is https://invent.kde.org/frameworks/kio/-/blob/master/src/gui/kprocessrunner.cpp#L139. It uses the URL minus the file name as working dir. That said I'm not sure how much of a bug this is. > This leads to various applications not opening the expected folder. What applications exactly? Any app that expects a file/folder URL to be passed really should define a placeholder for it
Thanks for looking into this. > That said I'm not sure how much of a bug this is. > What applications exactly? Any app that expects a file/folder URL to be passed really should define a placeholder for it I just tested it again, and realized that the correct path is passed as the first parameter, even without the %u placeholder. During my initial testing, I thought users would need to know that %u syntax to get the correct path, which I did not know for quite some time. So, then it is only really relevant for quick-and-dirty scripts which work directly within the working directory. And I guess, one could expect users to grab the directory in their scripts from $1, if they want to use them in .desktop-files for processing directories. My personal intuition would still be to fix it, just to eradicate the possibility of unexpected behavior, but I understand that this is a breaking change for whoever might be relying on this unusual behavior.