Re: (sharutils) make distclean removes doc/uudecode.1

Bruce Korb wrote: > The last dinkleberry has to do with libintl. > On OS/X: > > $ ldd ../src/shar > > libintl.so.8 => /usr/local/lib/libintl.so.8 (0x02036000) > > libc.so.6.1 => /lib/libc.so.6.1 (0x02054000) > > libiconv.so.2 => /usr/local/lib/libiconv.so.2 (

Re: bug#8391: chmod setuid & setguid bits

Bruno Haible wrote: > It's because this use of '+' is easy to remember. > "chmod +x" means "add execution permissions". > "chmod -x" means "remove execution permissions". To be pedantic that isn't quite true. To be pedantic it actually is gated by the process umask in effect at that time. You ne

Re: chown, cpio: proposed change for userspec handling of USER:

Jim Meyering wrote: > While writing a few tests for userspec (below), I was surprised to > re-learn that chown USER_NAME: has a special meaning. It is a > shorthand for chown USER_NAME:+$(id -g USER_NAME) ... > I had expected it to be equivalent to this: > chown USER_NAME ... I use it quite often

Re: ls -v is still inconsistent

Kamil Dudka wrote: > Kamil Dudka wrote: > > I'll look at it deeper next week and check if the new regex works in all > > cases. > > The Debian's backport suffix "~bpo${debian_release}+${build_int}" seems to > be safe in the context of this patch. Thanks to the '+' it can be never > matched as a f

Re: ls -v is still inconsistent

Kamil Dudka wrote: > On Friday 20 of March 2009 12:36:38 Bruno Haible wrote: > > Jim Meyering wrote: > > > Perhaps "~" isn't the only character we should treat that way. > > > > I'd say that '~' is pretty special here because it's used as backup file > > suffix by many text editors. Which is not th

Re: SIGPIPE not properly reset with 'trap - PIPE'

Hi Ralf! Andreas Schwab wrote: > Ralf Wildenhues writes: > > I noticed the following bash bug when using gnulib-tool. The script > > below outputs > > > > foo: line 20: echo: write error: Broken pipe > > foo: line 21: echo: write error: Broken pipe > >... > > Please also note that the above error

Re: touch and utimens troubles on new/old software combinations

Daniel Jacobowitz wrote: > Bob Proulx wrote: > > Most common systems only support backward compatibility. I have not > > heard of a system which supported forward compatibility. > > > > In other words, compiling on a platform usually results in an > > executable

Re: touch and utimens troubles on new/old software combinations

Jim Meyering wrote: > Mike Frysinger wrote: > > for example, if you're running a recent version of glibc (say 2.7) > > compiled against recent kernel headers (say 2.6.25) but execute on > > an older kernel (say 2.6.18), then the resulting touch binary will > > attempt to use utimensat() which fails

Re: socklen_t on HP/UX

Dustin J. Mitchell wrote: > As you probably know, on HP/UX, accept, getpeername, et al. take (.., > int *addrlen), not (.., socklen_t *addrlen) unless _XOPEN_SOURCE and > _XOPEN_SOURCE_EXTENDED are defined. However, if these macros are not > defined, socklen_t is still defined. There are a few mo

Re: Problem with anonymous check out using git

Gabriele Bartolini wrote: >I have installed GIT (v. 1.5.4.4) on my system but I cannot > anonymously check out the sources using the instructions on the main > page of the GNUlib project: > > $ git clone git://git.savannah.gnu.org/gnulib.git > mkdir: cannot create directory `': No such file o

Re: gnulib-tool --version

Eric Blake wrote: > What is really needed is a method in git where once a SHA1 prefix becomes > ambiguous, you can still easily choose to resolve the ambiguity in favor > of the oldest commit that matches the prefix. This is on the grounds that > there are times when the user knows that the prefix

Re: email addresses in texinfo

Karl Berry wrote: > I personally don't feel so strongly about such anti-spamification stuff, Me neither. Hiding an email address seems doomed to failure. You can't hide something that other people need to know about to use. > especially for mailing lists, but I don't see any particular harm in

Re: printf failure on HP/UX 10.20 with 6.9.92

Eric Blake wrote: > According to Peter Fales on 2/4/2008 4:00 PM: > |It looks like the system snprintf is buggy. I suspect the '-' > ... > And that violates C99/POSIX. Duplication of the `-' flag should not > disable it. In some defense of HP-UX 10.20 it was released IIRC in 1996 which was

Re: announce: cvs pserver (read-only) access to the git mirror

Jim Meyering wrote: > I've set up for cvs pserver (read-only) access to the git mirror > of gnulib's cvs repository. This is in preparation for discontinuing > the CVS repository in favor of the git one for upstream commits. > > To check out the latest, use this: > cvs -d :pserver:[EMAIL PROTECTE

Re: build failures: string.h vs. HP-UX

Bob Proulx wrote: > That seemed to mostly work. It is still failing under ia64 though. I > think the compiler there has no support for restrict. If I define > restrict to be nothing to disable it completely then the compilation > succeeds. > ... > So apparently the configure

Re: build failures: string.h vs. HP-UX

Jim Meyering wrote: > Actually restrict-detection is working just fine. > The problem is that "config.h" isn't included. That seemed to mostly work. It is still failing under ia64 though. I think the compiler there has no support for restrict. If I define restrict to be nothing to disable it co

Re: fnmatch_loop.c sync from libc

Paul Eggert wrote: > Bob Proulx writes: > > cc -I. -Ae -O -c fnmatch.c > > cc: "fnmatch_loop.c", line 604: error 1588: "is_seqval" undefined. > > Thanks for catching that; I installed this obvious patch. > > 2007-01-23 Pa

Re: build failures: string.h vs. HP-UX

Jim Meyering wrote: > Check out the red columns here: > > http://proulx.com:9000/ > > Maybe a system-provided mempcpy macro is causing trouble? > ... > cc -I. -Ae -O -c mempcpy.c > cc: "string.h", line 39: error 1000: Unexpected symbol: "__dest". > cc: "string.h", line 39: error 1

Re: fnmatch_loop.c sync from libc

Paul Eggert wrote: > 2007-01-23 Paul Eggert <[EMAIL PROTECTED]> > Import the following changes from libc. > 2004-12-01 Jakub Jelinek <[EMAIL PROTECTED]> > * lib/fnmatch_loop.c (internal_fnmatch): Clear is_seqval after > normal_bracket label. > ... > @@ -592,6 +599,9 @@ F

Re: coreutils bootstrapping issue on non-GNU platforms

Paul Eggert wrote: > "James Youngman" <[EMAIL PROTECTED]> writes: > > Doesn't the previous code actually produce the _maximum_ version (that > > is, with sort .. | tail -1)? > > Yes, and thanks for catching that. Hmm, nobody has used this since > December 30? Anyway, I installed this: Thanks fo

Re: coreutils 6.6 HP-UX build error

Responding to a note from Date: Wed, 22 Nov 2006 16:08:27 -0600. Matthew Woehlke wrote: > The OS is 11.00, and I can't tell about the compiler ('cc -v' is giving > some odd output but no version number). Because of historical legacy most of the HP-UX programs report version information using SCC

coreutils bootstrapping issue on non-GNU platforms

Bootstrapping a new architecture from bare metal is often a problematic exercise in circular dependencies. I ran into a case of this while building the coreutils. Bootstrapping coreutils on a pristine HP-UX 11.23 ia64 machine produces the following error: ./bootstrap: gnulib/gnulib-tool --imp

Re: converting gnulib: cvs to git

Paul Eggert wrote: > Simon Josefsson <[EMAIL PROTECTED]> writes: > > I find these markers useful when comparing file dates when updating > > old software, and I think it would be a clear disadvantage if moving > > to git won't make the same thing possible. > > They are controversial. I'd rather r

Re: reliable, incremental git->cvs ?

Sylvain Beucler wrote: > I haven't setup an auto-packing commit hook so may need to have me do > that. I'm planning to add something like in post-update: > > export GIT_DIR=coreutils.git > git-count-objects > # If > 5120k > git repack > git prune A useful reference for update scripts is

Re: coreutils-6.5: yet another C89 problem

Jim Meyering wrote: > Here's what Paul just added to Makefile.maint. > That should do it, as long as you do that build > on a relatively modern Linux system: > > $ grep -C2 ansi Makefile.maint > && (cd src && patch -V never --fuzz=0&& ./configure --disable-largefi

Re: coreutils-6.5: yet another C89 problem

Paul Eggert wrote: > Matthew Woehlke <[EMAIL PROTECTED]> writes: > > > I could probably do it on > > this box, but since it's Linux, it would still be with gcc. > > Even that would be helpful, since our current buildbot doesn't do the > particular combination of GCC options you're interested in.

Re: C++ support (1)

Bruno Haible wrote: > Compiling GNU gettext with a C++ compiler revealed a bug: an assignment > between an 'int' variable and an 'enum' variable that was not intended. Although I am sure it was not intended, what bad consequences would have resulted from the enum and int mixup? > This confirms on

Re: C++ support?

Karl Berry wrote: > Is supporting compilation with C++ of interest? (I'm not arguing for > it, just reporting it, since Nelson went to the trouble of trying it.) My opinion (which counts for very little here) is that while C++ is designed to be as close to C as possible, but no closer, that it is

Re: an introduction to gnulib

Bruno Haible wrote: > Karl Berry wrote: > > -it works on Unix and Windows > > +it works on GNU/Unix and Windows > > Now this is ridiculous. Do you consider a Solaris or a Tru64 system a > "GNU/" system? No, I consider those a Unix system, or at least a Unix-like system. The Unix part would have d

OT: latest stable version not recommended (was: coreutils-cvs build error fixed)

[EMAIL PROTECTED] wrote: > heh, it's nice to get a second opinion, but is there ever a case when > "the latest stable version" is ever _not_ recommended? ;) Yes, actually. gzip is one example. The latest stable version is 1.2.4a but it has been so long since a stable release and many problems

Re: --version output and license specifications

Paul Eggert previously wrote: > "sort --version" could output something like this, say: > > sort (GNU coreutils) 6.2 > Copyright (C) 2006 Free Software Foundation, Inc. > License: GPL v2 . > This is free software. There is NO WARRANTY, to the extent >

Re: problem with gl_ABSOLUTE_HEADER and HP-UX native ANSI C compiler

Paul Eggert wrote: > Thanks for reporting the further problem. I installed this > in both gnulib and coreutils. That fixed all of the current problems and things are building fine again. Thanks for the work there! Bob

Re: problem with gl_ABSOLUTE_HEADER and HP-UX native ANSI C compiler

Eric Blake wrote: > Does this solve it? > Index: m4/stdint.m4 > ... > -ABSOLUTE_STDINT_H="<$gl_cv_absolute_stdint_h>" > -AC_SUBST([ABSOLUTE_STDINT_H]) It is definitely related code. But unfortunately no it does not fix it. Actually things take a turn for the worse. With that change the

Re: problem with gl_ABSOLUTE_HEADER and HP-UX native ANSI C compiler

Paul Eggert wrote: > Bob Proulx writes: > > ./lib/Makefile:ABSOLUTE_STDINT_H = > > ./lib/stdint.h:# include > > Looks like you need to re-run 'config.status'. That won't help. It is in config.status. Look at this: grep ',g > Or do a &#x

Re: problem with gl_ABSOLUTE_HEADER and HP-UX native ANSI C compiler

Paul Eggert wrote: > > However if I change it to use "" inclusion it works. > > OK, thanks, then we might as well try using "" everywhere. I'm more > comfortable with "///..." anyway; the gave me the willies, > since a compiler might think it was a C99 comment. Ew, yes, that does seem disconcer

Re: gl_IGNORE_UNUSED_LIBRARIES sets --as-needed on HP-UX but should not

Paul Eggert wrote: > Thanks for mentioning that. I installed the following to fix this, > and to detect the problem Ralf noted. That seems to have fixed things. It is happy now. Thanks! Bob

gl_IGNORE_UNUSED_LIBRARIES sets --as-needed on HP-UX but should not

For past reference see: http://lists.gnu.org/archive/html/bug-gnulib/2006-06/msg00119.html While building coreutils on HP-UX 11.11 using the native hp c compiler I noticed that gnulib's gl_IGNORE_UNUSED_LIBRARIES causes --as-needed to be inadvertently used where it is not a valid option there.

Re: style question - const char *

Jim Meyering wrote: > Paul Eggert <[EMAIL PROTECTED]> wrote: > > Eric Blake <[EMAIL PROTECTED]> writes: > >> Is there a preference for 'const char *' over 'char const *'? > > > > I prefer putting type qualifiers like "const" after the types they > > modify, as that's more consistent. For example,

Re: [bug-gnulib] Re: quoting in gnulib

Bruno Haible wrote: > Paul Eggert wrote: > > I am using the latest release of Debian GNU/Linux (3.1, released only > > last month), and one of the most widely used browsers (Firefox 1.0.4 > > as maintained by Debian). But I can't read all the characters in that > > web page telling me how to quote

Re: UTF-8 support

James Youngman wrote: > OK, maybe I'm wrong - xterm does use Xt, so if uxterm is a wrapper > around xterm and uxterm still doesn't read .Xdefaults, perhaps I'm > mistaken. The .Xdefaults is not read if the $DISPLAY's xrdb contains resources. Bob ___ b

Re: UTF-8 support

Paul Eggert wrote: > Bruno Haible <[EMAIL PROTECTED]> writes: > > Paul Eggert wrote: > >> I read your email containing accented letters with GNU Emacs 21.4 and > >> Gnus 5.10.6, a combination that supports UTF-8. > > > > The UTF-8 support in Emacs 21.4 is minimal. Some people recommend the > > emac

Re: {base,dir}name // semantics

Eric Blake wrote: > I take it a simple autoconf test is in order (how about just testing > to see if 'ls -di / //' produces 2 different inodes?), and that the > results be used in the gnulib dirname module. Will that be sufficient? If Cygwin is using this then it might be the only active system w