Bug#411635: getopt_long_only: short vs. long option ambiguity
Hello,
I disagree on 2 points:
1. The bug should be assigned to libc6 instead of libc6-i686,
because it's equally applicable to all architectures,
including i386 of course.
2. The severity isn't minor in any way, because:
* the bug potentially affects a lot of packages that
use getopt_long_only()
* it introduces a whole new class of ambiguities that
were not even mentioned in getopt's documentation _and_
were ignored in implementation altogether, AFAIS
* the current getopt_long_only()'s behaviour is completely
against any expectation or common sense, that greatly
increases risk of programming errors and bugs
Citing man getopt_long_only:
getopt_long() and getopt_long_only() also return the
option character when a short option is recognized.
For a long option, they return val if flag is NULL,
and 0 otherwise. Error and -1 returns are the same
as for getopt(), plus ’?’ for an ambiguous match or
an extraneous parameter.
* there's no option `-l' is ambiguous warning message
generated at all, or '?' returned for short vs. long
option ambiguity. (you get the '?' and warning when
there's amgiguity between 2 long options (e.g. '-longa'
vs. '-longb')).
* curent resolution of ambiguities is inconsistent, because
it prefers long option in one case and short one in all
others (see below):
There's no description about how the current implementation
resolves short vs. long option ambiguities, and the actual
rule is the next (JFYI):
a) lone (unbundled) short option
'-l': '-l' vs. '--long'
= short option takes precedence
b) bundled short option in beginning of a bundle
'-ls': '-l' '-s' vs. '--long' '-s'
= short option is chosen ('-l' '-s')
c) bundled short option in middle of a bundle
'-Sls': '-S' '-l' '-s' vs. '-S' '--long' '-s'
= short option is chosen ('-S' '-l' '-s')
d) bundled short option at end of a bundle
'-sl': '-s' '-l' vs. '-s' '--long'
= long option is preferred here ('-s' '--long')
--
IMHO this doesn't qualify as a minor bug.
Regards,
xrgtn
Bug#352139: getopt optional arg does not work as documented
tag 352139 wontfix thanks However, this does not seem to be the case. Actually it works quite similar. When run: [EMAIL PROTECTED]:/tmp$ a.out -a a arg is: (null) Correct behaviour. $ ./a.out -afoo a arg is: foo [EMAIL PROTECTED]:/tmp$ a.out -a hello a arg is: (null) Now. This case is difficult. The string hello could also be just a normal filename argument. I think the glibc handles this case correctly and thus mark the bug as wontfix. Helmut signature.asc Description: Digital signature
Processed: Re: getopt optional arg does not work as documented
Processing commands for [EMAIL PROTECTED]: tag 352139 wontfix Bug#352139: getopt optional arg does not work as documented There were no tags set. Tags added: wontfix thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#136727: marked as done (Confused examples in (libc.info.gz)Variable Substitution)
Your message dated Tue, 27 Feb 2007 12:43:16 +0100
with message-id [EMAIL PROTECTED]
and subject line Confused examples in (libc.info.gz)Variable Substitution
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
---BeginMessage---
Package: glibc-doc
Version: 2.2.5-3
In the node (libc.info.gz)Variable Substitution, the exact same
variable reference -- ${foo%%r*} -- is given in the examples for %, %%,
#, and ##. Additionally, each of # and ## has the exact same last
paragraph as % or %% has, respectively. % needs a % removed from
${foo%%r*}. %% looks fine. # and ## must be fixed to say that they
match from the beginning rather than the end, and their examples must
be fixed, too.
-- THEWeirdo [EMAIL PROTECTED]
---End Message---
---BeginMessage---
In the node (libc.info.gz)Variable Substitution, the exact same
variable reference -- ${foo%%r*} -- is given in the examples for %, %%,
#, and ##. Additionally, each of # and ## has the exact same last
paragraph as % or %% has, respectively. % needs a % removed from
${foo%%r*}. %% looks fine. # and ## must be fixed to say that they
match from the beginning rather than the end, and their examples must
be fixed, too.
This bug (now applying to glibc-doc-reference) seems to be silently
fixed in unstable (2.3.6-1) and experimental (2.5-1).
Helmut
signature.asc
Description: Digital signature
---End Message---
Processed: Re: date: long timezone offset sighlently changed
Processing commands for [EMAIL PROTECTED]: tag 160683 moreinfo Bug#160683: date: long timezone offset sighlently changed There were no tags set. Tags added: moreinfo thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#160683: date: long timezone offset sighlently changed
tag 160683 moreinfo thanks On Thu, Sep 12, 2002 at 12:10:48PM -0700, Blars Blarson wrote: Gnu date apperently siglently limits the timezone offset to 23, so the above command will SOMETIMES show todays date instead with no error message. (The SOMETIMES makes this even harder to debug.) This breaks portable and older shell scripts. (I realize there are better ways of doing this using Gnu date, but they don't work on solaris or aix.) Could you be more precise on SOMETIMES and maybe include steps to reproduce? Does it only happen for specific dates? Which? Does it depend on the architecture? Which? Helmut signature.asc Description: Digital signature
Bug#412312: iconv fails when converting Catalan ela geminada character
No it does not, iconv is meant as a 1:1 converter. If you want more subtle and evolved conversions, please use recode. ŀ and Ŀ do not exist in latin1/9 so it's valid not to be able to convert them. Please do consider that echo $foo | iconv -f utf8 -t latin1 | iconv -f latin1 -t utf8 should be identity (if every character in $foo exists in utf8). With your request, it's no longer true, as converting e.g. ŀ back and forth would give you l· in utf-8 as well, which is incorrect. Hi Pierre, My real intention was gaining the ability to use ŀ and Ŀ in gettext translations, with the certainty that gettext will manage to convert them for people still using latin1. I was under the impression that iconv relied on the same backend that gettext does, and so that fixing iconv would automaticaly fix gettext. But as you put it, sounds like that's not the case. Do you know what is needed to archieve what we want? -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412312: iconv fails when converting Catalan ela geminada character
On Tue, Feb 27, 2007 at 10:35:31PM +0100, Robert Millan wrote: No it does not, iconv is meant as a 1:1 converter. If you want more subtle and evolved conversions, please use recode. ŀ and Ŀ do not exist in latin1/9 so it's valid not to be able to convert them. Please do consider that echo $foo | iconv -f utf8 -t latin1 | iconv -f latin1 -t utf8 should be identity (if every character in $foo exists in utf8). With your request, it's no longer true, as converting e.g. ŀ back and forth would give you l· in utf-8 as well, which is incorrect. Hi Pierre, My real intention was gaining the ability to use ŀ and Ŀ in gettext translations, with the certainty that gettext will manage to convert them for people still using latin1. I was under the impression that iconv relied on the same backend that gettext does, and so that fixing iconv would automaticaly fix gettext. But as you put it, sounds like that's not the case. Do you know what is needed to archieve what we want? I think you can pass //TRANSLITERATE or sth like that to do what you want (I think). I'm not sure it's iconv that provides that though. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpFiTtewEb2w.pgp Description: PGP signature
Bug#412312: iconv fails when converting Catalan ela geminada character
Pierre Habouzit a écrit : On Tue, Feb 27, 2007 at 10:35:31PM +0100, Robert Millan wrote: No it does not, iconv is meant as a 1:1 converter. If you want more subtle and evolved conversions, please use recode. ŀ and Ŀ do not exist in latin1/9 so it's valid not to be able to convert them. Please do consider that echo $foo | iconv -f utf8 -t latin1 | iconv -f latin1 -t utf8 should be identity (if every character in $foo exists in utf8). With your request, it's no longer true, as converting e.g. ŀ back and forth would give you l· in utf-8 as well, which is incorrect. Hi Pierre, My real intention was gaining the ability to use ŀ and Ŀ in gettext translations, with the certainty that gettext will manage to convert them for people still using latin1. I was under the impression that iconv relied on the same backend that gettext does, and so that fixing iconv would automaticaly fix gettext. But as you put it, sounds like that's not the case. Do you know what is needed to archieve what we want? I think you can pass //TRANSLITERATE or sth like that to do what you want (I think). I'm not sure it's iconv that provides that though. If I remember correctly, you have to add //TRANSLIT to the destination code. But you should really use recode for that which has be designed for that. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
was margo
attorney Mark McDonald said outside court. He's very distraught and scared Critical Care Inc, symbl: .CTCX. This one is an easy doubler @ 65 cents wont last long Expected target : $ 3.00 Critical Care Announces Expansion of Cost Containment Activities Business Wire (Fri, Feb 16) Critical Care to Acquire Health Care Company Business Wire (Wed, Jan 31) GET IN TOMORROW, This one is shoo in to DOUBLE because the case is continuing.Last week's fire was stoked by Santa Ana winds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#210355: marked as done (tzconfig vs tzsetup: both in base)
Your message dated Tue, 27 Feb 2007 21:35:10 -0500 with message-id [EMAIL PROTECTED] and subject line well.. has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: libc6 Version: 2.3.2-4 Severity: normal We currently have two programs in base, tzconfig and tzsetup, that do the same things. I thought I asked for this a long time ago, but I think tzconfig should be removed from the distribution. If there is a lot of documentation that refers to tzconfig, or a lot of users who expect it, I would have no problem with renaming tzsetup to tzconfig. If you're not familiar with tzsetup, I wrote it because we needed a program to be called from base-config using the debconf UI. It is based on tzconfig and it walks through the same configuration as does tzconfig, and if run with debconf's dialog frontend, it looks rather like tzconfig. In addition, it has a -g switch which lets it set GMT. Internally I belive that tzsetup is better, since it does not rely on a hardcoded list for its top-level menu, and instead bases it on the contents of /usr/share/zoneinfo. It also lets the user back up if they pick the wrong menu item. It's just a waste of space and confusing to have two programs in the base system that do the same thing. If you agree, you could close bug #182981, maybe #179837, and reassign #122874 to base-config. -- see shy jo pgplZCAPDtSS4.pgp Description: PGP signature ---End Message--- ---BeginMessage--- Well, I removed tzsetup from base, since base-config is gone. -- see shy jo signature.asc Description: Digital signature ---End Message---
