search

techoe / gflags

Automatically exported from code.google.com/p/gflags
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Why unrecognized flagnames are silently ignored in a flagfile #50

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. write a wrong flag in a flagfile name : demo.flag
2. run a program using --flagfile=demo.flag
3. unrecognized flagnames are silently ignored,

What is the expected output? What do you see instead?
I see nothing and want the gflag notice me about the wrong flag .

What version of the product are you using? On what operating system?
1.6 linux

Please provide any additional information below.

In particular, unrecognized flagnames are silently ignored, as are flags that 
are missing a required value (e.g., a flagfile that just says --languages).

Why?

Original issue reported on code.google.com by lshmouse on 3 Nov 2011 at 6:40

GoogleCodeExporter commented 9 years ago 
Gosh, I'm actually not sure I can say -- this is a decision that's over 10 
years old at this point, and I can't remember why we made it.  Here's a thread 
I found from 2000 that may (or may not) shed some light:
---
Date: Mon, 31 Jul 2000 16:08:25 -0700 (PDT)
To: csilvers@google.com
Subject: Dealing with unrecognized flags

Hey, Craig--

I'm thinking that we should deal differently with unfamiliar flags
when parsing command lines.  Right now, we barf-- unless it's an
unfamiliar flag which is encountered in a "flagfile" (those we just
ignore).

I figure we should just ignore 'em, I guess.
---
to which I responded:
---
The problem is, often the "unfamiliar flag" is actually a typo.  Then
we want to die and force people to use the right name.  Nowadays I
often guess at the flag name.  For flagfiles this isn't a problem
because presumably people were careful in making them up.  :-)
---

Looking at it now, I don't see any good reason we shouldn't treat flagfiles the 
way as any other flag, except that it's difficult to change such semantics 
after such a long time.  I worry people might use this feature of flagfiles on 
purpose (as an alternative to --undefok, perhaps).

(Well, I guess I can think of one reason: if you remove a flag from a binary, 
and suddenly all your scripts stop working because they call binary 
--flagfile=foo, and you forgot to remove that flag from your flagfile.  
Presumably everything actually still works fine, so silently ignoring may be 
the 'right' thing to do.  But that's a pretty weak rationale, I think.)

Have you been having trouble because of this?  I do think it would be 
worthwhile to be able to have errors in flagfiles be fatal, but I don't know 
how invasive or API-breaking I want to be to do it.

Original comment by csilv...@gmail.com on 4 Nov 2011 at 12:46

GoogleCodeExporter commented 9 years ago 
Yes, I am trouble in using the flagfile.

The condition is that someone changed the flag name , and program can run
but with wrong answer. It wasted me  much time

to find the problem. I do not know if somelse have the same problem, but I
think if a user use a wrong flag, we should notice he or she immediatly.

Original comment by lshmouse on 4 Nov 2011 at 9:34

GoogleCodeExporter commented 9 years ago 
I agree this is an unfortunate situation.  I'm happy to take a look at a patch!

Original comment by csilv...@gmail.com on 5 Nov 2011 at 12:19

GoogleCodeExporter commented 9 years ago 
to #2 lshmouse
Please support my suggest, support flag alias to make rename smoothly:
http://code.google.com/p/gflags/issues/detail?id=65

Original comment by chen3feng on 29 Jan 2013 at 3:06

GoogleCodeExporter commented 9 years ago 
I agree that it can cause more troubles to not recognize such mistakes than it 
should be considered a feature to ignore them. But to maintain backwards 
compatibility, I would consider a build configure time setting which allows 
developers to choose one or the other behavior and/or boolean runtime switch 
which can be set in the main before any command-line flags are parsed. The 
default of this switch could be whatever is configured during build time. This 
way this change should be flexible enough so users that rely on this obsolete 
feature can still use it, and new users will just get the default which is that 
unknown flags trigger an error also in flagfiles unless --undefok is used.

Original comment by andreas....@gmail.com on 20 Mar 2014 at 3:43