Re: Explicit interpreter paths considered harmful

l...@gnu.org (Ludovic Courtès) writes: Here's a patch. Likewise, ‘pmccabe2html’ assumes /usr/bin/awk, but I’m not sure what to do here: See the documentation in pmccabe2html -- the recommended way to use the script is already using $(AWK). So I don't think there is any problem, is there?

Re: Explicit interpreter paths considered harmful

Ludovic Courtès wrote: ... because perl eventually execs /bin/sh: 4473 execve(./build-aux/gitlog-to-changelog, [./build-aux/gitlog-to-changelog], [/* 60 vars */]) = 0 4473 execve(/var/run/current-system/sw/bin/perl, [perl, -S, ./build-aux/gitlog-to-changelog], [/* 59 vars */]) = 0 4473

test-utimens.h:105: assertion failed

A (f)utimens test fail on Ubuntu 8.04 LTS: ../../gltests/test-utimens.h:105: assertion failed FAIL: test-fdutimensat ../../gltests/test-futimens.h:109: assertion failed FAIL: test-futimens ../../gltests/test-utimens.h:105: assertion failed FAIL: test-utimens Reproduce with: gnulib-tool --test

Re: Explicit interpreter paths considered harmful

Ludovic Courtès wrote: k...@freefriends.org (Karl Berry) writes: -#!/usr/bin/perl +#!/bin/sh Just to mention that an alternative would be #!/usr/bin/env perl. It won’t work on NixOS, which doesn’t have /usr/bin. (On NixOS, the only “standard” path that can be relied on is

Re: mkdir vs. GPL

Eric Blake wrote: Jim Meyering jim at meyering.net writes: [3/5] dirname-lgpl: adjust clients that don't need full dirname Fallout from the split. In particular, test-mkdir and test-rename no longer need libintl. Meanwhile, openat and friends no longer drag in dirname, but

Re: mkdir vs. GPL

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/30/2009 3:05 AM: I think the only clean solution is to bite the bullet and decide that canonicalize-lgpl is the only module which can provide canonicalize_file_name, which in turn means that coreutils needs to quit

Re: Explicit interpreter paths considered harmful

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/30/2009 2:52 AM: FYI, this appears to work, both when invoked directly, and when invoked as perl gitlog-to-changelog ..., but I'm still on the fence... Is it worth the ugliness, when invoking with $(PERL) is so easy,

Re: Explicit interpreter paths considered harmful

Eric Blake wrote: According to Jim Meyering on 10/30/2009 2:52 AM: FYI, this appears to work, both when invoked directly, and when invoked as perl gitlog-to-changelog ..., but I'm still on the fence... Is it worth the ugliness, when invoking with $(PERL) is so easy, and when the recommended

Re: Explicit interpreter paths considered harmful

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/30/2009 6:00 AM: @@ -1,7 +1,9 @@ -#!/usr/bin/perl +eval '(exit $?0)' eval 'exec perl -wS $0 ${1+$@}' + eval 'exec /usr/bin/perl -wS $0 $argv:q' shouldn't that be perl, rather than /usr/bin/perl? +if 0;

stat() replacement with _LARGE_FILES on AIX

Hi, using stat() replacement on AIX results in these build errors (seen in gzip-1.3.13 on AIX5.3), because AIX defines 'stat' to 'stat64' when _LARGE_FILES is defined (by AC_SYS_LARGEFILE): CC lstat.o lstat.c:62: warning: struct stat declared inside parameter list lstat.c:63: error:

Re: Explicit interpreter paths considered harmful

Eric Blake wrote: According to Jim Meyering on 10/30/2009 6:00 AM: @@ -1,7 +1,9 @@ -#!/usr/bin/perl +eval '(exit $?0)' eval 'exec perl -wS $0 ${1+$@}' + eval 'exec /usr/bin/perl -wS $0 $argv:q' shouldn't that be perl, rather than /usr/bin/perl? I could not arrange for that 2nd eval line

