Re: bootstrapping fails with git v1.4.4.4

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Steven Schubiger on 1/10/2008 6:33 AM: | 228 git clone --depth 2 git://git.sv.gnu.org/gnulib || | | causes trouble here. git-clone --depth was not added until git 1.5.0. Either upgrade git (now at 1.5.3.8 upstream), or you must clo

Re: bootstrapping fails with git v1.4.4.4

Steven Schubiger <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED]:~/code/foreign/coreutils$ ./bootstrap > ./bootstrap: Bootstrapping from checked-out coreutils sources... > ./bootstrap: getting gnulib files... > Usage: /usr/bin/git-clone [--template=] > [--use-separate-remote] [--reference ] [--bare

bootstrapping fails with git v1.4.4.4

[EMAIL PROTECTED]:~/code/foreign/coreutils$ ./bootstrap ./bootstrap: Bootstrapping from checked-out coreutils sources... ./bootstrap: getting gnulib files... Usage: /usr/bin/git-clone [--template=] [--use-separate-remote] [--reference ] [--bare] [-l [-s]] [-q] [-u ] [--origin ] [-n] [] I remove

Re: tr '[:upper:]' '[:lower:]' -- misaligned construct

"James Youngman" <[EMAIL PROTECTED]> wrote: > On Jan 5, 2008 11:34 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: >> diff --git a/NEWS b/NEWS >> index 5285d51..5b1b366 100644 >> --- a/NEWS >> +++ b/NEWS >> @@ -2,6 +2,12 @@ GNU coreutils NEWS-*- >> outline -*- >> >

Re: tr '[:upper:]' '[:lower:]' -- misaligned construct

Jim Meyering wrote: > "James Youngman" <[EMAIL PROTECTED]> wrote: > >> On Jan 5, 2008 11:34 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: >>> diff --git a/NEWS b/NEWS >>> index 5285d51..5b1b366 100644 >>> --- a/NEWS >>> +++ b/NEWS >>> @@ -2,6 +2,12 @@ GNU coreutils NEWS

[bug #21999] rm fails completely on systems that don't have dirfd()

URL: Summary: rm fails completely on systems that don't have dirfd() Project: GNU Core Utilities Submitted by: None Submitted on: Thursday 01/10/08 at 16:04 UTC Category: None

[bug #21999] rm fails completely on systems that don't have dirfd()

Follow-up Comment #1, bug #21999 (project coreutils): There's a dirfd substitute for systems that lack it, so it shouldn't be a problem. Which version of coreutils are you using, exactly? And which system is failing? Can you please try the latest snapshot of coreutils, at

[bug #21999] rm fails completely on systems that don't have dirfd()

Follow-up Comment #3, bug #21999 (project coreutils): Oh, I'm using coreutils-6.9 currently. ___ Reply to this item at: ___ Message sent via/by Savanna

[bug #21999] rm fails completely on systems that don't have dirfd()

Follow-up Comment #2, bug #21999 (project coreutils): In config.h I see this /* the name of the file descriptor member of DIR */ /* #undef DIR_FD_MEMBER_NAME */ #ifdef DIR_FD_MEMBER_NAME # define DIR_TO_FD(Dir_p) ((Dir_p)->DIR_FD_MEMBER_NAME) #else # define DIR_TO_FD(Dir_p) -1 #endif And t

Re: [bug #21999] rm fails completely on systems that don't have dirfd()

Alan Hourihane <[EMAIL PROTECTED]> wrote: > And therefore dirfd() is implemented with returning DIR_TO_FD(Dir_p) -1. Thanks. We need to know why it ends up using that value. Please post your config.log file and tell us what type of system you're using. ___

[bug #21999] rm fails completely on systems that don't have dirfd()

Follow-up Comment #4, bug #21999 (project coreutils): I guess if DIR_TO_FD() is -1 and dirfd() is not available, then configure should really abort. The system I'm using is a little obscure, so it's not mainstream, so i guess I'll have to fix it's libc instead. _

Re: [bug #21999] rm fails completely on systems that don't have dirfd()

Alan Hourihane <[EMAIL PROTECTED]> wrote: > I guess if DIR_TO_FD() is -1 and dirfd() is not available, then configure > should really abort. > > The system I'm using is a little obscure, so it's not mainstream, so i guess > I'll have to fix it's libc instead. Look at coreutils' m4/fpending.m4. If

[PATCH] df: add `--total' option

Given that the attached patch works, except that the SIZE argument specified to -B/--block-size parameter doesn't currently make it into the totals, I'd like to hear some opinions how you would make it happen (I have some ideas, but I'd certainly prefer to have some peer- driven effort). Steven

[bug #21999] rm fails completely on systems that don't have dirfd()

Follow-up Comment #5, bug #21999 (project coreutils): Just checked other programs, and ls.c deals with dirfd() returning -1 and falls back to using an alternative. It seems to me that remove.c doesn't check the return status of dirfd() ever failing and tries to do bad things... For example, rem