Created attachment 168859 [details] 5 screenshots showing the problem and a workaround SUMMARY When typing brackets in the launch configuration arguments, these bracket characters are ignored when executing that launch configuration (likely linked to Bug 324830 which didn't describe the issue properly). However, they are used for filtering automated test cases with the popular catch2 v3 library. STEPS TO REPRODUCE 1. create launch configuration that uses square brackets, eg. "[capitalize]" (see screenshots) 2. select this launch configuration as current launch configuration and execute it OBSERVED RESULT the square brackets are silently removed from the argument; the run window shows the argument without the brackets, eg. "/home/gerald/repos/github/cpp/c_strings_solutions/build> /home/gerald/repos/github/cpp/c_strings_solutions/build/c_strings_test capitalize" when the argument was set to "[capitalize]". This means that filtering test cases by tags using the catch2 library is not possible without a workaround. EXPECTED RESULT The execution gets the full string passed into the arguments field. All characters in the text field are passed 1:1. SOFTWARE/OS VERSIONS Linux/KDE Plasma: kubuntu 23.10 with all updates but no backports (available in About System) KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION As a workaround, it is possible to escape the brackets with a "\", then they are passed (however, the backlash is hence not passed as argument);
I was able to reproduce the problem with version: 5.13.240202 , however the run window shows: *** Failed to specify program to start: ***
I think the user is responsible for quoting or escaping problematic arguments manually. If KDevelop quotes the string automatically, passing multiple arguments becomes impossible. If KDevelop escapes special characters automatically, quoted or already escaped arguments in existing user configurations would break.
True that existing configurations that work around the problem would break by fixing this issue. Not sure how many people this would affect. For new users, the current behavior is misleading as they're defining cli arguments and should be able to presume that they are passed to the cli as if they were typed in a konsole window. A possible alternative to using the argument text input as a raw string would be to add a proper help message telling the user which characters require escaping.
launch_window.png shows the argument as capitalize, without square brackets. Is this a screenshot mistake? Is escaping the only working solution or does quoting the argument work too? (In reply to Gerald Senarclens de Grancy from comment #3) > A possible alternative to using the argument text input as a raw string > would be to add a proper help message telling the user which characters > require escaping. Feel free to implement the help message (as a tooltip perhaps) and create a merge request at https://invent.kde.org/kdevelop/kdevelop/-/merge_requests
Just tested: quoting works as well as escaping, so the issue is not too bad. Perhaps the UI should show an error message earlier - before the user attempts to actually run the program, because the problem is localized in the value of the Arguments line edit. The relevant code was implemented in 2009 by https://commits.kde.org/kdevelop/fd240820495a98ff30b61af3476e0e5bc6fcd606. The code currently resides in https://invent.kde.org/kdevelop/kdevelop/-/blob/c8417fc2baf2ecba70e7e2b474fa2d00b1970265/plugins/execute/executeplugin.cpp#L62. The job of splitting arguments is fully delegated to KShell::splitArgs(cmd, KShell::TildeExpand | KShell::AbortOnMeta, err). Its documentation: https://api.kde.org/frameworks/kcoreaddons/html/namespaceKShell.html#a2af8a3c7f2b485868a1169f4de07a050. The documentation for the AbortOnMeta flag suggests it is the culprit, and indeed removing the flag makes unquoted and unescaped square brackets work. I don't know whether removing this flag is going to break something else though. Needs a more detailed analysis and careful testing.
Thanks for your investigation Igor! When vacation time starts I'll have another look and will attempt a MR if I can up with a reasonable improvement.