Re: [Freerdp-devel] CMAKE_INSTALL_PREFIX does not load correctly library
Sure. I think that I want a small change to the way master handles the rpath, so I will work on that, and then we can move it to stable. - Original Message - From: Bernhard Miklautz bmikla...@thinstuff.at To: Kevin Dalley kdal...@vmware.com Cc: Freerdp-devel freerdp-devel@lists.sourceforge.net Sent: Thursday, December 6, 2012 2:30:50 PM Subject: Re: [Freerdp-devel] CMAKE_INSTALL_PREFIX does not load correctly library Hi, On Thu, Dec 06, 2012 at 11:11:45AM -0800, Kevin Dalley wrote: I just realized that master handles rpath correctly. I had been on stable for a while and didn't notice that master was fixed. good to know. Did you look further into this? - We should fix this on stable as well. Would you create an issue that we don't forget? Thanks. Best regards, Bernhard -- 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
Re: [Freerdp-devel] CMAKE_INSTALL_PREFIX does not load correctly library
I just realized that master handles rpath correctly. I had been on stable for
a while
and didn't notice that master was fixed.
- Original Message -
From: Kevin Dalley kdal...@vmware.com
To: bmikla...@thinstuff.at
Cc: Freerdp-devel freerdp-devel@lists.sourceforge.net
Sent: Tuesday, December 4, 2012 4:31:16 PM
Subject: Re: [Freerdp-devel] CMAKE_INSTALL_PREFIX does not load correctly
library
Actually, cmake does support having CMAKE_INSTALL_PREFIX to be used so
that the installed executable search the location where the libraries are
installed.
You can see examples similar to this in the section
Always full RPATH
of this document.
http://www.vtk.org/Wiki/CMake_RPATH_handling
It should be possible to modify some of the CMakeLists.txt files
so that the correct directories are searched. Of course, the system libraries
search path doesn't change, but executable will know where it should be
searched.
If you look at the linking as part of make VERBOSE=1, you can see the use
of -Wl,-rpath in the linking phase, so that the directories in which the
libraries
are built will be search if you run xfreerdp from the compilation directory.
However, the installation wipes out the references to these directories, as it
should.
We don't want the installed version of the executable to search the build
directories.
Unfortunately, I am having difficulty following the cmake suggestions
to make it do the right thing.
Is this file obsolete: /etc/ld.so.conf.d/freerdp.conf?
It is mentioned in
https://github.com/FreeRDP/FreeRDP/wiki/Compilation
- Original Message -
From: Bernhard Miklautz bmikla...@thinstuff.at
To: Kevin Dalley kdal...@vmware.com
Cc: Freerdp-devel freerdp-devel@lists.sourceforge.net
Sent: Tuesday, December 4, 2012 4:06:06 PM
Subject: Re: [Freerdp-devel] CMAKE_INSTALL_PREFIX does not load correctly
library
Hi,
On Tue, Dec 04, 2012 at 03:25:05PM -0800, Kevin Dalley wrote:
and CMAKE_INSTALL_PREFIX.
cmake -DCMAKE_INSTALL_PREFIX=/home/kevin
make clean; make VERBOSE=1; make VERBOSE=1 install
ldd ~/bin/xfreerdp
linux-vdso.so.1 = (0x7fff887ff000)
libXinerama.so.1 = /usr/lib/x86_64-linux-gnu/libXinerama.so.1
(0x7ffef57b1000)
libXext.so.6 = /usr/lib/x86_64-linux-gnu/libXext.so.6
(0x7ffef559f000)
libXcursor.so.1 = /usr/lib/x86_64-linux-gnu/libXcursor.so.1
(0x7ffef5393000)
libXv.so.1 = /usr/lib/x86_64-linux-gnu/libXv.so.1 (0x7ffef518d000)
libfreerdp-core.so.1.0 = not found
libfreerdp-gdi.so.1.0 = not found
CMAKE_INSTALL_PREFIX doesn't affect the systems library search path so
libraries are only searched in the default locations.
For testing I usually install to /opt and use a script like the
following to run xfreerdp:
#!/bin/bash
CMAKE_INSTALL_PREFIX=/opt/freerdp-stable-1.0
export PATH=$PATH:${CMAKE_INSTALL_PREFIX}/bin
export LD_LIBRARY_PATH=${CMAKE_INSTALL_PREFIX}/lib/x86_64-linux-gnu/
xfreerdp $@
(The lib/x86_64.. might be different on a non debian system)
Hope that helps.
Best regards,
Bernhard
--
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
Re: [Freerdp-devel] Why is there a change in the command line interface?
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
Re: [Freerdp-devel] Why is there a change in the command line interface?
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. - Original Message - 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
Re: [Freerdp-devel] Why is there a change in the command line interface?
Alex, The two of use agree on most issues here. Heuristics, no. Pre-existing parsers, yes. I prefer argp, because it includes documentation. We do disagree n argv[0] Using argv[0] to determine behavior definitely used to be standard, back in the pre-Linux days. mv and ln, I believe were the same binary. But not any more. And today, in memory-limited environments, busybox uses this technique. It makes sense there. Please name modern examples which do not result from limited memory. Using argv[0] leaves you in a situation where copying an executable to a new name results in different behavior. In your example, if I copied xfreerdp to xfreerdp-new, then the behavior would be different, even though the name is almost the same. And it using argv[0] violates the GNU standard, something you should do only when there is a good reason for doing so. - Original Message - From: Alex Bligh a...@alex.org.uk To: Kevin Dalley kdal...@vmware.com Cc: Alex Bligh a...@alex.org.uk, Stephen Dowdy sdo...@ucar.edu, freerdp-devel@lists.sourceforge.net Sent: Tue, 04 Dec 2012 11:46:34 -0800 (PST) Subject: Re: [Freerdp-devel] Why is there a change in the command line interface? On 4 Dec 2012, at 18:07, Kevin Dalley wrote: Please don't use argv[0] to determine the behavior. This is confusing. It should be possible to make a link to a program and have it behave in the same way as the original program. Also, it violates the GNU standards. http://www.gnu.org/prep/standards/html_node/User-Interfaces.html#User-Interfaces Opinion from someone who has had exposure to reading the code but not writing it, and tripped over the current CLI. In my opinion using argv[0] to influence program operation is perfectly reasonable and a lot of linux utilities do it (for better or worse). Moreover, the appropriate standard should be POSIX not GNU here. I don't believe there is a POSIX requirement not to do this (but POSIX standards are full of surprises). I understand some people consider it hacky, but it does permit the following which is what I'd recommend. If invoked as xfreerdp, use a command line interface as close as possible to the current one. I know this needs work, having tried to find my way through the homebrew parser to backport stuff. I would suggest moving to the getopt_long which has support everywhere, and at least is a known quantity. I do not think there is anything freerdp does which would not possible using getopt_long, and there might be bugs which could be fixed by a refactor (from memory the parsing of certain security parameters depends on other parameters, which means as they are parsed in order, the effect is dependent upon the ordering of parameters - this could be fixed by recording parameters prior to interpreting them). If invoked as [something else], use a CLI more friendly for windows users, be that borrowed from mstsc or otherwise. Heuristics that rely on the presence or absence of slashes or minus signs are bound to fail as filenames on windows can begin with minus signs and file names (well, paths) on linux can begin with slashes. So don't try and guess, use something that can never be ambiguous (i.e. argv[0]). I believe on some non-POSIX platforms it may not be possible to determine the value of argv[0], but I doubt xfreerdp will run there anyway. -- 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
Re: [Freerdp-devel] CMAKE_INSTALL_PREFIX does not load correctly library
Actually, cmake does support having CMAKE_INSTALL_PREFIX to be used so
that the installed executable search the location where the libraries are
installed.
You can see examples similar to this in the section
Always full RPATH
of this document.
http://www.vtk.org/Wiki/CMake_RPATH_handling
It should be possible to modify some of the CMakeLists.txt files
so that the correct directories are searched. Of course, the system libraries
search path doesn't change, but executable will know where it should be
searched.
If you look at the linking as part of make VERBOSE=1, you can see the use
of -Wl,-rpath in the linking phase, so that the directories in which the
libraries
are built will be search if you run xfreerdp from the compilation directory.
However, the installation wipes out the references to these directories, as it
should.
We don't want the installed version of the executable to search the build
directories.
Unfortunately, I am having difficulty following the cmake suggestions
to make it do the right thing.
Is this file obsolete: /etc/ld.so.conf.d/freerdp.conf?
It is mentioned in
https://github.com/FreeRDP/FreeRDP/wiki/Compilation
- Original Message -
From: Bernhard Miklautz bmikla...@thinstuff.at
To: Kevin Dalley kdal...@vmware.com
Cc: Freerdp-devel freerdp-devel@lists.sourceforge.net
Sent: Tuesday, December 4, 2012 4:06:06 PM
Subject: Re: [Freerdp-devel] CMAKE_INSTALL_PREFIX does not load correctly
library
Hi,
On Tue, Dec 04, 2012 at 03:25:05PM -0800, Kevin Dalley wrote:
and CMAKE_INSTALL_PREFIX.
cmake -DCMAKE_INSTALL_PREFIX=/home/kevin
make clean; make VERBOSE=1; make VERBOSE=1 install
ldd ~/bin/xfreerdp
linux-vdso.so.1 = (0x7fff887ff000)
libXinerama.so.1 = /usr/lib/x86_64-linux-gnu/libXinerama.so.1
(0x7ffef57b1000)
libXext.so.6 = /usr/lib/x86_64-linux-gnu/libXext.so.6
(0x7ffef559f000)
libXcursor.so.1 = /usr/lib/x86_64-linux-gnu/libXcursor.so.1
(0x7ffef5393000)
libXv.so.1 = /usr/lib/x86_64-linux-gnu/libXv.so.1 (0x7ffef518d000)
libfreerdp-core.so.1.0 = not found
libfreerdp-gdi.so.1.0 = not found
CMAKE_INSTALL_PREFIX doesn't affect the systems library search path so
libraries are only searched in the default locations.
For testing I usually install to /opt and use a script like the
following to run xfreerdp:
#!/bin/bash
CMAKE_INSTALL_PREFIX=/opt/freerdp-stable-1.0
export PATH=$PATH:${CMAKE_INSTALL_PREFIX}/bin
export LD_LIBRARY_PATH=${CMAKE_INSTALL_PREFIX}/lib/x86_64-linux-gnu/
xfreerdp $@
(The lib/x86_64.. might be different on a non debian system)
Hope that helps.
Best regards,
Bernhard
--
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
Re: [Freerdp-devel] Why is there a change in the command line interface?
Alexis makes a good point in the ps. If you are used to one type of syntax, it is difficult to follow a new syntax. If every developer created a different type of syntax, it would be extremely difficult to use Linux. - Original Message - From: Alexis Moinet alexis.moi...@umons.ac.be To: Freerdp-devel freerdp-devel@lists.sourceforge.net Sent: Sun, 02 Dec 2012 03:30:17 -0800 (PST) Subject: Re: [Freerdp-devel] Why is there a change in the command line interface? ps: I'm a bit lost too with the new syntax by the way, but it must be because I've not used Windows command-line in years -- Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net/ ___ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
Re: [Freerdp-devel] Why is there a change in the command line interface?
Keeping backwards compatibility sounds like a wonderful idea. If you are willing to do the work to support both, that sounds good. I suspect that it will take some work to make sure that everything works well. Part of my problem is that I will have to support old versions of xfreerdp, as well as new versions. My customers may be using a 2 year old Ubuntu, which doesn't have FreeRDP. 2 years from now, that will probably remain the same. Let's consider the documentation as well. With the old style arguments, there are 3 places where each argument appears: client/X11/xfreerdp.1.xml, for documentation libfreerdp-utils/args.c, in the help section libfreerdp-utils/args.c, in the argument parsing In the new style arguments, args.c is replaced with client/common/cmdline.c, which contains 2 references to every argument argp_parse allows the --help output to be combined with the argument parsing, which gets rid of one of the duplications. --help includes arguments if and only if the arguments are actually parsed. You still have to worry about the man page, but you reduce the duplication a little. When long command line arguments were first added, they were a bit controversial. There was a stage when + was used rather than --, but most innovation in command line arguments have been minimal since then. - Original Message - From: Marc-André Moreau marcandre.mor...@gmail.com To: Christian Nilsson nik...@gmail.com Cc: freerdp-devel@lists.sourceforge.net Sent: Sat, 01 Dec 2012 08:43:05 -0800 (PST) Subject: Re: [Freerdp-devel] Why is there a change in the command line interface? I've designed a very generic command-line parser with that in mind. I've been told by some people on IRC that they were fine with just moving on to the new command-line interface, so I didn't bother doing the extra work for keeping backwards compatibility forever. However, it is definitely doable. In other words, here's the work that needs to be done: Implement the POSIX-style command-line syntax parsing in the parser, detect it, and use it when detected. Implement a detection method for the old arguments (can be done by checking for the hostname being passed last without /v:, and the syntax being POSIX/Linux) and offer backwards compatibility for the old set of arguments in this case. This should be fairly easy to do for simple arguments, but it will require more work for stuff like --plugin. This way, we can offer backwards compatibility, and we can offer both command-line syntaxes (windows-style, linux-style), such that everybody is happy. On Sat, Dec 1, 2012 at 11:31 AM, Christian Nilsson nik...@gmail.com wrote: 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?
[Freerdp-devel] Why is there a change in the command line interface?
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
Re: [Freerdp-devel] version 1.0.2-rc1
What is the timeline on 1.0.2? I have at least one fix I want to get into it, but I want to do additional testing, if there is time. - Original Message - From: Bernhard Miklautz bmikla...@thinstuff.at To: freerdp-devel@lists.sourceforge.net Sent: Tuesday, November 6, 2012 3:15:14 PM Subject: [Freerdp-devel] version 1.0.2-rc1 Hi all, we just tagged the first release candidate for freerdp version 1.0.2 it can be found at https://github.com/FreeRDP/FreeRDP/tree/1.0.2-rc1. Version 1.0.2 will be a maintenance release for the stable-1.0 branch containing basically bug fixes - see changelog for details. Please help us by testing and reporting issues - https://github.com/FreeRDP/FreeRDP/wiki/BugReporting. Best regards, Bernhard -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
[Freerdp-devel] Is there work on releasing the next stable FreeRDP?
I'm particularly interested in the --from-stdin command line option and the fixes to parenting a window in xfreerdp. I created a patch to add these 2 features to freerdp-1.0.1, but it would be nice to point people toward a stable release, rather than a patched release. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
