A. Pagaltzis [EMAIL PROTECTED] writes:
Something like ++ instead of --.
I think thats ugly. Id suggest simply addding another dash [...]
I find it very interesting to note that although we're talking about
quite different semantics, everyone seems to be wanting to stick to
the ancient syntax
* Johan Vromans [EMAIL PROTECTED] [2005-06-19 11:15]:
I find it very interesting to note that although we're talking
about quite different semantics, everyone seems to be wanting
to stick to the ancient syntax of --style command line
options.
I dont see why it is ancient instead of sensible.
Johan Vromans wrote:
I have several tools that take different syntax on the command line,
specific for the task. For example, subcommands:
mycmd init db=$HOME/mydb
mycmd load db=$HOME/mydb data1
mycmd load --trace db=$HOME/mydb data1
mycmd --trace load db=$HOME/mydb data1
Yes;
Eric Wilhelm [EMAIL PROTECTED] writes:
Ok. Then my previous argument stands. If the --no- means unset any
hard-coded or config-file defaults, then it shouldn't be evaluated in
command-line order.
Good deduction, but the premise does not hold. --no- does not mean
unset any [...] defaults,
Eric Wilhelm [EMAIL PROTECTED] writes:
Independent of percentages, why disallow --foo --no-foo provided
there's a clear definition of the semantics?
I never suggested that it should be disallowed. Only that it should be
equivalent to '--no-foo --foo'.
That's part of the clearly defined
On Thu, 2005-06-16 at 20:12 -0700, Eric Wilhelm wrote:
The purpose of a negated option is (in all of the usages that I have
seen) to reset any hard-coded or config-file variable.
This is not the purpose, see my other posting.
-- Johan
On Sat, Jun 18, 2005 at 10:44:21AM +0200, Johan Vromans wrote:
The problem that I see is legacy. Many users expect the left-to-right
behaviour, and will get confused if some tools act differently.
I don't think that's merely legacy; the majority of those on this list who
have expressed a
Eric Wilhelm [EMAIL PROTECTED] writes:
What I'm trying to do with Getopt::Modern here is to establish some
conventions which allow this to happen internally. This saves the
author some code and gives the user a guaranteed consistent experience
with multiple programs.
The debate on the
Eric Wilhelm [EMAIL PROTECTED] writes:
Because I had originally built that as a wrapper around Getopt::Long, I
had a laundry-list of what didn't work.
This would have been interesting for me to know.
In fact, as I mentioned I would be happy for G::L to have this
functionality, but I doubt
To Eric,
Some might-be-helpful thoughts for you:
1. Bundling Problem on Getopt::Long:
Yes, I was very troubled for that problem before. I even had a same
thought as you to parse the arguments by myself. But after a couple of
tries I gave up. My codes get all messed up. Then I found
# The following was supposedly scribed by
# Johan Vromans
# on Saturday 18 June 2005 03:37 am:
What I'll probably end-up with is something like '--un-' performing
the above task of initializing internal values.
I'd strongly suggest that if you really break the long standing
conventions, even
imacat [EMAIL PROTECTED] writes:
[...] But, then, is this whole thread that meaningless?
I don't think so. Many good ideas and suggestions have come by, and
though not all ideas are equally viable, many people spend energy
on communicating ideas -- which is fundamental to open source
software.
Eric Wilhelm [EMAIL PROTECTED] writes:
Maybe we'll even manage to hammer it into a standard.
That would really be nice!
-- Johan
Orton, Yves [EMAIL PROTECTED] writes:
I currently have two projects that address this issue: Getopt::Toolkit
(which is based on Getopt::Long) and Getopt::Long version 3 (which is
a complete redesign, a.k.a. Getopt::Long on steroids). Merging the two
projects into a single new Getopt::Long
* Johan Vromans [EMAIL PROTECTED] [2005-06-18 23:20]:
Eric Wilhelm [EMAIL PROTECTED] writes:
Is '--un-' not distinctive enough?
I believe there's more involved that adding the --un-
semantics. For example, precedence order parsing yields
different results from left to right parsing.
I
Eric Wilhelm [EMAIL PROTECTED] writes:
You wouldn't say
--foo --no-foo
if you just meant
--no-foo
Would you?
I think the basic question is, what do you expect from a certain
combination of options and arguments. For example,
--foo arg1 --no-foo arg2
This can be interpreted as:
Eric Wilhelm [EMAIL PROTECTED] writes:
Do you mean to say that 99% of the time (when --foo and --no-foo are
both present) that it is because somebody has an alias with a --foo
flag written into it?
Independent of percentages, why disallow --foo --no-foo provided
there's a clear definition
Eric Wilhelm [EMAIL PROTECTED] writes:
Ok, and maybe I showing my age here, but is *this* where the
negated-options thing comes from? I.E. is this the historic (and
entire) reason for having the 'foo!' syntax in Getopt::Long?
No, it's because of a) defaults. Sometimes a flag is enabled by
Eric Wilhelm [EMAIL PROTECTED] writes:
Please see this essay
http://scratchcomputing.com/svn/Getopt-Modern/trunk/data/notes/why_order_matters.txt
Nice piece of writing, but it contains several flaws. For example:
If your spouse tells you to get tuna and halibut, but not any
other
On Fri, 17 Jun 2005 10:57:26 +0200
Johan Vromans [EMAIL PROTECTED] wrote:
Eric Wilhelm [EMAIL PROTECTED] writes:
Please see this essay
http://scratchcomputing.com/svn/Getopt-Modern/trunk/data/notes/why_order_matters.txt
If your spouse tells you to get tuna and halibut, but not any
* Eric Wilhelm [EMAIL PROTECTED] [2005-06-17 01:35]:
I dont understand. If there was no need to be able to say
--foo --no-foo, then why do both exist?
No, no, no. Start over.
1. There is a need.
2. It doesn't matter what order the user gives the options in,
the result should be the
On Jun 16, 2005, at 10:33 PM, Ken Williams wrote:
For a counterexample, please see the -f and -i options to /bin/rm.
Many people, myself included, have found it exceptionally useful that
the final switch takes precedence, because then we can do things like
alias ls ls -i and still be able
On Jun 16, 2005, at 11:04 PM, Eric Wilhelm wrote:
Ok, and maybe I showing my age here, but is *this* where the
negated-options thing comes from? I.E. is this the historic (and
entire) reason for having the 'foo!' syntax in Getopt::Long?
If so, is that why there is so much resistance to
Title: RE: RFC: Getopt::Modern
[Quoting Eric Wilhelm, on June 16 2005, 15:14, in Re: RFC:
Getopt::Mo]
15 years * n requests/year = 15*n degrees of flexibility =
unpredictable
Hmm. I'd say
15 years * n requests/year * m happy users = reliability
which is as meaningless as your
# The following was supposedly scribed by
# Johan Vromans
# on Friday 17 June 2005 12:55 am:
Do you mean to say that 99% of the time (when --foo and --no-foo are
both present) that it is because somebody has an alias with a --foo
flag written into it?
Independent of percentages, why disallow
# The following was supposedly scribed by
# imacat
# on Friday 17 June 2005 02:51 am:
I did not notice the go_shop problem. But I think it's trivial to
solve that with Getopt::Long:
my @conf_fishes = read_conf(fish); # get qw(trout)
my @opt_fishes = qw();
my $opt_nofish = 0;
On Fri, 17 Jun 2005 08:45:26 -0700
Eric Wilhelm [EMAIL PROTECTED] wrote:
Ok. Then my previous argument stands. If the --no- means unset any
hard-coded or config-file defaults, then it shouldn't be evaluated in
command-line order.
Well, as I said, if you would like unordered options,
# The following was supposedly scribed by
# Johan Vromans
# on Friday 17 June 2005 08:14 am:
If it involves typing @main::ARGV, something is wrong.
This is another one of your statements that feel like a religious
issue. If typing @main::ARGV indicates that something is wrong, I
think you have
* Eric Wilhelm [EMAIL PROTECTED] [2005-06-17 18:00]:
In fact, as I mentioned I would be happy for G::L to have this
functionality, but I doubt that program-order evaluation (one
of the main design goals) is going to fit without some serious
restructuring.
Why do you keep claiming that? Both
* Eric Wilhelm [EMAIL PROTECTED] [2005-06-17 18:20]:
In any case. How does G::L evaluate in precedence order?
That's why I'm writing G::?
By parsing into two separate variables, and allowing separate
module-client code evaluate how to react to the values in those
to variables. A working
On Fri, 17 Jun 2005 09:08:51 -0700
Eric Wilhelm [EMAIL PROTECTED] wrote:
Yes. You can solve it. It's not really trivial by the time you add
meats, cheeses, breads, and mustard though. All of these things come
in many flavors and you might have a config file with your favorites
listed in
* Eric Wilhelm [EMAIL PROTECTED] [2005-06-17 18:15]:
It's not really trivial by the time you add meats, cheeses,
breads, and mustard though. All of these things come in many
flavors and you might have a config file with your favorites
listed in it so that running go_shop with no arguments
--- A. Pagaltzis [EMAIL PROTECTED] wrote:
Why do you keep claiming that? Both me and someone else already
posted working code that shows how you can trivially do what you
want with Getopt::Long if you just use two different variables.
Which, to me, is the clincher. Getopt::Long can easily
On Jun 17, 2005, at 2:13 PM, A. Pagaltzis wrote:
* Ovid [EMAIL PROTECTED] [2005-06-17 20:15]:
I'm still trying to figure out why it's carried on this long.
Calling the new module ::Modern and claiming that ::Long is
crufty, too flexible, and unpredictable probably set the mood.
Amen.
On Fri, Jun 17, 2005 at 03:07:27PM -0500, Ken Williams wrote:
On Jun 17, 2005, at 2:13 PM, A. Pagaltzis wrote:
* Ovid [EMAIL PROTECTED] [2005-06-17 20:15]:
I'm still trying to figure out why it's carried on this long.
Calling the new module ::Modern and claiming that ::Long is
crufty,
# The following was supposedly scribed by
# Ken Williams
# on Friday 17 June 2005 01:07 pm:
Calling the new module ::Modern and claiming that ::Long is
crufty, too flexible, and unpredictable probably set the mood.
Amen. Eric, that was really obnoxious. You might have had more luck
convincing
* Austin Schutz [EMAIL PROTECTED] [2005-06-17 22:45]:
Imagine this is Eric's first try at publishing a module.
Then what is http://search.cpan.org/~ewilhelm/? :-)
You could take at least a cursory look before making such
assumptions
Regards,
--
#Aristotle
On Fri, Jun 17, 2005 at 11:22:58PM +0200, A. Pagaltzis wrote:
* Austin Schutz [EMAIL PROTECTED] [2005-06-17 22:45]:
Imagine this is Eric's first try at publishing a module.
Then what is http://search.cpan.org/~ewilhelm/? :-)
You could take at least a cursory look before making such
On Jun 17, 2005, at 3:37 PM, Austin Schutz wrote:
On Fri, Jun 17, 2005 at 03:07:27PM -0500, Ken Williams wrote:
On Jun 17, 2005, at 2:13 PM, A. Pagaltzis wrote:
* Ovid [EMAIL PROTECTED] [2005-06-17 20:15]:
I'm still trying to figure out why it's carried on this long.
Calling the new
On Fri, 17 Jun 2005 14:34:59 -0700
Austin Schutz [EMAIL PROTECTED] wrote:
Was I assuming, or was I imagining? The point is that the
community can be unnecessarily combative and ugly, a point which to
my eyes you have helped illustrate.
Well, I suppose, I am one of those you
* Austin Schutz [EMAIL PROTECTED] [2005-06-17 23:40]:
The point is that the community can be unnecessarily combative
and ugly, a point which to my eyes you have helped illustrate.
Yes, I was rude. At first I was frustrated after trying to find
information about Erics proposal other than this
Eric Wilhelm wrote:
Code:
http://scratchcomputing.com/svn/Getopt-Modern/trunk/
English:
http://scratchcomputing.com/developers/Getopt-Modern/
I tried following the online slide show but it failed here:
http://scratchcomputing.com/developers/Getopt-Modern/slides/text2.html
with a 404 Not
On Thu, 16 Jun 2005 11:21:04 +0200
Johan Vromans [EMAIL PROTECTED] wrote:
* lacks predictable behaviour
I fail to see your point here. Options are handled from left to
right, which makes perfect sense.
I have watched the on-line slide. The slide said:
* lacks predictable
Authors
Subject: Re: RFC: Getopt::Modern
On Thu, 16 Jun 2005 11:21:04 +0200
Johan Vromans [EMAIL PROTECTED] wrote:
* lacks predictable behaviour
I fail to see your point here. Options are handled from left to
right, which makes perfect sense.
I have watched the on-line slide. The slide
to go around your shell alias. Some programs like
'less' even allow you to put options into an environment variable, then
let command line options override the variable.
-Lee
Date: Thu, 16 Jun 2005 14:35:52 -0700
From: Eric Wilhelm [EMAIL PROTECTED]
To: module-authors@perl.org
Subject: Re: RFC
# The following was supposedly scribed by
# Johan Vromans
# on Thursday 16 June 2005 02:21 am:
[Quoting Eric Wilhelm, on June 15 2005, 16:58, in RFC:
Getopt::Modern]
As the author and maintainer of Getopt::Long I would be very
interested to know what exactly your problems are.
I would love
Eric Wilhelm wrote:
Ok. Here's one edge-case which probably involves somebody smart enough
to not get stuck in it. Is this really a good argument for perplexing
the user the other 99% of the time?
It seems to me that that situation is far more than 1%, more like 99%,
of the times *when
On Jun 16, 2005, at 4:56 PM, Ovid wrote:
I'm sorry, while I certainly won't argue that there is necessarily a
need for a new module here, I will argue that the order of arguments
shouldn't matter. Asking for foo and then asking for no foo
doesn't make a lick of sense to me. What does that
On Jun 16, 2005, at 10:12 PM, Eric Wilhelm wrote:
Do you mean to say that 99% of the time (when --foo and --no-foo are
both present) that it is because somebody has an alias with a --foo
flag written into it?
Restated: if we counted 100 times that the user used these flags
together, 99 of
# The following was supposedly scribed by
# Ken Williams
# on Thursday 16 June 2005 08:42 pm:
In my experience it's more like 99.999%. And I can't actually
remember seeing a legit case of the 0.001% coming out of my fingers,
but I'm throwing it in there as a bone.
The alias thingy is just an
You should take a look at C's manpage getopt_long(3).
The use of shell aliasing for the default options is very common on
the modern Linux boxes. Most Linux distributions shipped with default
shell aliasing, and most your so-called primitive users won't even
notice that. When you type
Eric Wilhelm wrote:
If this is the case, then the cat to be skinned is a couple of steps to
the left, since an alias override is a different beast than a
config-file override (and not having any way to tell them apart isn't
going to help either.)
I don't see what makes them so different --
* Eric Wilhelm [EMAIL PROTECTED] [2005-06-16 02:05]:
English:
http://scratchcomputing.com/developers/Getopt-Modern/
Your presentation gets about two slides in before it chokes on
404s.
I looked at the code and didnt see much that warranted a new
module and an OO API.
The example you show on
53 matches
Mail list logo
