Hi,
ok, you can submit a bug report, it looks like this was unintentionally
broken along the way.
(we do use the windows style syntax for most stuff in our tests, so
sorry for the inconvenience)
regards
Armin
On 14.05.25 23:29, Koichi Murase via FreeRDP-devel wrote:
Hi,
I initially tried to submit a bug report on GitHub, but the template
told me not to submit questions. Actually, I'm not 100% sure whether
this is really a bug or an intentional behavior, so it implicitly
includes the question "Is this a bug"? Thus, I decided to post the
report here instead of GitHub. If this mailing list is not the place
to report it, I'd appreciate it if you could give me some guidance for
reporting.
To clarify first, I'm not a user of xfreerdp, but one of the
maintainers of the bash-completion framework, which provides a
command-line completion setting of xfreerdp for Bash. Therefore, I
must confess that I don't fully understand the usage and the
command-line syntax of xfreerdp, and also I'm not sure how to properly
test the behavior of xfreerdp. The question popped up in a discussion
in bash-completion [1]:
[1] https://github.com/scop/bash-completion/pull/1380
----
Here's the main part of the report:
In my understanding, the CLI command "xfreerdp" is supposed to accept
both forms of the options, the POSIX style (--long-option) and the
Windows style (/long-option) as described e.g. on the wiki page:
https://github.com/FreeRDP/FreeRDP/wiki/CommandLineInterface-(possibly-not-up-to-date%2C-check-application-help-text-for-most-up-to-date-version)
[...] Generally speaking, you can now use both --long-option or
/long-option.[...]
In fact, the command-line parser of xfreerdp seems to try to detect
the POSIX/Windows styles [2] and tries to parse the command line using
the corresponding "flags" [3].
[2]
https://github.com/FreeRDP/FreeRDP/blob/fa4d99ac5aad0a34f3ad609bf0f664b54cba1cd7/client/common/cmdline.c#L5483-L5486
[3]
https://github.com/FreeRDP/FreeRDP/blob/fa4d99ac5aad0a34f3ad609bf0f664b54cba1cd7/client/common/cmdline.c#L5518-L5521
However, some POSIX-style long options such as "--list kbd" does not
seem to be recognized.
$ xfreerdp /list:kbd
Keyboard Layouts
0x0000041C Albanian
[...snip...]
$ xfreerdp --list kbd
[06:25:52:109] [3581111:0036a4b7] [ERROR][com.winpr.commandline] -
[log_error]: Failed at index 1 [--list]: Unexpected keyword
Currently my guess for the cause is because for some options to report
the status, the command line is parsed again with a fixed
"flags=0x112" in the function
"freerdp_client_settings_command_line_status_print_ex" [4] where 0x112
does not contain COMMAND_LINE_SIGIL_DOUBLE_DASH (0x8).
[4]
https://github.com/FreeRDP/FreeRDP/blob/fa4d99ac5aad0a34f3ad609bf0f664b54cba1cd7/client/common/cmdline.c#L1797
This line was introduced in commit 30275e7a [5], but the associated PR
[6] and Issue [7] do not seem to intend to drop the support for the
POSIX-style of these status-report options.
[5]
https://github.com/FreeRDP/FreeRDP/commit/30275e7ac3eedf4db1b8fb1c0cb81f03e630ee8a.
[6] https://github.com/FreeRDP/FreeRDP/pull/5707
[7] https://github.com/FreeRDP/FreeRDP/issues/5695
Hence, my suspicion is that the support for the POSIX style of the
status-report options are unintentionally dropped while fixing the
issue [7]. Or was this an intentional change? Is this documented
somewhere? For consistency, I feel the POSIX-style should also be
supported for the status-report options, so let me report this in case
it was unintentional.
Thank you for your consideration.
Best regards,
Koichi
_______________________________________________
FreeRDP-devel mailing list
FreeRDP-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
_______________________________________________
FreeRDP-devel mailing list
FreeRDP-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
