Thanks Marc,
It works for the most part. I can help with it.
As for the Debug system, thanks for letting us know it about to change.
That will affect all developers but hopefully not users.
The parameters are such a big deal because everyone is affected.
Jay
As a matter of fact, I just
On 4 Dec 2012, at 20:54, Kevin Dalley wrote:
Please name modern examples which do not result from limited memory.
git does this I think to support the longform 'git-clone' like options.
I think bash looks (or looked) at whether it is invoked as /bin/sh
in order to disable bashisms.
sox does
Please don't use the IRC for decisions that affect EVERYONE. It's
fine for talking with another developer or support but it was not
designed for that purpose. Use the mailing list.
Looks like an unfair shot to me.
Ain't this very thread the actual proof that Marc-André
- uses *both* IRC
Hi all,
On 12/05/2012 11:01 AM, Philippe Auphelle wrote:
Please don't use the IRC for decisions that affect EVERYONE. It's
fine for talking with another developer or support but it was not
designed for that purpose. Use the mailing list.
neither IRC nor E-Mail is really the proper thing for
Hi,
As a matter of fact, I just merged a compatibility layer for the old CLI:
https://github.com/FreeRDP/FreeRDP/pull/846
It might not be perfect yet, but it parses and processes the old options
and even suggests mappings to the new options. I have also improved
detection of the command-line
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:
I'm not overly fond of the existing command line structure, but i'm
also not desiring necessarily to have an MSTSC compatible command
line structure, either.
I do understand the desire to have an MSTSC compatible interface, so
why not just create a front-end converter to translate the options
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
I fail to comprehend the need or utility for the change. Perhaps leave the
existing POSIX syntax for xfreerdp and create this new-fangled syntax for
wfreerdp. You can, and already have, been a lot more clever than the MS
reference documentation.
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
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,
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.
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
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
The fact that some of the discussion happens on IRC is partially behind
this. I've discussed this a lot on IRC but not on the mailing list. I
usually get a lot more advice on IRC than on the mailing list, and what came
out of the discussions I had with other community members is that while
On 01/12/12 07:28, Marc-André Moreau wrote:
With the old syntax, we had --disable-wallpaper. Not only this is twice
longer than the new option
...
It's definitely much less efficient than +/- anyway.
I'd suggest to integrate a bash/zsh/... *argument* autocompletion file, it
really helps:
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
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.
It's on my branch:
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
On 1 Dec 2012, at 07:36, olav wrote:
I totally agree with Kevin Dalley on this point:
fr., 30.11.2012 kl. 16.49 -0800, skrev Kevin Dalley:
I strongly recommend that any tool which runs on Linux follow these
standards,
rather than create a new command line interface. This interface is
I don't see any problems with enable/disable:
--wallpaper=yes and --wallpaper=no
Moreover, you can add very usefull group options for all +/- parameters:
--enable=wallpaper,aero or --disable=wallpaper,aero
And I can't understand where you've found problems with plugins. Enabling
plugins:
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
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.
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
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:
I'd have to agree. I like the old style better. Why did we switch to
this strange format?
Jay
On Fri, Nov 30, 2012 at 4: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
It looks like some kind of windowsis influence
--
Com os melhores cumprimentos.
Helmer Teles
http://hteles.wordpress.com
Sent from my Android Device
Please don't send me proprietary file formats, use ISO standard ODF instead
(ISO/IEC 26300)
.-.G N U
/v\
Hi,
I forgot one topic:
enabling/disabling options
This one is tricky. I really like the +/- syntax for enabling and disabling
options. For instance, we can enable or disable the wallpaper this way:
+wallpaper or /wallpaper enables the wallpaper
-wallpaper disables the wallpaper
This allows
I totally agree with Kevin Dalley on this point:
fr., 30.11.2012 kl. 16.49 -0800, skrev Kevin Dalley:
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
29 matches
Mail list logo