Re: Explicit interpreter paths considered harmful

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/30/2009 6:29 AM: +eval '(exit $?0)' eval 'exec perl -wS $0 ${1+$@}' + eval 'exec /usr/bin/perl -wS $0 $argv:q' shouldn't that be perl, rather than /usr/bin/perl? I could not arrange for that 2nd eval line to

Re: test-utimens.h:105: assertion failed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Simon Josefsson on 10/30/2009 2:32 AM: A (f)utimens test fail on Ubuntu 8.04 LTS: Thanks for the report. Which kernel and which version of glibc? Is it a machine I might have access to, like the gcc compile farm? I can't reproduce

Re: stat() replacement with _LARGE_FILES on AIX

Eric Blake wrote: According to Michael Haubenwallner on 10/30/2009 6:21 AM: Hi, using stat() replacement on AIX results in these build errors (seen in gzip-1.3.13 on AIX5.3), because AIX defines 'stat' to 'stat64' when _LARGE_FILES is defined (by AC_SYS_LARGEFILE): Thanks for the

Re: Explicit interpreter paths considered harmful

Eric Blake wrote: According to Jim Meyering on 10/30/2009 6:29 AM: +eval '(exit $?0)' eval 'exec perl -wS $0 ${1+$@}' + eval 'exec /usr/bin/perl -wS $0 $argv:q' shouldn't that be perl, rather than /usr/bin/perl? I could not arrange for that 2nd eval line to make a difference, so figured

Re: Explicit interpreter paths considered harmful

On 10/30/2009 01:38 PM, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/30/2009 6:29 AM: +eval '(exit $?0)' eval 'exec perl -wS $0 ${1+$@}' + eval 'exec /usr/bin/perl -wS $0 $argv:q' shouldn't that be perl, rather than /usr/bin/perl? I could

Re: Explicit interpreter paths considered harmful

Paolo Bonzini wrote: On 10/30/2009 01:38 PM, Eric Blake wrote: According to Jim Meyering on 10/30/2009 6:29 AM: +eval '(exit $?0)' eval 'exec perl -wS $0 ${1+$@}' + eval 'exec /usr/bin/perl -wS $0 $argv:q' shouldn't that be perl, rather than /usr/bin/perl? ... I'd also change -wS to -S

Re: Explicit interpreter paths considered harmful

On 10/30/2009 04:32 PM, Jim Meyering wrote: I definitely want to keep the -w. If you're writing Perl without warnings enabled, you'd better have a very good reason, and can certainly manage the extra effort of applying s/wS/S/ to those two lines -- along with a comment justifying it, I'd expect.

Re: Explicit interpreter paths considered harmful

Hi, Jim Meyering j...@meyering.net writes: From f8a4d66d651f505d0cd349a7c0be025f1b2e12d0 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Fri, 30 Oct 2009 15:02:02 +0100 Subject: [PATCH] gitlog-to-changelog: remove #!/usr/bin/perl in favor of more portable...

Re: Explicit interpreter paths considered harmful

Ludovic Courtès wrote: Works like a charm on NixOS, both with ./gitlog-to-changelog and “perl gitlog-to-changelog”, thanks! Good! ... While you’re at it, can you update the other scripts under ‘build-aux’ that use /usr/bin/perl? Of course.

Re: Explicit interpreter paths considered harmful

Hi Simon, Simon Josefsson si...@josefsson.org writes: l...@gnu.org (Ludovic Courtès) writes: Here's a patch. Likewise, ‘pmccabe2html’ assumes /usr/bin/awk, but I’m not sure what to do here: See the documentation in pmccabe2html -- the recommended way to use the script is already using

Re: Explicit interpreter paths considered harmful

