Hi Kevin, Ok, let's make take a decision right now: there will be backwards compatibility for the old options as well. There is a bunch of ways I can think of that would allow us to detect which set of options is used with very high accuracy. This settles the matter which a lot of you are pointing out. Now for all of those pushing for a release, this is again added work on myself. I'm just trying to get everything in order for a 1.1 release here, and I'm working on tons of other things just as important as this at the same time. Right now time spent on the CLI is time pushing back TS Gateway, which a lot of the other community members care a LOT about. There's been a lot of helpful people on IRC offering their help, but to get everything in order and to please everyone, there's really a lot of work to be done. I can definitely give a list of things that can help, but when I suggest things, it doesn't really work. I feel like I'm saying suggestions out loud for myself because most of the time I end up doing it myself after some time.
As for using an existing parser, no, there is none which does everything we need, is under a suitable license, and is not an added strong dependency. We avoid adding strong dependencies as much as possible, the only one we have is OpenSSL right now, and we're trying to make it a soft dependency replaceable by other libraries. Trust me, from experience, strong dependencies that could be replaced were eventually replaced, since they often cause more problems than they solve. Each time you add one, you're reducing the portability of FreeRDP. I am not trying to force one CLI on all systems since the current code now supports both the Windows-style and Linux-style syntax. On Tue, Dec 4, 2012 at 2:00 PM, Kevin Dalley <kdal...@vmware.com> wrote: > Hi Marc-Andre, > > I don't want to discourage you from the excellent work you are doing. > However, I want to > make sure that you are cautious. > > Any method which uses heuristics is subject to error in certain cases. > Counting the number of arguments will reduce the errors, > but when errors happen, they may be difficult to understand. It is better > to know absolutely which parser will be used > in any given case. Yes, I believe that you can improve the heuristics, > but it will still be heuristics, and still subject > to odd cases where the parser will not be predicted the user. However, > there are standard, well-tested > parsers for each system. If you roll your own, it is likely that will be > some errors. Change the options to be rational, > but just use pre-existing parsers. Yes, there are options which are > difficult to follow in the old CLI. > > If you want to change the CLI, I suggest standardizing on a GNU-style CLI > for Linux, > a Windows style interface for Windows, etc. Don't try to force one CLI > for all systems. > Users are used to the standard interface in their environment. > > Developers who call FreeRDP need to establish backwards compatibility for > any changes for years, which probably means forever. > This isn't necessarily bad, if the new interface is an improvement. > However, it is a reality. That is a lot of developers. > > > ------------------------------ > *From: *"Marc-André Moreau" <marcandre.mor...@gmail.com> > *To: *"Kevin Dalley" <kdal...@vmware.com> > *Cc: *"Freerdp-devel" <freerdp-devel@lists.sourceforge.net>, "Christian > Nilsson" <nik...@gmail.com> > *Sent: *Tuesday, December 4, 2012 10:33:03 AM > > *Subject: *Re: [Freerdp-devel] Why is there a change in the command line > interface? > > Hi Kevin, > > The current syntax detection method is very naive and can simply be > replaced by a much better one that will work with much more accuracy. For > instance, we know what the expected options are, one very accurate way > would be to parse the argument vector twice, one for each syntax, and count > the number of recognized options. This way, the parser would effectively > know what is an option and what is a value, avoiding potential conflicts > with values like what you pointed out. It's nothing that can't be fixed, > yet you speak like there is no good solution to this problem. It's a > no-brainer. > > Also, I can guarantee you this is a one-time change. I have been meaning > to do it for a very long time but never got the time to do it. Now is the > time, in preparation for the 1.1 release. > > I don't mind backwards compatibility for a period of time, but let's face > it, I know I'm going to have to do all the work necessary for this. Feel > free to prove me wrong, but I'm kind of disillusioned right now. > > On Tue, Dec 4, 2012 at 12:59 PM, Kevin Dalley <kdal...@vmware.com> wrote: > >> Using a Microsoft style command line syntax for a Linux program really >> doesn't >> make sense. I think that it would be best to drop the MS style arguments >> from >> Linux. It's too difficult to get the parsing right. >> >> For example "/admin" is a legal file name. How can you tell whether >> it is a connection file or a file name. >> >> I don't like changing the arguments, though I do sympathize with the idea >> of having the arguments appear compatible with other RPC clients. >> >> Having a one-time change in command line arguments *might* be OK, if >> there is sufficient >> warning to the users, and a long period to allow scripts to change. This >> change will >> cause a lot of pain to a lot of users. Let's make sure that the pain >> is justified. >> >> ----- Original Message ----- >> From: "Marc-André Moreau" <marcandre.mor...@gmail.com> >> To: "Christian Nilsson" <nik...@gmail.com> >> Cc: "Freerdp-devel" <freerdp-devel@lists.sourceforge.net> >> Sent: Tuesday, December 4, 2012 8:00:21 AM >> Subject: Re: [Freerdp-devel] Why is there a change in the command line >> interface? >> >> Hi, >> >> As explained earlier, the new command-line options are first based on the >> mstsc options, from which we extend to add all our options. >> >> You can find the mstsc command-line reference here: >> >> http://windows.microsoft.com/en-US/windows-vista/Use-command-line-parameters-with-Remote-Desktop-Connection >> >> mstsc [<connection file>] [/v:<server[:port]>] [/admin] [/f[ullscreen]] >> [/w:<width>] [/h:<height>] [/public] | [/span] [/edit "connection file"] >> [/migrate] [/?] >> >> Since we support both syntaxes, /v becomes -v >> >> Using an option for the hostname means we can put the hostname anywhere we >> want in the command. >> >> With mstsc, the only option-less argument that can be passed is the .rdp >> connection file. If we were to retain the old syntax where the hostname is >> always the last argument and option-less, then we would not be able to >> really make the difference between xfreerdp being invoked with a .rdp file >> and xfreerdp being invoked with a hostname, unless we check for the .rdp >> file extension. >> >> Now you do bring a point that since putting the hostname last is no longer >> enforced, this breaks the old functionality where multiple command lines >> could be passed once to xfreerdp to launch multiple instances. It would be >> possible to use some sort of a separator to divide set of options and >> provide similar functionality. However, I'd like to know more about who, >> why and how this feature was used exactly, and if we should do it the same >> way (multiple set of options in a single command-line that can only be >> entered once). What happens if you want to launch another session from the >> same instance after it has already been launched? >> >> Here is what I suggest as a replacement or addition: >> >> Add a command-line argument giving the path to a local named pipe like >> /tmp/freerdp, on which the given xfreerdp instance would listen for >> further >> command-line strings. We could also make it such that xfreerdp could be >> ran >> without launching a session, and just listen for connection command lines. >> >> What do you think? >> >> On Tue, Dec 4, 2012 at 10:34 AM, Christian Nilsson <nik...@gmail.com> >> wrote: >> >> > Why do we need to add -v before hostname? >> > Is it it still needed to have host as the last option on the >> commandline? >> > >> > There is other applications that can take them in any order (mplayer is >> > one example i have mentioned before) >> > Is there still multi connection support as in FreeRDP-old (one instance >> of >> > xfreerdp connected to multiple servers) If not giving commands in any >> order >> > should be trivial? And even if there is multi connections support it >> shuld >> > work with a command like: xfreerdp -globalopt1 -globalopt2 host1:3389 >> > -opt-for-host1 host2:3399 -opt-for-host2 >> > >> > This -v option dosn't make sense to me. >> > >> > Regards >> > Christian >> > >> > On Tue, Dec 4, 2012 at 8:19 AM, Kevin Dalley <kdal...@vmware.com> >> wrote: >> > >> >> OK. I understand it a little bit more. I hadn't realized that the >> >> server name and port are now optional, >> >> rather than mandatory. I tested the new parser briefly. There do seem >> to >> >> be a lot of changes. >> >> It will take me a while to determine whether I understand it and can >> use >> >> it. >> >> >> >> Some suggestions: >> >> >> >> If file is optional, then it should have an option in front of it, >> >> otherwise it should be >> >> mandatory. >> >> >> >> Test this parser for quite a while before switching to it in stable. >> >> >> >> There are very reliable CLI parsers already written. Writing a new one >> >> brings a strong risk that there are some cases which are not >> interpreted >> >> correctly. >> >> >> >> Here's a case which seems to be interpreted incorrectly. >> >> Since the file name starts with "/", the parser assumes that we >> >> are using windows style options. >> >> >> >> $ xfreerdp /tmp/foo -v 10.113.138.75:3389 >> >> error: server hostname was not specified with /v:<server>[:port] >> >> >> >> ----- Original Message ----- >> >> From: Marc-André Moreau <marcandre.mor...@gmail.com> >> >> To: Kevin Dalley <kdal...@vmware.com> >> >> Cc: Alex Bligh <a...@alex.org.uk>, Freerdp-devel < >> >> freerdp-devel@lists.sourceforge.net>, Alexis Moinet < >> >> alexis.moi...@umons.ac.be> >> >> Sent: Mon, 03 Dec 2012 20:15:41 -0800 (PST) >> >> Subject: Re: [Freerdp-devel] Why is there a change in the command line >> >> interface? >> >> >> >> Hey, I haven't magically brought back the old *options* back, only the >> >> syntax. >> >> Your command should be: >> >> xfreerdp -v 10.113.131.83 >> >> >> >> On Mon, Dec 3, 2012 at 6:31 PM, Kevin Dalley <kdal...@vmware.com> >> wrote: >> >> Somehow, running the command does not seem to work for me. >> >> >> >> >> >> ~/bin/xfreerdp 10.113.131.83:3389 >> >> >> >> error: server hostname was not specified with /v:<server>[:port] >> >> >> >> >> >> I see a potential problem with >> >> >> >> >> >> freerdp_detect_windows_style_command_line_syntax >> >> >> >> >> >> If any of the arguments are a file name which starts with a "/", then >> the >> >> command line would be assumed to be >> >> >> >> windows style. >> >> >> >> >> >> ----- Original Message ----- >> >> >> >> From: "Alex Bligh" <a...@alex.org.uk> >> >> >> >> To: "Marc-André Moreau" <marcandre.mor...@gmail.com> >> >> >> >> Cc: "Alex Bligh" <a...@alex.org.uk>, "Kevin Dalley" < >> kdal...@vmware.com>, >> >> "Freerdp-devel" <freerdp-devel@lists.sourceforge.net>, "Alexis >> Moinet" < >> >> alexis.moi...@umons.ac.be> >> >> >> >> >> >> Sent: Sunday, December 2, 2012 11:58:47 PM >> >> >> >> Subject: Re: [Freerdp-devel] Why is there a change in the command line >> >> interface? >> >> >> >> >> >> On 2 Dec 2012, at 18:41, Marc-André Moreau wrote: >> >> >> >> >> >> > I have added support for both syntaxes. Detection of the syntax is >> >> >> >> > performed by checking if arguments start with / or not. >> >> >> >> > >> >> >> >> > Right now the help will show only the windows-style syntax, but the >> >> >> >> > arguments are exactly the same for the other syntax, aside from the >> >> syntax >> >> >> >> > itself. >> >> >> >> >> >> You could always display windows help from /help and POSIX help from >> >> --help. >> >> >> >> >> >> -- >> >> >> >> Alex Bligh >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> >> Remotely access PCs and mobile devices and provide instant support >> >> Improve your efficiency, and focus on delivering more value-add >> services >> >> Discover what IT Professionals Know. Rescue delivers >> >> http://p.sf.net/sfu/logmein_12329d2d >> >> >> >> _______________________________________________ >> >> Freerdp-devel mailing list >> >> Freerdp-devel@lists.sourceforge.net >> >> https://lists.sourceforge.net/lists/listinfo/freerdp-devel >> >> >> > >> > >> >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> _______________________________________________ >> Freerdp-devel mailing list >> Freerdp-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freerdp-devel >> > > > ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
