[patch #6758] Add support for Atari FreeMiNT OS

URL: Summary: Add support for Atari FreeMiNT OS Project: GNU Core Utilities Submitted by: alanh Submitted on: Sat Feb 28 14:50:24 2009 Category: None Priority: 5 - Nor

Re: [patch #6758] Add support for Atari FreeMiNT OS

On Sat, 2009-02-28 at 17:29 +0100, Jim Meyering wrote: > Alan Hourihane wrote: > > <http://savannah.gnu.org/patch/?6758> > > Summary: Add support for Atari FreeMiNT OS > > Project: GNU Core Utilities > > Thanks for the work. I

Re: [patch #6758] Add support for Atari FreeMiNT OS

Hi Jim, On Sat, 2009-02-28 at 17:29 +0100, Jim Meyering wrote: > Alan Hourihane wrote: > > <http://savannah.gnu.org/patch/?6758> > > Summary: Add support for Atari FreeMiNT OS > > Project: GNU Core Utilities > > Thanks for th

bug#5776: [bug #29349] ls.c missing HAVE_NL_LANGINFO check

URL: Summary: ls.c missing HAVE_NL_LANGINFO check Project: GNU Core Utilities Submitted by: alanh Submitted on: Fri Mar 26 14:04:52 2010 Category: None Severity: 3 - N

bug#5779: [bug #29349] ls.c missing HAVE_NL_LANGINFO check

Follow-up Comment #2, bug #29349 (project coreutils): I've be fine with adding logic to deal with abmon_init returning 0 too. Let me know if I should test something. ___ Reply to this item at: ___

bug#5780: [bug #29349] ls.c missing HAVE_NL_LANGINFO check

Follow-up Comment #3, bug #29349 (project coreutils): Actually, I think it's just because required_mon_width is never initialized to 0 and it's never set in this case. ___ Reply to this item at: _

bug#5783: [bug #29349] ls.c missing HAVE_NL_LANGINFO check

Follow-up Comment #5, bug #29349 (project coreutils): O.k. But the problem is that when abmon_init returns 0 we get the horrible error message for the case that we don't have HAVE_NL_LANGINFO. And given that abmon_init() already contains this check, we should probably just move the check to aroun

[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

[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. _

[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