Hi, Yes, the command-line interface has been completely changed. There are reasons for this, such as the fact that the old syntax was very inefficient and not flexible enough. I did some research on existing command-line syntaxes, their strengths and weaknesses, and came to the conclusion that the most efficient syntax in our case would be the syntax which is more "windows-style" with / and +/- for enable/disable. The +/- option is very practical, but requires that - does not mean something other than minus.
I have worked on a generic command-line parser that accepts a variety of command-line syntaxes. It would therefore be possible to work on adding support for a more "linux-style" command-line interface as an alternative syntax if there are some of you who really like to type longer commands. Trust me, it does look weird, but there is definitely a gain in how commands are shorter in the end. Some users on IRC seem to like it better once they've come over the fact that this is a more of a windows-style syntax. I have based my command-line parser based on this article: https://pythonconquerstheuniverse.wordpress.com/2010/07/25/command-line-syntax-some-basic-concepts/ I will look into the other links which were sent for the standard POSIX command-line syntax and will consider adding support for it. Both syntaxes would then be usable, making everybody happy. However, besides the command-line syntax, the option names were changed. The new options are mstsc-compatible from the start, and then extend with our set of options. For your code that invokes FreeRDP, you should basically have to migrate only once, when you decide to upgrade to the upcoming FreeRDP 1.1 release. FreeRDP 1.0 will simply be the last release with the old syntax, 1.1 and later will use the new set of options and the new syntax. Otherwise, we'd have to forever be stuck with the old syntax and its issues. If in the previous syntax, you would launch a remoteapp program this way: xfreerdp --app --plugin rail --data "||cmd" -u username -p password -d domain hostname The equivalent now becomes: xfreerdp "/app:||cmd" /u:username@domain /p:password /v:hostname That's putting aside huge gains for loading sub-plugins, like for device redirection or dynamic virtual channels: xfreerdp --plugin rdpdr --data "drive:media:/home" -- hostname which now becomes: xfreerdp /a:drive,media,/home hostname Or for multimedia redirection: xfreerdp --plugin drdynvc --data tsmf -- hostname which now becomes: xfreerdp /dvc:tsmf hostname Some of the issues with the POSIX standard command-line syntax is mainly with the usage of spaces inside argument values. From the link you've given, I see the following guideline: *Guideline 10:*The argument *--* should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character. The *--* argument should not be used as an option or as an operand. Ok, we can definitely handle that, but it means that for any variable-length list of values to an argument, we need to follow this guideline, since there is effectively no way of knowing where exactly the list ends. This is why we had the -- as a end delimiter for the list of --data parameters. /option:value drops the space, and makes it unambiguous from the start. A single element in the argument vector argv contains both the option and its value, period, no need to look for the value over multiple other elements of the argument vector. As for lists, I've decided to simply use comma-separated lists, which usually do not conflict with other symbols. For the previous syntax, we had the issue of : conflicting with paths like C:\, it was extremely annoying for drive redirection and remoteapp. So, here's what I suggest: Take a look, see what the real issue is. If there is enough demand for it I can look into simply adding support for the standard POSIX syntax and have exactly the same set of options usable with either one of the syntaxes, where the default syntax will remain the current one. Before parsing the options, a simple detection function will check for which one of the two syntaxes has been detected. This will still not fix your problem of compatibility, because option names have been changed. I can't help for this, as we need to move forward with a more suitable set of options. You can find the current generic command-line parser here: https://github.com/FreeRDP/FreeRDP/blob/master/winpr/libwinpr/utils/cmdline.c And here is where the client command-line options are being parsed with it: https://github.com/FreeRDP/FreeRDP/blob/master/client/common/cmdline.c You'll notice I'm passing flags to the parser indicating which syntax to parse the arguments with. We could basically implement the standard POSIX syntax and use the same options but with an alternative syntax. What do you think? Best regards, - Marc-Andre On Fri, Nov 30, 2012 at 7:49 PM, Kevin Dalley <kdal...@vmware.com> wrote: > I recently noticed that the master branch of FreeRDP has a change in the > command line interface. > > The new command line options no longer follow the POSIX standard for > command line interface or the GNU standard for CLI. > > Here are references for both standards: > POSIX: > http://pubs.opengroup.org/onlinepubs/009604499/basedefs/xbd_chap12.html > GNU: > > http://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html > > I strongly recommend that any tool which runs on Linux follow these > standards, > rather than create a new command line interface. This interface is > completely different from > any other tool which I have used on Linux. > > At VMware, we ship an application which runs xfreerdp, or alternatively, > rdesktop. > > A change in the command line interface breaks compatibility for us. We > would have to verify which version > of xfreerdp is available, and then choose which version of command line > arguments to use. Of course, > this problem can be worked around, but it is an ugly addition to the code. > > For those who haven't looked at the new command line interface, here is a > summary. > > Usage: xfreerdp [file] [options] [/v:<server>[:port]] > > Syntax: > /flag (enables flag) > /option:<value> (specifies option with value) > +toggle -toggle (enables or disables toggle, where '/' is a synonym of '+') > /v:<server>[:port] Server hostname > /port:<number> Server port > /w:<width> Width > ... > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > INSIGHTS What's next for parallel hardware, programming and related areas? > Interviews and blogs by thought leaders keep you ahead of the curve. > http://goparallel.sourceforge.net > _______________________________________________ > Freerdp-devel mailing list > Freerdp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freerdp-devel > ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
