Re: Support for variable number of arguments in popt
On Sep 7, 2011, at 4:44 AM, Christian Schmidt wrote:
Hi,
I'm trying to parse a command line that can contain multiple variable
number of arguments for a parameter, e.g.
program -r /dev/sda /dev/sdb -m /dev/sdc /dev/sdd -b 16m …
Traditionally, uglix was designed with the model
PROGRAM OPTIONS ARGUMENTS
and that is captured in strict POSIX (and still common on *BSD systems iirc).
The default option processing enhances --options=arg to take the next
item, and there is the = that has been added to introduce some form
of stickiness.
What you are seeking with multiple arguments to a single option
(and I understand well why you are attempting) isn't well supported
anywhere afaik. The usual solution is to embed white space within
quotes like
program -r /dev/sda /dev/sdb -m /dev/sdc /dev/sdd -b 16m
The reason for the space separated lists is simply shell expansion.
Given existing device nodes you could write program -r /dev/sd[ab] -m
/dev/sd[cd] -b 16m ... to reach the same. Similar expansion could be
done with {a..z} or wildcard patterns. However this is not a case of
leftover arguments since the context (in the above example, -r or -m) is
relevant.
Got it.
So far I tried to use POPT_ARG_ARGV (which expects one -r/-m for each
argument) as well as poptPeekArg from within a r/m handler to look at
the next word in the command line. However, poptPeekArg only seems to
work after all arguments are parsed.
Yes I can believe that poptPeekArg() isn't going to work for what you
intend. I _MIGHT_ be able to make poptPeekArg() work that way, but
its rather tricky to unravel nested coroutine recursions to get
that job done. The implementation would likely need a backtracking
parser so that all the options copuld be parsed out to determine
what exactly the next argument should be. POPT is already doing
that to support the rather obscure !#:+ syntax used by popt aliases.
(aside)
The syntax choice was derived from KSH/BASH … but its dreadfully obscure
shell functionality and only !#:+ is implemented in POPT.
Here's some usage examples from /usr/lib/rpm/rpmpopt:
# [--dbpath DIRECTORYuse database in DIRECTORY
rpm alias --dbpath --define '_dbpath !#:+'
# [--ftpport port] port number of ftp server (or proxy)
rpm alias --ftpport --define '_ftpport !#:+'
# [--ftpproxy host] hostname or IP of ftp proxy
rpm alias --ftpproxy--define '_ftpproxy !#:+'
# [--httpport port] port number of http server (or proxy)
rpm alias --httpport--define '_httpport !#:+'
# [--httpproxy host]hostname or IP of http proxy
rpm alias --httpproxy --define '_httpproxy !#:+'
You _MIGHT_ be able to consume the next two arguments by rewriting -m/-r
with an alias, and then rewriting what is passed to the program with
a POPT_ARGFLAG_DOC_HIDDEN helper option (--mstuff/--rstuff used in example) like
program alias -m--mstuff !#:+ --mstuff !#:+
program alias -r--rstuff !#:+ --rstuff !#:+
if the number of arguments to -m and -r is always 2 strings.
Is there a way to realize what I'm trying within the current version of
popt, and if not, would there be any interest (or chance of being added)
implementing a POP_ARG_LIST that would act like POPT_ARG_ARGV, but take
all arguments until the next parameter starting with a -?
There's likely some other alternatives using a POPT callback (caveat: it
would require peeping into POPT internal data structures)
And its possible to rewind/restart POPT argument processing, but that
too is quite tricky (RPM used to do multiple passes on options/args
in order to extract one option that then modified how the options were
further processed: total PITA to maintain and not KISS reliable engineering …)
hth
73 de Jeff
Regards,
Christian
__
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
__
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
Re: Please remove the following content
On Jul 5, 2011, at 4:32 AM, Hulin, Gerlinde (E D EA SOL D TC1) wrote: Hello, The following two mails got in your archive without my agreeement. I cannot accept that my complete adress and email contact is online. My memory of the series of events leading to these messages goes like this: - You sent mail privately asking about POPT licensing. - I replied that the concerns should be posted to popt-devel@rpm5.org. POPT is an open-source project that conducts matters transparently and publicly, particular for matters like license audits. - You posted publicly here: http://rpm5.org/community/popt-devel/0244.html - The issues were replied to here: http://rpm5.org/community/popt-devel/0245.html You did ask (and received an answer) on a public mailing list. - You (again) requested a resolution to your issues here: http://rpm5.org/community/popt-devel/0246.html - You received two replies here: http://rpm5.org/community/popt-devel/0247.html http://rpm5.org/community/popt-devel/0248.html And now you wish to undo actions that you initiated, with replies as requested, because you dod not consent to publishing your contact information on line? At a minimum, your contact information is in more than the two messages you are requesting being removed. And removing only 2 messages is _NOT_ considering that the public popt-devel@rpm5.org mailing list is reflected in many other locations on the internet. Even if I removed the messages in popt-devel@rpm5.org, you seem to have given (imho, I am not a lawyer) implied consent by initiating actions that contained your contact info and choosing to publish on a public mailing list. I can/will remove the messages in popt-devel@rpm5.org if there is better reason than that you did not realize what public and transparent means when you requested information. Otherwise, consistent with policy @rpm5.org, I'd prefer to leave the public record exactly as is: other actions, like removing messages and otherwise changing the public record, are inconsistent with the intents and goals of a FL/OSS project. 73 de Jeff Please remove the conent from the archive http://www.mail-archive.com/popt-devel@rpm5.org/msg00245.html http://www.mail-archive.com/popt-devel@rpm5.org/msg00246.html Thank you very much Best regards, Gerlinde Hulin -Original Message- From: Mail Archive Support [mailto:themailarch...@gmail.com] Sent: Wednesday, June 29, 2011 10:34 PM To: Hulin, Gerlinde (E D EA SOL D TC1) Subject: Re: Please remove the following content Gerlinde, All the information we have on that list can be found here: http://www.mail-archive.com/popt-devel@rpm5.org/info.html Beyond that, we do not know the contact information for the mailing list administrators. Most mailing list services have a -owner address where you can reach the list admin (for example, if the list is gos...@jab.org then the list admin can likely be reached at gossip-ow...@jab.org). If this does not work, you will need to search for the website that hosts the mailing list, or post a question to the mailing list. Tom Support The Mail Archive On Wed, Jun 29, 2011 at 8:35 AM, Hulin, Gerlinde (E D EA SOL D TC1) gerlinde.hu...@siemens.com wrote: Hello, Who is the list administrator ? Since this email got published without my aproval I do not know who added this content. However you can see from my email account that my email account is in the two web pages. _http://www.mail-archive.com/popt-devel@rpm5.org/msg00245.html_ _http://www.mail-archive.com/popt-devel@rpm5.org/msg00246.html_ Best regards, Gerlinde Hulin -Original Message- From: Mail Archive Support [mailto:themailarch...@gmail.com] Sent: Wednesday, June 29, 2011 4:53 PM To: Hulin, Gerlinde (E D EA SOL D TC1) Subject: Re: Please remove the following content Gerlinde, Thanks for writing. The Mail Archive's policy is to delete messages only with the approval of the list administrator. We are providing a free service for list administrators and the admin needs to be the final decision maker on archived list content. Please discuss your request with the list admin and have him contact us directly if he wishes to remove the posts from the archive. Tom Support The Mail Archive On Wed, Jun 29, 2011 at 12:25 AM, Hulin, Gerlinde (E D EA SOL D TC1) gerlinde.hu...@siemens.com wrote: Hello, The following two mails got in your archive without my agreeement. I cannot accept that my complete adress and email contact is online. Please remove the conent from the archive _http://www.mail-archive.com/popt-devel@rpm5.org/msg00245.html_ _http://www.mail-archive.com/popt-devel@rpm5.org/msg00246.html_ Thank you very much Best regards, Gerlinde Hulin -- Support The Mail Archive www.mail-archive.com -- Support The Mail Archive www.mail-archive.com
Re: AW: INFO: Popt 1.14 license evaluation - response appreciated
On Mar 14, 2011, at 7:41 AM, Hulin, Gerlinde (E D EA SOL D TC1) wrote: Hello, I was wondering if you could respond to my question ? Are ou going to get the issues sorted out regarding the license texts ? I thought this reply (Mark Hatle is part of the the @rpm5.org project that maintains POPT) was sufficient: http://rpm5.org/community/popt-devel/0245.html If Mark's answer is not sufficient to get the issues sorted out, you will have to be more specific about what the issue(s) are than mailing a highlighted web form from an automated scanner in order for me to tell what issues remain. What I see is that your automated scanner is confused about generated files from GNU tools using in POPT. 73 de Jeff Best regards, Gerlinde Hulin _ Von: Hulin, Gerlinde (E D EA SOL D TC1) Gesendet: Thursday, March 03, 2011 10:15 AM An: 'popt-devel@rpm5.org' Cc: Hufnagel, Michael (E D EA SOL EN) Betreff:INFO: Popt 1.14 license evaluation - response appreciated Hello, Am doing the liecense clearing for open source components in our department. I did the clearing your component popt1.4. I scanned all files of popt 1.14 for license informations. Unfortunately there are issues regarding the popt licenses. Most of the licenses does not match with the MIT license. Some files are under the GPL (wich is irreversible !), and 2 license informations are not correct. Jef Johnson told me to post to this email in order to get the issues sorted out. On the home page popt is stated as MIT style license http://freshmeat.net/tags/mitx-consortium-license. But here is what I found: 1) Global Licenses MIT style - disclaimer X Consortium for promotion Copyright (c) 1998 Red Hat Software Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium. 36 \artifact.unpacked\popt-1.14\COPYING 294 \artifact.unpacked\popt-1.14\install-sh 3070 \artifact.unpacked\popt-1.14\config.sub 2250 \artifact.unpacked\popt-1.14\config.guess 14434 \artifact.unpacked\popt-1.14\ltmain.sh 125 \artifact.unpacked\popt-1.14\popthelp.c 47 \artifact.unpacked\popt-1.14\poptint.h 0 \artifact.unpacked\popt-1.14\test1.c 0 \artifact.unpacked\popt-1.14\po\sv.po 0 \artifact.unpacked\popt-1.14\po\vi.po 0 \artifact.unpacked\popt-1.14\po\fr.po 0 \artifact.unpacked\popt-1.14\po\pl.po 0 \artifact.unpacked\popt-1.14\po\de.po 44 \artifact.unpacked\popt-1.14\popt.h 49 \artifact.unpacked\popt-1.14\poptparse.c 2797 \artifact.unpacked\popt-1.14\popt.3 50 \artifact.unpacked\popt-1.14\poptconfig.c 2) Other Licenses – NO NOT USE – license issue Open Issue... /* (C) 1998-2002 Red Hat, Inc. -- Licensing details are in the COPYING file accompanying popt source distributions, available from ftp://ftp.rpm.org/pub/rpm/dist. */ ... This strin occurs in many places but the this link here is not correct Wrong license information # This file is distributed under the same license as the popt package. # This file is put in the public domain. 0 \artifact.unpacked\popt-1.14\po\fi.po Dual License GPL or LGPL without any version number - this is wrong /* Popt Library Test Program Number Too -- a real world test of popt bugs -- Copyright (C) 1999 US Interactive, Inc. This program can be used under the GPL or LGPL at your whim as long as this Copyright remains attached. */ 0 \artifact.unpacked\popt-1.14\test2.c 3) Other Licenses GPL V2 or later Reference with Autoconf Exception_cct This file is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version
Re: AW: INFO: Popt 1.14 license evaluation - response appreciated
On Mar 14, 2011, at 7:41 AM, Hulin, Gerlinde (E D EA SOL D TC1) wrote: Hello, I was wondering if you could respond to my question ? Are ou going to get the issues sorted out regarding the license texts ? Is the most important issue -- highlighted in RED -- the fact that the POPT license is no longer available at ftp://ftp.rpm.org/pub/rpm/dist If that's the issue, you will have to contact the owners of the rpm.org domain (i.e. Red Hat) and tell them to put their license where oit belongs. I've left the original license text in POPT exactly as written for historical continuity. But if changing a URI is all that you want/need, I can/will change the URI. 73 de Jeff Best regards, Gerlinde Hulin _ Von: Hulin, Gerlinde (E D EA SOL D TC1) Gesendet: Thursday, March 03, 2011 10:15 AM An: 'popt-devel@rpm5.org' Cc: Hufnagel, Michael (E D EA SOL EN) Betreff:INFO: Popt 1.14 license evaluation - response appreciated Hello, Am doing the liecense clearing for open source components in our department. I did the clearing your component popt1.4. I scanned all files of popt 1.14 for license informations. Unfortunately there are issues regarding the popt licenses. Most of the licenses does not match with the MIT license. Some files are under the GPL (wich is irreversible !), and 2 license informations are not correct. Jef Johnson told me to post to this email in order to get the issues sorted out. On the home page popt is stated as MIT style license http://freshmeat.net/tags/mitx-consortium-license. But here is what I found: 1) Global Licenses MIT style - disclaimer X Consortium for promotion Copyright (c) 1998 Red Hat Software Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium. 36 \artifact.unpacked\popt-1.14\COPYING 294 \artifact.unpacked\popt-1.14\install-sh 3070 \artifact.unpacked\popt-1.14\config.sub 2250 \artifact.unpacked\popt-1.14\config.guess 14434 \artifact.unpacked\popt-1.14\ltmain.sh 125 \artifact.unpacked\popt-1.14\popthelp.c 47 \artifact.unpacked\popt-1.14\poptint.h 0 \artifact.unpacked\popt-1.14\test1.c 0 \artifact.unpacked\popt-1.14\po\sv.po 0 \artifact.unpacked\popt-1.14\po\vi.po 0 \artifact.unpacked\popt-1.14\po\fr.po 0 \artifact.unpacked\popt-1.14\po\pl.po 0 \artifact.unpacked\popt-1.14\po\de.po 44 \artifact.unpacked\popt-1.14\popt.h 49 \artifact.unpacked\popt-1.14\poptparse.c 2797 \artifact.unpacked\popt-1.14\popt.3 50 \artifact.unpacked\popt-1.14\poptconfig.c 2) Other Licenses – NO NOT USE – license issue Open Issue... /* (C) 1998-2002 Red Hat, Inc. -- Licensing details are in the COPYING file accompanying popt source distributions, available from ftp://ftp.rpm.org/pub/rpm/dist. */ ... This strin occurs in many places but the this link here is not correct Wrong license information # This file is distributed under the same license as the popt package. # This file is put in the public domain. 0 \artifact.unpacked\popt-1.14\po\fi.po Dual License GPL or LGPL without any version number - this is wrong /* Popt Library Test Program Number Too -- a real world test of popt bugs -- Copyright (C) 1999 US Interactive, Inc. This program can be used under the GPL or LGPL at your whim as long as this Copyright remains attached. */ 0 \artifact.unpacked\popt-1.14\test2.c 3) Other Licenses GPL V2 or later Reference with Autoconf Exception_cct This file is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your
Re: popt with msvc?
On Oct 28, 2010, at 12:50 AM, Matt Arsenault wrote: Other than those failed tests, I do now have it working without the need to revert to an older version. If you send alon a patch for VS, I'll try to carry that in popt (I don't do VS or Windoze but ..) There's a patch for Xcode in popt already ... popt changes little enough that VS might be maintainable in spite of bit rot. The gnulib approach used by Mingw is way way overkill for a teensy library like POPT imho. 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Re: popt with msvc?
On Oct 27, 2010, at 12:25 AM, Matt Arsenault wrote: On Oct 26, 2010, at 11:27 PM, Jeff Johnson wrote: What test are failing? Like long long and double, the tests are quite complete over data types and It Really Doesn't Matter: hardly ant program needs/uses long long and double CLI options. test1 - 19, 20, 21, 22, 23, 60, 61 19-23 are testing alias/exec functionality from test-poptrc. If you can live without alias/exec (and you likely can, only rpm makes heavy/serious use of popt alias/exec afaik). 60-61 are just cosmetic --help comparisons. If popt alias/exec isn't functional, then the --help display will fail too. test3 - 51, 52, 53 I just sort of haphazardly threw things together until it built, so I may have broken something. I quickly added cmake to try building it since I have no idea how to get autotools to work with VS. Yes the AutoFu chains are getting rather daunting. The basic trick with autotools, is use configure, and avoid using the autotools, on tricky platforms. I haven't a clue how to get AutoFu to work with VS either. You might try older POPT tarballs. The basic functionality of POPT hasn't changed since forever, nor has the API, nor are there significant bugs. Older tarballs might have less AutoFu. 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
A better example usage case for POPT_ARG_BITSET
One of the more subtle additions in popt-1.16 is
POPT_ARG_BITSET
This a Bloom filter data type that parses option
arguments as a CSV and adds to the bit set.
What is difficult to describe is why/how Bloom filters
work (wikipedia does an excellent job) and particularly
how to describe
Why would I _EVER_ need Bloom filters doing CLI option parsing?
So here's a perfectly sane usage case that I'll be implementing in RPM
shortly.
One of the mysteries in RPM is %config handling. In short, a file path
marked with %config is handled with a state machine that tries to
avoid accidentally discarding local customizations during upgrade.
However, what is often needed is a means (through POPT options) to
disable some functionality, or also to negate the behavior (like grep -v)
Since there are like 300K possible file paths on existing systems, this is a
rather
complex task if arrays/lists are used to attach a per-file disabler using POPT.
One can certainly fiddle up the application code to process POPT
options in any number of ways.
Or (as I'm gonna do) one can let POPT_ARG_BITSET do most of the heavy lifting
for you
handling a large estimated universe (in this case potentially 300K file paths)
with almost no additional application code needed. This POPT helper
int poptBitsChk(poptBits bits, const char * s);
will return TRUE/FALSE depending on whether a string was mentioned (or not).
There's already a a test case (popt/tdict.c) based on /usr/share/dict/words
in popt code.
Fiddle around with tdict.c if you wish to attempt using POPT_ARG_BITSET
in some application.
Wayne: RSYNC+POPT likely has zillions of usage cases for POPT_ARG_BITSET
with large unknown(a priori) populations of file paths (and enablers/disablers
attached to a specific path). Note that the default expected population size
in POPT is way too small for 300K+ file paths (from popt/popt.h):
#define _POPT_BITS_N1024U/* estimated population */
#define _POPT_BITS_M((3U * _POPT_BITS_N) / 2U)
#define _POPT_BITS_K16U /* no. of linear hash combinations */
but can be overridden by assigning values to
/*...@unchecked@*/
extern unsigned int _poptBitsN;
/*...@unchecked@*/
extern unsigned int _poptBitsM;
/*...@unchecked@*/
extern unsigned int _poptBitsK;
There's also the attached bit of deep dark chocolate from RPM code (where
the POPT_ARG_BITSET Bloom filter implementation in POPT was swiped from)
if interested in an optimal set of parameters with a false positive
failure rate less than specified for a given estimated population size.
See the appended routine.
(aside)
I left rpmbfParams() (the mnemonic is RPMBF == RPM Bloom Filter, duh) routine
out of POPT largely because of the math complexity and no clearly established
usage case for POPT_ARG_BITSET so far. I also hadn't implemented rpmbfParams()
yet at the time I did the port to POPT ;-).
I almost certainly will include some variant of the attached routine
to estimate optimal bitset parameters in POPT 2.0 before I'm done.
hth
73 de Jeff
===
void rpmbfParams(size_t n, double e, size_t * mp, size_t * kp)
{
static size_t _nmin = 10;
static size_t _n = 1;
static size_t _nmax = 1 * 1000 * 1000 * 1000;
static double _emin = 1.0e-10;
static double _e = 1.0e-4;
static double _emax = 1.0e-2;
size_t m;
size_t k;
/* XXX sanity checks on (n,e) args. */
if (!(n = _nmin _n = _nmax))
n = _n;
if (!(e = _emin _e = _emax))
e = _e;
m = (size_t)((n * log(e)) / (log(1.0 / pow(2.0, log(2.0 + 0.5);
k = (size_t) ((m * log(2.0)) / n);
if (mp) *mp = m;
if (kp) *kp = k;
}
__
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
Re: POPT 2.0: version stamping in includes
On Jun 18, 2010, at 9:03 PM, Michael Jennings wrote:
Ah, okay. I guess I was envisioning for runtime checks:
void *f = dlopen(NULL, RTLD_LAZY);
if (dlsym(f, popt_something)) {
...
}
Any idea how portably POSIX dlsym() is in 2010?
There's the GNUish dlvsym() that needs figgering if I attempt
compatibility with symbol versioning too.
73 de Jeff
__
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
Re: Disallowing args
On Jun 5, 2010, at 11:39 AM, Wayne Davison wrote: Here's something that was recently fixed for the popt that is included with rsync: rejecting an arg to an option that doesn't take an arg. Attached is a patch. A new error code, POPT_ERROR_UNWANTEDARG, was created to make the error message nice. This handles both -l=value and --long-arg=value where neither one is supposed to take a value. ..wayne.. arg-error.patch Hmmm, I'll get this fix worked in down the road. Certainly a bug. (aside) All this code is actively being simplified for POPT 2.0 so that I can more easily follow the logic path. Meanwhile in the future, if you could send a patch against some POPT release that I can find (I tried all the way back to the popt-1_11-release tag, patch doesn't apply), or at least provide some hint about what code repository the patch applies to (the patch itself seems to have been edited), that would certainly help. Please also note that I won't accept any patch that doesn't pass make check regression tests. If you _REALLY_ want to make sure that odd POPT corner cases like args given to an option return an error, adding a reproducer to the test cases too. 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
POPT 2.0: another malloc issue
This is another ancient (circa 1997) in POPT.
The argv returned through certain interfaces ('d have
to check, but the issue bites me every couple months)
has everything allocated in one contiguous blob so
that an experienced/lazy programmer just has to do
const char * s = bing bang boom;
int ac = 0;
const char ** av = NULL;
int rc = poptParseArgvString(s, ac, av_;
if (av)
free(av);
i.e. no loop over that strings in the array is needed.
The issue is that there are corner cases that do
not conform to general expectations, where a string
can be reallocated, or otherwise manipulated freely
without considering whether the memory is part of
an argv array returned from POPT.
(As an experienced/lazy programmer I use this POPT (and RPM)
functionality a fair amount).
The problem is that in order to attempt tuples by parsing
a CSV attached to a single option like
--option bing,bang,boom
uniformly with POPT_ARG_ARGV (and I can think of several other
usage cases for tuples), how the memory was allocated
affects how tuple merges are implemented.
I'm likely to change the behavior in POPT 2.0 to allocate
all the strings independently to simplify tuple merging.
Which means that applications will have to explicitly write the
loop (and its trivial to add a helper function in POPT) to do
for (i = 0; i ac; i++)
if (av[i]) free(av[i])
free(av);
But I can be convinced otherwise, and perhaps *shudder* arrange
for a Have it your own way! selector logic if I absolutely MUST
do that.
Personally I'd rather see KISS even if incompatible. It just
ain't that big a deal to write a loop where needed.
But -- as always -- this means I'm forced to debug everyone's
widdle valgrind exercises if/when POPT is abused and used incorrectly.
73 de Jeff
__
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
POPT 2.0: renaming to popt2 vs. loader maps and ELF versioned symbols
There's a thread on gcrypt-devel that is directly relevant to POPT library compatibility and symbol handling: http://lists.gnupg.org/mailman/listinfo/gcrypt-devel (You will get a 403 Forbidden for the gcrypt-devel archives, go find a mirror) And for reference, there's Drepper's deep dark chocolate DSO guidance here: http://people.redhat.com/drepper/dsohowto.pdf (aside) And gcrypt-devel is unrelated to generating 64bit RSA keypairs using a RPN calculator in POPT. ;-) There are (at least) two approaches to adding symbol versioning and visibility to a DSO library. 1) use a loader map already implemented in POPT, just opt-in and so never used. 2) use GCC __attribute__((visibility)) voo-doo Using __attribute__ can be used to do opt-out symbol hiding without the modest overhead of loader maps. The other (and different) issue is symbol versioning. The connection to visibility is largely because a loader map can also be used to add symbol versions quite easily. (aside) There's also the distantly related/coupled issue (if I choose to add ELF symbols to the RPN calculator) of using dlsym() # in POSIX and should be portable versus dlvsym()# GNU extensions necessary with versioned symbol lookup I can/will chase down a straw-man implementation using loader maps and versioned symbols for compatibility over the next month because I _REALLY_ think renaming to popt2 is just wussiness. 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Re: Disallowing args
On Jun 5, 2010, at 12:48 PM, Wayne Davison wrote: On Sat, Jun 5, 2010 at 8:56 AM, Jeff Johnson n3...@mac.com wrote: but --foo bar returns bar in the argument list? Yes. The user may well have wanted it to be in the arg list. There's no way for the program to know that the user didn't just toss some options in the middle of some args (which I do all the time these days, like starting my rsync source/dest args, and then tossing in a --remove-source-files, --backup, or what-not at wherever I am in the list), so I wouldn't want to see an error for something like this: rsync -aiv --del file --remove-source-args some/dir host:/dest/dir ... just because --del doesn't take an arg. The other way to fix the error is to morph --foo=bar behavior to be identical to --foo bar, i.e. an extra argument failure. I don't see how that would work for something like rsync that takes any number of command-line args outside the options. Well determistic behavior works, just not very useful ;-) I'm not arguing, just there's issues like POSIX_ME_HARDER that get factored into --foo=bar error handling, all mind numbingly tedious. Your patch is likely what I will add, I'm a very lazy schmuck. Anything you want to see in POPT 2.0? I'm collecting features ... A couple ideas off the top of my head: An incrementing option -- repeated use adds 1 to the variable instead of setting it to the same value. How about a full blown RPN calculator to handle not just increment/decrement, but all arithmetic operations, on option values. infix - postfix just isn't that hard, and the whole mess is just a teensy stack and a switch. I've got several RPN calculators floating around in RPM code these days that could be dropped into POPT without any effort whatsoever. Nor is a RPM calculator very hard to implement. Multiple long names separated by | in the long-name string (though that could really just be defined as an alias, it might be nice to auto-gen the alias). There's already Bloom filters fin POPT 1.16 for opaquely handling multiple option value strings (the bar in --foo bar). That partly addresses the need for fewer popt table entries/aliases/execs. (aside) The usage case is for RPM which has 100 hash algorithm names buried into popt tables, and I need to collapse down to a single popt table entry for my own maintenance sanity. Full pattern matching, either *RE or fnmatch(3), would not be hard. The pdksh extensions to fnmatch globs would handle your specific alternation request. And POPT is already linking fnmatch(3). If you have any other RFE's just drop a note here ... and blame Rusty Russell for encouraging POPT 2.0 ;-) 73 de Jeff
Re: Disallowing args
On Jun 5, 2010, at 12:42 PM, Danny Sung wrote:
On 06/05/2010 8:56 AM, Jeff Johnson wrote:
(aside)
Anything you want to see in POPT 2.0? I'm collecting features ...
Since you're collecting features... =)
One thing I'd like is to extend the help/usage capability just a little.
Well reworking --help is one of the primary motivations for POPT 2.0.
Hysterically, encoding was rammed into POPT by GNOME way back when.
While the scheme is workable, the original change _HAD_ to be done
as an addition to preserve ABI, and so all of the i18n for --help
is rather awkwardly done.
To make matters worse, another patch from GNOME wanted POPT to undertake
localization transforms from UTF8 to whatever was in LC_ALL etc.
While iconv(3) makes the character encoding transform as trivial as deciding
the to - from locales, its hardly trivial to make that decision reliably
based solely on a desired LC_ALL environment variable (the from locale cannot
be determined reliably, and hackery like trying various from locales like
glib does is hardly sound engineering).
The killer is that the data needed to find --help alignment reproducers is
application resident,
and application chosen, and the GNOME developers who forced the iconv(3) into
POPT just aren't helping with reproducers. I have no interest in supporting
POPT functionality that noone is willing to help maintain any more.
So the short answer is:
All of the --help handling needs to be scrapped and reworked in POPT
2.0.
For starters, 30-40% of the code is --help related, and _ALL_ of the bug reports
I've heard for years are
But --help columns don't align!
Enough already ... bring on the --help bulldozers!
So I'd like to be able to have more descriptive usage parameters (eg. to
cover left-over arguments). I addition it'd be nice to have a little
description/summary of what the program to do. I realize you can do this
with a custom help function. But it'd be nice if these were standard
elements.
Other niceties might be:
- a way to indicate parameters enabled by default (eg. having a '*' next to
them in the help)
There is already
#define POPT_ARGFLAG_SHOW_DEFAULT 0x0080U /*! show default value
in --help */
as well as
#define POPT_ARGFLAG_OPTIONAL 0x1000U /*! arg may be missing */
wired into --help output.
- An additional structure that could provide detailed help on argDescription
elements. For example, rpm has an option:
--queryformat=QUERYFORMATuse the following query format
It'd be nice if there were a section of help that could describe what
QUERYFORMAT could be. So obviously it's not going to be a full man page, but
perhaps it could just show supported % format options or something like that.
This is a different issue. There is already the 6th/7th fields in POPT tables,
the problem is really information overload from --help. At some point man(1)
or info(1) is a better approach than --help, particularly for RPM which has
an entire eco-system of option processing and far too many options
to be reasonably displayed with --help (because the info is not very helpful).
(aside)
Note that RPM is _ROUTINELY adding
#define POPT_ARGFLAG_DOC_HIDDEN 0x4000U /*! don't show in
help/usage */
there's zillions of options in RPM that noone knows about. My guess is that
there's
more hidden than displayed options these days, usually disablers that noone
ever
really needs to use.
I use something like this in my code, but I have specific keys like
[replaceme] that I convert. And I put just the acceptable keys in the help
cause I just need a quick reminder of what they are. But it clutters the
option help a little. I'd be fine with specifying FORMATSTRING in the
option help. Then have perhaps an arg help down below that shows what values
FORMATSTRING understands.
I'm not sure exactly how you could support these without breaking
compatability with existing apps. Perhaps a new datatype something like:
FYI: POPT 2.0 is all about breaking compatibility. There's only so much
that can be done with obscure overloadings of the existing 7-tuple in
popt table entries.
enum poptOptionType {
POPT_OPTION,
POPT_ARG,
POPT_USAGE,
};
union poptDetailedOption {
poptOptionType optType;
struct poptShortOption;
struct poptArgHelp;
struct poptUsageHelp;
}
struct poptShortOption { /* same as poptOption but with a type field */
poptOptionType optType;
const char * longName;
char shortName;
int argInfo;
void * arg;
int val;
const char * descrip;
const char * argDescrip;
};
I'm not sure this would give the desired effect.. but the thought would be
that it'd turn your options table to something like this:
poptDetailedOption optionsTable[] = {
{ POPT_OPTION, bps, 'b', POPT_ARG_INT, speed, 0,
signaling rate in bits-per-second, BPS },
{ POPT_ARG, FORMATSTRING, Possible
Re: Test failure for popt 1.16
On May 10, 2010, at 7:57 PM, Pieter Bowman wrote: I did builds of popt 1.16 on a number of our systems here. Test 59 failed on a number of the systems with the following output: The fix for the failure in popt-1.16 make check is likely (I have easy no easy means of testing across all the platforms that you have) as simple as the atached patch. If you can confirm that the patch works, I'll re-roll the popt-1.16 tarballs, and re-release (it hasn't been announced anywhere) the popt-1.16 tarball. hth 73 de Jeff == Index: test1.c === RCS file: /v/rpm/cvs/popt/test1.c,v retrieving revision 1.44 diff -p -u -w -r1.44 test1.c --- test1.c 26 Jul 2009 16:38:25 - 1.44 +++ test1.c 11 May 2010 18:50:39 - @@ -252,7 +252,7 @@ int main(int argc, const char ** argv) resetVars(); /*...@=modobserver@*/ /*...@-temptrans@*/ -optCon = poptGetContext(test1, argc, argv, options, 0); +optCon = poptGetContext(test1, argc, argv, options, POPT_CONTEXT_KEEP_FIRST); /*...@=temptrans@*/ (void) poptReadConfigFile(optCon, ./test-poptrc); (void) poptReadDefaultConfig(optCon, 1); __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Re: [PATCH] added pkgconfig support for popt
On Jul 24, 2009, at 11:03 AM, Ralf S. Engelschall wrote: Only true if you install POPT into standard system locations. But if I install POPT with --includedir=/usr/include/popt --libdir=/usr/lib/ popt the pkg-config file still allows me to build and link against POPT without having to know its particular install locations (assuming that at least the popt.pc is in a standard location or at least in the PKG_CONFIG_PATH -- or whatever the name of this variable is). So, yes and no, it can be considered a little bit overkill for POPT, but in general it is already useful just because it encapsulates/remembers the install locations. Point taken. Good, there's a usage case at least. There's so much fussing with popt for little known purpose. 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Fwd: Adding poptSecuritySaneFile to popt-1.15?
(resent, dunno where the 1st message went)
I kind of like the idea of using a '@' before
a file path as an attention marker to increase
the file validation checks, and so I'm likely to
refactor the functionality out of rpm and into
popt-1.15 as part of simplifying rpm configuration/initialization.
At the same time, I will probably add a new
poptReadConfigFiles() method whose argument
will be a colon separated list of configuration
file paths to read.
Any other opinions?
73 de Jeff
Begin forwarded message:
From: Jeff Johnson n3...@mac.com
Date: December 18, 2008 3:15:33 PM EST
To: popt-devel@rpm5.org
Subject: Adding poptSecuritySaneFile to popt-1.15?
I'm currently catching up with popt changes, including adding a
--[no]option toggle flag and a precedence group to options, and
perhaps attaching a table to carry named bits in a single option enum.
I see this code in rpm using popt: basically paths can be prefixed
with
an '@' attention marker, which will do stricter sanity checks
on files as in:
int rpmSecuritySaneFile(const char *filename)
{
struct stat sb;
uid_t uid;
if (stat(filename, sb) == -1)
return 1;
uid = getuid();
if (sb.st_uid != uid)
return 0;
if (!S_ISREG(sb.st_mode))
return 0;
if (sb.st_mode (S_IWGRP|S_IWOTH))
return 0;
return 1;
}
...
/* work-off each resulting file from the path element */
for (i = 0; i ac; i++) {
const char *fn = av[i];
#if defined(RPM_VENDOR_OPENPKG) /* security-sanity-check-rpmpopt-and-
rpmmacros */
if (fn[0] == '@' /* attention */) {
fn++;
if (!rpmSecuritySaneFile(fn)) {
rpmlog(RPMLOG_WARNING, existing POPT
configuration file \%s\ considered INSECURE -- not loaded\n, fn);
continue;
}
}
#endif
(void)poptReadConfigFile(optCon, fn);
av[i] = _free(av[i]);
}
Should I drop the '@' prefix on file path attention! convention
into popt instead?
Its easy enough to do, although perhaps access(2) rather
than stat(2) might be slightly better owner checking.
73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
Re: Some umlaut issues in popt 1.15 (the old thing again)
On May 25, 2008, at 9:19 AM, Robert Scheck wrote:
Hello all,
I've claimed that I can see some umlaut issues with popt 1.14 and I
really
would like to see it solved, now. Reproducer is for me as follows.
Using
popt-1.13-3 from Fedora 8, 9 or Rawhide, I simply executed the
following:
$ [EMAIL PROTECTED] rpm --help rpm-1.13-iso
$ LANG=de_DE.UTF-8 rpm --help rpm-1.13-utf
Using popt 1.15 from latest CVS checkout, I also did the following:
$ [EMAIL PROTECTED] rpm --help rpm-1.15-iso
$ LANG=de_DE.UTF-8 rpm --help rpm-1.15-utf
Results are now as follows using file(1) to compare:
popt-1.13-iso: ISO-8859 text# as expected
popt-1.13-utf: UTF-8 Unicode text # as expected
popt-1.15-iso: Non-ISO extended-ASCII text # NOT as expected
popt-1.15-utf: UTF-8 Unicode text # as expected
Hmmm, file(1) can be tricked and is perhaps unreliable as a test.
I've written this toy reproducer script:
#!/bin/bash
sudo make -C /X/popt/popt-1.13 install /dev/null echo ==
1.13-3.fc9 installed
[EMAIL PROTECTED] rpm --help /tmp/popt-1.13-iso
LANG=de_DE.UTF-8 rpm --help /tmp/popt-1.13-utf
diff -u /tmp/popt-1.13-{iso,utf}
sudo make -C /X/src/popt install /dev/null echo == 1.15
installed
[EMAIL PROTECTED] rpm --help /tmp/popt-1.15-iso
LANG=de_DE.UTF-8 rpm --help /tmp/popt-1.15-utf
diff -u /tmp/popt-1.15-{iso,utf}
With popt-1.13-3.fc9 installed (with the popt-1.13-popt_fprintf patch
applied), I see
differences rendering umlaut's between the output from the 2 locales
for both 1.13 and 1.15.
(aside) the description column _IS_ aligned, which is/was the rather
feeble reproducer
for this issue during popt-1.14 release.
And here is what file(1) has to say on the matter:
[EMAIL PROTECTED] popt]$ file /tmp/popt-1.13-iso
/tmp/popt-1.13-iso: ISO-8859 English text
[EMAIL PROTECTED] popt]$ file /tmp/popt-1.15-iso
/tmp/popt-1.15-iso: Non-ISO extended-ASCII English text
reproducing your results here.
I have most certainly removed the encoding conversion in popt-1.14 so
that the --help
columns are aligned. Which likely explains the file(1) output, iconv
is _NOT_ being
performed, because doing the iconv conversion visibly destroyed the --
help column alignment.
So a little more help please. What problem should I focus on? Having
only American
English kinda hampers my abilities to fix this issue, I really don't
know what to expect
with de_DE locale encoded display output (although I'm way more
familiar with
rpm --help than kudzu or random GNOME --help). I can most easily
detect column alignment
issues, duh.
And sure I want to fix _ALL_ the popt problems. Just which one first?
Once my LANG is [EMAIL PROTECTED] for popt = 1.14, the ISO-8859 text
seems not
sane to be written somehow. Please note, that popt 1.13, I was
using here
is not the vanilla one, the following patch was applied (no matter
what it
does exactly):
http://cvs.fedora.redhat.com/viewcvs/*checkout*/devel/popt/
popt-1.13-popt_fprintf.patch
Greetings,
Robertpopt-1.13-iso.gzpopt-1.13-utf.gzpopt-1.15-
iso.gzpopt-1.15-utf.gz
__
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
Re: Some umlaut issues in popt 1.15 (the old thing again)
Here's a summary from trying to sort the dueling umlaut encoding -
--help column alignment
issue which started here:
http://rpm5.org/community/popt-devel/0061.html
jbj_ what I need if you wish me to fix in popt-1.15 is a better
test. we don't disagree that popt-1.15-iso is broken. we do disagree
whether popt-1.13-iso works or not. I will sort the file(1)
difference, but I don't think that test is gonna be strong enough
(but I will find out tomorrow).
jbj_ i expect columns to stop aligning, the other problem. I can
work the column alignment rather than the umlauts destruction if you
prefer. but I have dueling bugs atm.
jbj_ I'll also see about adding a make check reproducer to popt.
your popt-devel post with rpm --help reproducer is exactly what I
needed to attempt. thank you.
rsc np. Let's see how testing develops. A replay of one of the
previous patches is not such hard as I got you - if needed for 1.14+
or so
On May 25, 2008, at 6:34 PM, Jeff Johnson wrote:
On May 25, 2008, at 9:19 AM, Robert Scheck wrote:
Hello all,
I've claimed that I can see some umlaut issues with popt 1.14 and
I really
would like to see it solved, now. Reproducer is for me as follows.
Using
popt-1.13-3 from Fedora 8, 9 or Rawhide, I simply executed the
following:
$ [EMAIL PROTECTED] rpm --help rpm-1.13-iso
$ LANG=de_DE.UTF-8 rpm --help rpm-1.13-utf
Using popt 1.15 from latest CVS checkout, I also did the following:
$ [EMAIL PROTECTED] rpm --help rpm-1.15-iso
$ LANG=de_DE.UTF-8 rpm --help rpm-1.15-utf
Results are now as follows using file(1) to compare:
popt-1.13-iso: ISO-8859 text# as expected
popt-1.13-utf: UTF-8 Unicode text # as expected
popt-1.15-iso: Non-ISO extended-ASCII text # NOT as expected
popt-1.15-utf: UTF-8 Unicode text # as expected
Hmmm, file(1) can be tricked and is perhaps unreliable as a test.
I've written this toy reproducer script:
#!/bin/bash
sudo make -C /X/popt/popt-1.13 install /dev/null echo
== 1.13-3.fc9 installed
[EMAIL PROTECTED] rpm --help /tmp/popt-1.13-iso
LANG=de_DE.UTF-8 rpm --help /tmp/popt-1.13-utf
diff -u /tmp/popt-1.13-{iso,utf}
sudo make -C /X/src/popt install /dev/null echo == 1.15
installed
[EMAIL PROTECTED] rpm --help /tmp/popt-1.15-iso
LANG=de_DE.UTF-8 rpm --help /tmp/popt-1.15-utf
diff -u /tmp/popt-1.15-{iso,utf}
My script here was flawed, ... libdir=/lib ... was also needed for
make install. Now fixed.
With popt-1.13-3.fc9 installed (with the popt-1.13-popt_fprintf
patch applied), I see
differences rendering umlaut's between the output from the 2
locales for both 1.13 and 1.15.
(aside) the description column _IS_ aligned, which is/was the
rather feeble reproducer
for this issue during popt-1.14 release.
And here is what file(1) has to say on the matter:
[EMAIL PROTECTED] popt]$ file /tmp/popt-1.13-iso
/tmp/popt-1.13-iso: ISO-8859 English text
[EMAIL PROTECTED] popt]$ file /tmp/popt-1.15-iso
/tmp/popt-1.15-iso: Non-ISO extended-ASCII English text
reproducing your results here.
I have most certainly removed the encoding conversion in popt-1.14
so that the --help
columns are aligned. Which likely explains the file(1) output,
iconv is _NOT_ being
performed, because doing the iconv conversion visibly destroyed the
--help column alignment.
So a little more help please. What problem should I focus on?
Having only American
English kinda hampers my abilities to fix this issue, I really
don't know what to expect
with de_DE locale encoded display output (although I'm way more
familiar with
rpm --help than kudzu or random GNOME --help). I can most easily
detect column alignment
issues, duh.
And sure I want to fix _ALL_ the popt problems. Just which one first?
hth
73 de Jeff
__
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
Permit arg units (like 100Kb), add getdate?
While using popt in another program, I came across 2 usage cases that might be usefully internalized in popt. One usage case was an attempt to specify a memory limit as --memory 16777216 Adding unit scaling, e.g. --memory 16Mb --memory 16384Kb would not be hard to add using something like POPT_ARG_INT | POPT_ARGFLAG_UNITS with the usual Kb/Kib Mb/Mib Gb/Gib tokens to prescale. Another possible popt-1.15 usage case is getdate.y, which is wonderfully useful for time/date argument input. While it is rather easy to use getdate.y through a popt callback, perhaps its time to push getdate.y into libpopt, and add a POPT_ARG_DATE distinguished method to make it as easy as possible to use getdate.y. I'm also seeing a need for a KEY=VALUE comma separated list popt sub-table option parser (there's a mouthful ;-) I'm starting to see --option K1=V1,K2=V2,K3=V3 occurrences more often. I can think of a couple ways to use popt to recursively parse KEY=VALUE settings, either by keeping track of a chained popt table that is used iff a specific --option is encountered, or by overloading the pointer field to be used as a option specific subtable parse. Opinions? 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Named bit fields ala ancient BSD %b format
While I'm thinking about popt features, here is another:
The BSD kernel (iirc) devised a means to map bit files to names
using a %b format.
A string was used to map bit# - name. E.g. here's an example
from some rpmdb code that I use for output purposes
static const char * dbtFlags =
\20\1APPMALLOC\2ISSET\3MALLOC\4PARTIAL\5REALLOC\6USERMEM
\7DUPOK;
The same technique (of nerdy embedded octal in a string) can be used
to assign names to bits in a set,
permitting option parsing (using the format string above):
--option PARTIAL,DUPOK
to save the value 0x48 (i.e. (1 3) | (1 6)) into the target
storage.
OTOH, generating the %b format string can be tedious, and perhaps
a more general table like (this from LZMA):
typedef struct {
const char *name;
uint64_t id;
} name_id_map;
with name = NULL as table end sentinel should be done.
Opinions?
73 De Jeff
__
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
popt-1.14 release
I've built popt-1.14 for release in the next couple of days. The SRPM for popt-1.4 that I will be releasing is at http://wraptastic.org/pub/i386-linux/SRPMS/popt-1.14-1.src.rpm Enjoy! 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Re: Allow equal after a short option
On Mar 9, 2008, at 10:14 AM, Wayne Davison wrote:
On Sun, Mar 09, 2008 at 12:42:37AM -0500, Jeff Johnson wrote:
/bin/echo on my system is unmodified from
Fedora 9 coreutils-6.10-4.fc9.i386
Interesting. So, what do you get with a manual run?
/bin/echo --foo --bar
/bin/echo -- --foo --bar
[EMAIL PROTECTED] popt]$ /bin/echo --foo --bar
--bar
[EMAIL PROTECTED] popt]$ /bin/echo -- --foo --bar
--foo --bar
Heh, I believe the answer starts to become clearer:
The echo(1) from Fedora coreutils-6.10-4.fc9.i386 dares to be
different.
The root cause is what I needed to understand. Thanks for the patience.
I see all the option information output literally, including the --.
What do you get if you try a make check using that perl -e patch
instead of echo? Does it still succeed for you?
I added the longArg = NULL, am seeing the same failure on test # 9.
Very weird. I don't see how my change could affect a short option's
separated arg. Attached is an even safer version of the change that
ensures that the only time it ever sets longArg to NULL is if the
longArg was set to oe + 1 upon finding an equal sign.
I also tried using valgrind in the test suite:
result=`valgrind $builddir/$prog $*`
and the test-run didn't turn up any errors.
Your
longArg = NULL;
patch seems fine. The issue I'm seeing is here:
...
origOptString++;
if (*origOptString != '\0')
con-os-nextCharArg = origOptString;
#ifdef NOTYET /* XXX causes test 9 failure. */
con-os-nextCharArg = origOptString +
(*origOptString == '=');
#endif
}
if (opt == NULL) return POPT_ERROR_BADOPT; /* XXX can't
happen */
...
If I turn that line on, popt make check (and rpm -q) breaks.
There's a class of problems, particularly with recursions like popt,
that can fool valgrind.
Meanwhile, below is a rewrite of POPT_fprintf, essentially identical
to the man vsnprintf
example. See what you think ...
(aside) I swear I wrote this code before, likely early June 2007,
when the need for va_copy
on amd64/ppc was discovered. The issue was discussed at some length
on [EMAIL PROTECTED]
during the 1st two weeks of June 2007.
int
POPT_fprintf (FILE * stream, const char * format, ...)
{
char * b = NULL, * ob = NULL;
size_t nb = 1;
int rc;
va_list ap;
while ((b = realloc(b, nb)) != NULL) {
va_start(ap, format);
rc = vsnprintf(b, nb, format, ap);
va_end(ap);
if (rc -1 (size_t)rc nb)
break;
if (rc -1)/* glibc 2.1 */
nb = rc + 1;
else/* glibc 2.0 */
nb += (nb = 1 ? 100 : nb);
ob = b;
}
rc = 0;
if (b != NULL) {
#ifdef HAVE_ICONV
ob = strdup_locale_from_utf8(b);
if (ob != NULL) {
rc = fprintf(stream, %s, ob);
free(ob);
} else
#endif
rc = fprintf(stream, %s, b);
free (b);
} else if (ob != NULL)
free(ob);
return rc;
}
73 de Jeff
__
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
Re: Allow equal after a short option
On Mar 8, 2008, at 12:02 PM, Wayne Davison wrote: I think it would be nice to allow an equal to separate a short option letter from its abutting argument. e.g. these commands using the test1 executable would all work the same: ./test1 -2 foo ./test1 -2=foo ./test1 -2foo ./test1 --arg2 foo ./test1 --arg2=foo Since this has been a syntax error in released versions of popt, this should not cause a compatibility problem. This fix requires my prior patch to make sure that short-option parsing doesn't have longArg set. I think the patch is a reasonable extension, but there's more to do: [EMAIL PROTECTED] popt]$ make check ... make check-TESTS make[2]: Entering directory `/X/src/popt' Running tests in /X/src/popt Running test test1 - 1. Running test test1 - 2. Running test test1 - 3. Running test test1 - 4. Running test test1 - 5. Running test test1 - 6. Running test test1 - 7. Running test test1 - 8. Running test test1 - 9. Test test1 -2 foo failed with: arg1: 0 arg2: rest: foo != arg1: 0 arg2: foo Would you mind looking at the problem? Thanks ... 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Re: popt-1.13 release
On Jan 11, 2008, at 2:49 AM, Takao Fujiwara - Tokyo S/W Center wrote: Actually I'm not sure what is your problem. Which applications do you try? It seems recently some of modules, GTK, Bonobo and GNOME session, uses goption. When the application uses --help options, it includes the output of both goption and popt. goption has the current encoding but popt is UTF-8 then you may encounter the problem. Could you apply POPT_fprintf() for popt options only? In principle POPT_fprintf could be applied for popt options only. The context of popt options only is extremely difficult to identify however, because popt behvaior is driven by application data. No matter what, I'm not going to be accepting patches for popt such as POPT_fprintf (or the Solaris signed character fix) without explicit regression tests in the future. And I'm likely to revert to Robert Scheck's patch for the next version of popt as that seems to be closest to being explicitly identified as working. 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Re: popt-1.13 release
On Dec 19, 2007, at 2:26 AM, Robert Scheck wrote: Moin Jeff, On Wed, 19 Dec 2007, Jeff Johnson wrote: See if the attached patch (the minimum necessary reversion to popt-1.12 afaict) fixes your linux problems. If the patch fixes the linux problems, I'll see if I can rework the Solaris patch to not break linux. Yes, it really fixes my Linux problems: OK, thanks for verify. Would you mind checking the attached patch? It adds POPT_next_char() to undo POPT_prev_char() wide character ptr positioning, and pretty much (if it works for you) points the finger at POPT_fprintf() being broken somehow. Note that POPT_fprintf() is supposed to translate from UTF-8 to whatever locale is desired using iconv(3). GNOME wishes to distribute only UTF-8 locale files, so popt gets to do the final conversion using iconv(3). 73 de Jeff d Description: Binary data
Re: popt-1.13 release
On Dec 15, 2007, at 7:34 PM, Robert Scheck wrote: Yes the colum spacing looks better, but whenever an umlaut (ä, ö, ü, Ä, Ö, Ü, ß) or similar should be displayed, it aborts somehow. Please note, that I can't reproduce when having LANG=C for example. Oh, and it's NOT kudzu having this problem, it's popt - so [EMAIL PROTECTED] rpm --help has just the same problem. See if the attached patch (the minimum necessary reversion to popt-1.12 afaict) fixes your linux problems. If the patch fixes the linux problems, I'll see if I can rework the Solaris patch to not break linux. 73 de Jeff d Description: Binary data