Jim Meyering wrote: Ludovic Courtès wrote: Works like a charm on NixOS, both with ./gitlog-to-changelog and “perl gitlog-to-changelog”, thanks! Good! ... While you’re at it, can you update the other scripts under ‘build-aux’ that use /usr/bin/perl? Of course. Pushed like this: [Paolo,

Re: Explicit interpreter paths considered harmful

Excellent, thank you all! Ludo’.

vasnprintf warnings

Bruno, is it okay to apply this patch to silence these compiler warnings? | vasnprintf.c:2378: warning: declaration of 'buf' shadows a previous local | vasnprintf.c:1502: warning: shadowed declaration is here Here, using two different local variables buf with different types and nested scopes

Re: stat() replacement with _LARGE_FILES on AIX

Michael Haubenwallner michael.haubenwallner at salomon.at writes: If stat is defined, we can't be positive it was defined to stat64 or some other spelling, like __stat64. I'd feel safer blindly replacing all known spellings, as and when we encounter them. Fine with me. So that I can

Re: [PATCH] exclude: avoid an unwarranted warning

Eric Blake e...@byu.net ha escrit: Like this? Yes, it was one of the ways Jim suggested earlier. See http://lists.gnu.org/archive/html/bug-gnulib/2009-08/msg00435.html Regards, Sergey

Re: more test suite problems

Hi Eric, Eric Blake writes: Subject: [PATCH] fseek: avoid compilation failure when fflush is replaced * m4/fseeko.m4 (gl_REPLACE_FSEEKO): Also replace fseek, if fseek module is in use. --- a/m4/fseeko.m4 +++ b/m4/fseeko.m4 @@ -15,7 +15,7 @@ AC_DEFUN([gl_FUNC_FSEEKO],

Re: [PATCH] exclude: avoid an unwarranted warning

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Sergey Poznyakoff on 10/30/2009 10:52 AM: Eric Blake e...@byu.net ha escrit: Like this? Yes, it was one of the ways Jim suggested earlier. See http://lists.gnu.org/archive/html/bug-gnulib/2009-08/msg00435.html OK then, I've

Re: stat() replacement with _LARGE_FILES on AIX

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 10/30/2009 10:44 AM: Nope, you've done enough. Thanks! Now all I have to do is test that your patch doesn't break Linux or Solaris (that is, either autoconf doesn't set _LARGE_FILES for those platforms, or the use of

autoconf-only projects and gnulib?

Would it be at all feasible for gnulib to support non-automake (just autoconf) projects? If the answer is not at all feasible, that's ok. I'm just asking, not requesting. (I have a potential GNU package whose maintainer already knows autoconf, but not automake. It would be nice if he could use

more warnings patrol

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm committing this, to silence some unused variables, and to make inttostr.c quiet even on older gcc. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9

Re: bootstrap diagnostics: grep: amsnippet.tmp: No such file or directory

Jim Meyering wrote: FYI, before I forget (can't investigate right now)... Running bootstrap for GNU parted, I saw this on fedora rawhide: Copying file ._bootmp/m4/xstrtol.m4 grep: amsnippet.tmp: No such file or directory grep: amsnippet.tmp: No such file or directory grep:

Re: autoconf-only projects and gnulib?

Karl Berry wrote: Would it be at all feasible for gnulib to support non-automake (just autoconf) projects? If the answer is not at all feasible, that's ok. I'm just asking, not requesting. gnulib can be used in projects which don't use Makefile.am so far. But gnulib-tool will create the first

Re: more warnings patrol

Hi Eric, --- a/lib/mktime.c +++ b/lib/mktime.c @@ -147,6 +147,9 @@ const unsigned short int __mon_yday[2][13] = # undef __localtime_r # define __localtime_r localtime_r # define __mktime_internal mktime_internal +time_t __mktime_internal (struct tm *, + struct

Re: more warnings patrol

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 10/30/2009 6:43 PM: Hi Eric, --- a/lib/mktime.c +++ b/lib/mktime.c @@ -147,6 +147,9 @@ const unsigned short int __mon_yday[2][13] = # undef __localtime_r # define __localtime_r localtime_r # define