Re: a pox on trailing white space

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> After looking at trim.c, I searched for all trailing blanks >> in gnulib and found plenty: > > I removed those for I am responsible. > >> If anyone objects to my removing all of them, speak now... > > No objection from me. Thanks. Su

Re: a pox on trailing white space

[EMAIL PROTECTED] (Karl Berry) wrote: > There is no use in removing whitespace in the files below, because the > originals are not in gnulib. Just to pacify you, I will work on > changing them :). Great! I didn't expect that (and didn't mean to nag you). Thanks, Karl.

Error During cpio Make

AlphaServer ES45 with Tru64 5.1B running the built-in ³cc² C complier. source='imaxtostr.c' object='imaxtostr.o' libtool=no \ DEPDIR=.deps depmode=tru64 /usr/bin/posix/sh ../build-aux/depcomp \ cc -DHAVE_CONFIG_H -I. -I. -I.. -g -c imaxtostr.c cc: Error: ./inttypes.h, line 44:

Re: res_nmkquery - duplicate transaction-id across fork

Hi, Please ignore my bug report.   The bug was fixed in glibc 2.5.1. regards, Martin Martin Waite wrote: Hi, I'm using a debian Etch system with glibc-2.3.6 installed. Our application is a daemon process that forks a new process to handle incoming connections.  We have found that the

res_nmkquery - duplicate transaction-id across fork

Hi, I'm using a debian Etch system with glibc-2.3.6 installed. Our application is a daemon process that forks a new process to handle incoming connections.  We have found that the DNS transaction-id for the first DNS query issued by each child process has the same DNS transaction-id.  This po

Re: new module 'propername'

Eric Blake wrote: > it looks like > the extended specifier to --keyword was added in xgettext 0.15, but it > needs literal " in its argument. So, I ended up using this instead: > > --keyword=proper_name:1,'"This is a proper name. See the gettext manual, > section Names."' \ > --keyword=prope

Re: getpass-gnu module: missing dependency on fseeko

Martin Lambers wrote: > the getpass-gnu module should depend on the fseeko module, just like the > getpass module does. > > Martin > > > diff --git a/modules/getpass-gnu b/modules/getpass-gnu > index af493f9..92e2d79 100644 > --- a/modules/getpass-gnu > +++ b/modules/getpass-gnu > @@ -7,6 +7,7 @

Re: a pox on trailing white space

Jim Meyering wrote: > After looking at trim.c, I searched for all trailing blanks > in gnulib and found plenty: I removed those for I am responsible. > If anyone objects to my removing all of them, speak now... No objection from me. > build-aux/gendocs.sh > build-aux/texinfo.tex These file

Re: a pox on trailing white space

There is no use in removing whitespace in the files below, because the originals are not in gnulib. Just to pacify you, I will work on changing them :). build-aux/gendocs.sh build-aux/texinfo.tex doc/COPYING.LESSERv2 doc/COPYING.LESSERv3 doc/Copyright/assign.future.manual doc/Copyright/assign.man

getpass-gnu module: missing dependency on fseeko

Hi, the getpass-gnu module should depend on the fseeko module, just like the getpass module does. Martin diff --git a/modules/getpass-gnu b/modules/getpass-gnu index af493f9..92e2d79 100644 --- a/modules/getpass-gnu +++ b/modules/getpass-gnu @@ -7,6 +7,7 @@ lib/getpass.c m4/getpass.m4 Depe

Re: Feature request - base64 Filename Safe Alphabet

Simon Josefsson <[EMAIL PROTECTED]> wrote: > Hopefully now coreutils can resume tracking gnulib's base64 copy... > sorry for delaying this. Great! Thanks to both of you. Now that gnulib's base64.[ch] are identical to those in coreutils, all I have to do is remove the files from coreutils. Comin

Re: Feature request - base64 Filename Safe Alphabet

Bo Borgerson <[EMAIL PROTECTED]> writes: >> Would you mind creating a patchset that applies to the gnulib git >> repository? > > > Not at all. > > It wasn't very easy to read as a single revision, so I did it in two > steps. The first step is pure addition: New functions and a definition > of the

a pox on trailing white space

After looking at trim.c, I searched for all trailing blanks in gnulib and found plenty: $ g grep -l '[]$' build-aux/gendocs.sh build-aux/texinfo.tex config/srclist-update doc/COPYING.LESSERv2 doc/COPYING.LESSERv3 doc/Copyright/assign.future.manual doc/Copyright/assign.manua

[PATCH] trim.c: avoid a warning from gcc

I've committed this, since Davide doesn't have commit access to gnulib. >From cfc551f783f5bde5457a350fcc99bfc64857573d Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Mon, 19 May 2008 18:10:38 +0200 Subject: [PATCH] avoid a warning from gcc * lib/trim.c (IF_LINT): Define. (t

Re: proper names

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 5/18/2008 5:40 AM: | Thanks for the remarks. I added comments and make the XGETTEXT_OPTIONS variable | augmentation automatic. Based on my m4 discoveries, I think this patch needs some modifications: | + Notice: | + If y

Re: new module 'propername'

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 5/19/2008 6:42 AM: | | Actually, I'm starting to wonder if the culprit is bad documentation in | propername.h. It recommends: | | ~ --keyword=proper_name:1,"This is a proper name. See the gettext | manual, section

Re: new module 'propername'

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 5/19/2008 6:27 AM: | | I'm trying to use it in m4, but am failing to see the desired changes to | the m4.pot file after rerunning xgettext with the modified | XGETTEXT_OPTIONS. It seems like xgettext doesn't understand core

Re: getpass documentation

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> > What's the reason that you mention "from /dev/tty (or stdin)"? Don't other >> > implementations read from /dev/tty or stdin? >> >> Without that part, I found to description to be somewhat ambiguous: it >> could be interpreted

Re: new module 'propername'

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 5/18/2008 7:38 AM: | This module was already presented in | http://lists.gnu.org/archive/html/bug-gnulib/2006-09/msg00055.html | | After fixing this issues mentioned by Ben Pfaff and Paul Eggert, I'm moving it | from GNU

Re: getpass documentation

Bruno Haible <[EMAIL PROTECTED]> wrote: > ..., Solaris 10 (8, even less than PATH_MAX), Cygwin (128). I fixed the typo: * doc/glibc-functions/getpass.texi (getpass): s/PATH_MAX/PASS_MAX/.

Re: getpass documentation

Simon Josefsson wrote: > > What's the reason that you mention "from /dev/tty (or stdin)"? Don't other > > implementations read from /dev/tty or stdin? > > Without that part, I found to description to be somewhat ambiguous: it > could be interpreted as a function that returns a random password, not

Re: getpass alternative [Re: getpass documentation]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Josefsson wrote: > Another problem that I discovered is that gnulib's getpass.c inhibits > signals, so the user cannot press ^C/^Z. This is even more of a problem > when the user needs to type the same password twice: the process may be > stuck

Re: getpass alternative [Re: getpass documentation]

Micah Cowan <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> I'm not sure it is a good idea to recommend use of getpass, possibly >> gnulib could offer a better interface. It could have a parameter to ask >> for confirmation of the password internally. However, I will use >> getpass for n

Re: getpass documentation

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> Thanks, below is an updated patch. > > OK. Are you going to commit that? I'm pushing it now, thanks for comments. >> -Portability problems not fixed by Gnulib: >> +Portability problems fixed by Gnulib module @code{getpass-gnu}: