Hi, Just chiping in that I like the old command line interface to stay, at least for a foreseeable future. The reason being loots of scripts that I don't want to (be forced to) change. So for atleast, say a year it should still be possible to use the old options.
This change in command line interface have been scaring me since the first time i read about it. I see some similarities to the mstsc options, but should freerdp really be a copy of mstsc? (My answer is no) If there is ways that make it easier to use for the user then that's all good, but (forced) change is always negative, for every one else then the one that made the change (more or less and that is in human nature) I find it hard to read command lines that do not have spaces in them. Reusable parser functions and this should not be a issue at all! regards Christian On Sat, Dec 1, 2012 at 5:14 PM, Marc-André Moreau < marcandre.mor...@gmail.com> wrote: > Hi olav, > > You are right about commands like /a (that 'a' stands for 'addin' btw, I > decided to with the more microsoft-like terminology). I do not intend to > leave it that way. I'm thinking of adding channel specific options, they > just aren't there yet. For instance, you can now enable clipboard this way: > > +clipboard > > Instead of doing: > > /vc:cliprdr > > This is much easier to remember and understand for users > > There is more work to be done on the device redirection channels and the > other channels, it's not fully done yet. > > For drive redirection, I was thinking of an option like /drive with > optional arguments, etc. > > As for using Linux or POSIX style syntax, I think there's enough people > asking for it, so I'll simply work on implementing that in my command-line > parser such that both command-line syntaxes will be usable. > > If the current "examples" are: > > xfreerdp connection.rdp /p:Pwd123! /f > xfreerdp /u:JohnDoe@CONTOSO /p:Pwd123! /v:rdp.contoso.com > xfreerdp /u:JohnDoe /p:Pwd123! /w:1366 /h:768 /v:192.168.1.100:4489 > > They would become: > > xfreerdp connection.rdp -p Pwd123! -f > xfreerdp -u JohnDoe@CONTOSO -p Pwd123! -v rdp.contoso.com > xfreerdp -u JohnDoe -p Pwd123! -w 1366 -h 768 -v 192.168.1.100:4489 > > One other question: should we use a space or a sign like '=' to separate > the option name from its value? For parsing, it easier if there are no > spaces. If we use '=', it would look like this: > > xfreerdp connection.rdp -p=Pwd123! -f > xfreerdp -u=JohnDoe@CONTOSO -p=Pwd123! -v=rdp.contoso.com > xfreerdp -u=JohnDoe -p=Pwd123! -w=1366 -h=768 -v=192.168.1.100:4489 > > What do you think? > > On Sat, Dec 1, 2012 at 3:23 AM, olav <ola...@online.no> wrote: > > > Hi, > > > > I think it is ok to shorten the command-line options.It is a correct > > presupposition that the user should not have to care about the details > > of the program's working, as for example which shared objectfiles to > > load. The commandline options should be about which goals to reach, for > > example forwarding of local home dir. Then: to get rid of commands for > > sub-plugin-loading is fine. The commandline options should be easy to > > understand and remember. > > > > In my opinion either "/a" nor "--plugin rdpr etc..." is easily > > understood and remembered. I would say that "--drive=<remote > > drive>,<local dir>" is. What relation is there between "a" and drive, > > disk or dir? > > > > I think that the options should use the standard of one hyphen for > > one-letter options, and two hyphens for more-than one letter options. I > > see is no significant gain in leaving this part of the standard. The > > problem with + and - then could could be solved with two sets of > > options: --enable-this and --disable-this. Or like the options to > > configure: --enable-this=off > > > > The quantum of typing is no big deal. Deviating too far from the posix > > standard is. > > > > Olav. > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > 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 > ------------------------------------------------------------------------------ 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
