Re: dirent.d_ino check

[EMAIL PROTECTED] (Eric Blake) writes: > It looks like everywhere that coreutils looks for d_ino, it uses > macros that default to 0 on systems without support, so that d_ino > of 0 falls back to the stat() family. No, actually, it skips such entries. However, historically (pre-POSIX?) many impl

Re: [bug-gnulib] [bug-gnulib] fts portability fix for hosts with unusual pointer semantics

On Mon, May 09, 2005 at 10:04:34PM +0200, Bruno Haible wrote: Bruno> Paul Eggert wrote: [...] Paul> I installed this patch into coreutils. Paul> Paul> +static int Paul> +fts_compar (void const *a, void const *b) Paul> +{ Paul>/* ... */ Paul> + return pa[0]->fts_fts->fts_compar (pa, pb); Paul>

Re: [bug-gnulib] Re: getopt and Solaris 10

Derek Price wrote: >>>2005-05-05 Paul Eggert <[EMAIL PROTECTED]> >>> >>> * lib/getopt.m4 (gl_GETOPT): Check for Solaris 10 getopt, and >>> avoid needless checks. >>> >>> >>Yes, this also works for me. >> >> > >Okay, one more revision, to actually check if the -+ registers as

Buggy mv --interactive --reply=no, hopefully solved here

Hi, even after testing the recent anonymous checkout of cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/coreutils co coreutils I still believe there is a bug in `mv'. Try to run mv --interactive --reply=no plain1 plain2 and given both plains exist, plain2 gets overwritten. This is not expect

Re: dirent.d_ino check

> As I understand it, that test will work only if you happen to run > it in an NTFS file system. > > How about if we just modify the test to always report failure when > building for Cygwin? That's simple and it's better than sometimes > returning the wrong answer. That's fine for now, and much

Re: dirent.d_ino check

As I understand it, that test will work only if you happen to run it in an NTFS file system. How about if we just modify the test to always report failure when building for Cygwin? That's simple and it's better than sometimes returning the wrong answer. _

Re: [bug-gnulib] Re: getopt and Solaris 10

Derek Price <[EMAIL PROTECTED]> writes: > + myargv[[0]] = "conftest"; > + myargv[[1]] = "-+"; This doesn't null-terminate myargv. But I still don't get why the change is needed. It sounds like you're assuming Solaris 11 getopt might get fixed? But even in that case, the curren

Re: [bug-gnulib] [bug-gnulib] fts portability fix for hosts with unusual pointer semantics

Bruno Haible <[EMAIL PROTECTED]> writes: > (I have not yet seen any platform where the ABI treats 'void *' pointers > differently than any data pointers. The basic reason that 'void *' exists > at all in C is to permit this kind of cast.) The basic problem, as I understand it, is that some archit

dirent.d_ino check

The check in m4/d-ino.m4 is currently just a link test, which means it fails to detect that cygwin returns bogus d_ino data on readdir() of NTFS filesystems (but it matches stat() on FAT filesystems). I'm not sure how to test for a working d_ino in cross-compilation, so the fallback to my new r

Re: [bug-gnulib] [bug-gnulib] fts portability fix for hosts with unusual pointer semantics

Paul Eggert wrote: > That reminds me; fts.c violates C89 in a couple of places, which could > lead to core dumps on unusual hosts where void * and FTSENT const ** > have differing runtime representations. I installed this patch into > coreutils. > > +static int > +fts_compar (void const *a, void c

Re: Filename Globbing issues on Win32?

> I'm actually using the coreutils compiled and bundled with the > GnuWin32 and UnxUtils projects. Both projects still refer back to the > original Gnu coreutils lists. I may crosspost this thread over to > those guys if I'm not totally crazy on this. :) Your examples were from the Windows shell,

Re: Filename Globbing issues on Win32?

I'm actually using the coreutils compiled and bundled with the GnuWin32 and UnxUtils projects. Both projects still refer back to the original Gnu coreutils lists. I may crosspost this thread over to those guys if I'm not totally crazy on this. :) And moving the asterisk outside the quotes didn't

Re: [bug-gnulib] Re: getopt and Solaris 10

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ...I know you already agreed... ...I just thought this was interesting... In fact, Solaris 10 is the one actually sticking to the letter of the POSIX spec here, not that I think that assuming argv[0] should not be processed is going to hurt the GNU v

Re: [bug-gnulib] Re: getopt and Solaris 10

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthias Kurz wrote: >Hi. > >One more clarification. Maybe one or the other missed my last comments >on . It was me, >who introduced the "'+' myth". Well, it is not a myth. I studied the test pro

Re: [bug-gnulib] Re: getopt and Solaris 10

On Mon, May 09, 2005, Derek Price wrote: [...] > I did read this correctly in your report. If anyone else sees a need > for an actual test for correct optind=0 behavior, then they are welcome > to write one, but I decided the point was moot at the moment since > detecting the "+" bug, just as val

Re: [bug-gnulib] Re: getopt and Solaris 10

Hi. One more clarification. Maybe one or the other missed my last comments on . It was me, who introduced the "'+' myth". I "analysed" the problem wrong in the beginning. It is not exactly the "+" that makes the problem, but the fact, that the

Re: [bug-gnulib] Re: getopt and Solaris 10

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthias Kurz wrote: >I do not think that this is a Solaris _bug_. - From the point of view of the GNULIB getopt.m4 tests, if it doesn't behave like GNU getopt, that is a bug. :) >I'd bet that every system that does not use GNU getopt will suffer

Re: [bug-gnulib] Re: getopt and Solaris 10

On Mon, May 09, 2005, Derek Price wrote: [...] > Okay, one more revision, to actually check if the -+ registers as an > option or not. This fits the autoconf paradigm of testing for the bug, > even if it is using AC_TRY_RUN. This way, if Sun fixes the problem in a > later Solaris release, we sho

Re: [bug-gnulib] Re: getopt and Solaris 10

Matthias Kurz wrote: >On Thu, May 05, 2005, Paul Eggert wrote: > > > >>Derek Price <[EMAIL PROTECTED]> writes: >> >> >> >>>I prefer door #2. Trivial patch attached: >>> >>> >>Thanks, but I'd rather use AC_CHECK_DECL, so I installed this instead, >>into both coreutils and gnulib. Does

Re: [bug-gnulib] Re: getopt and Solaris 10

Regardless, since using an optind = 0 is not specified as supported by POSIX, whereas optind = 1 is, and since using optind = 1 in place of optind = 0 in CVS would avoid this problem on all platforms and with all versions of getopt (supporting optind = 0 provides no additional functionality that I

fts portability fix for hosts with unusual pointer semantics

Jim Meyering <[EMAIL PROTECTED]> writes: > I've hesitated to add coreutils' fts.c to gnulib partly because > I didn't know of any other package that used it. Also, in order > to remove some of those limitations, I had to change numerous types > of fts.h's struct members. That means packages that

Re: Filename Globbing issues on Win32?

> OK, first off, I'm on Win32 (XP) using 5.3 of coreutils. > > I have been knocking my head on this and I'm feeling *really* stupid. > I swear, I'm unix literate, but I can't seem to get the following to > work without cheating: > > cp -uvp "c:\dir with space\long path\*" k:\path >From context,

Re: Filename Globbing issues on Win32?

On Mon, 9 May 2005, Adin Burroughs wrote: >OK, first off, I'm on Win32 (XP) using 5.3 of coreutils. > >I have been knocking my head on this and I'm feeling *really* stupid. >I swear, I'm unix literate, but I can't seem to get the following to >work without cheating: > >cp -uvp "c:\dir with space\l

Filename Globbing issues on Win32?

OK, first off, I'm on Win32 (XP) using 5.3 of coreutils. I have been knocking my head on this and I'm feeling *really* stupid. I swear, I'm unix literate, but I can't seem to get the following to work without cheating: cp -uvp "c:\dir with space\long path\*" k:\path I call this "cheating": (tho

Re: DD converts LF -> CR / LF

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Christopher Faylor on 5/8/2005 5:03 PM: >>Hmm, overriding the explicit advice of the system administrator? How >>common is it for file systems to be mounted in text mode? Why would >>anyone do such a thing? If it's sufficiently rare, th