Re: rm: cannot remove directory `coreutils-7.3/lib': Directory not empty

l l wrote: > In the end, > > I given up LFS64, installed fedora 64. > The problem solved. Thanks for letting us know. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

[PATCH] Add ability to print ACL's from ls

The following patches add support for printing ACL's via 'ls -e/-E'. This is supported on platforms that have some sort of acl_to_text function, which is most of the platforms that the acl module supports. I tested this on Linux, OpenSolaris, and FreeBSD. -- David From 2b81cf5a5eb32c5e500c892fd11

Re: test-memchr failure on rawhide

Bruno Haible writes: > Does memchr(ptr,c,0) for ptr != NULL now access ptr[0] or not? The as-if rule allows everything as long as a strictly compliant program cannot tell the difference. > In both cases the memchr implementation is deviating from traditional > behaviour and provoking crashes fo

Re: test-memchr failure on rawhide

Andreas Schwab wrote: > s/worked fine earlier/invoked undefined behviour/ In your interpretation of the C99 standard: can you please tell, regarding this sentence in section 7.21.5.1, and assuming a call memchr(ptr,c,n) with ptr != NULL and n >= 0:   "The memchr function returns a pointer to the

Re: [PATCH] Add ability to print ACL's from ls

Hello David, > The following patches add support for printing ACL's via 'ls -e/-E'. > This is supported on platforms that have some sort of acl_to_text > function, which is most of the platforms that the acl module supports. Unfortunately, having GNU 'ls' (and maybe later GNU 'chmod') use the pla

Re: [PATCH] Add ability to print ACL's from ls

On Sat, May 9, 2009 at 3:36 AM, Bruno Haible wrote: > > Unfortunately, having GNU 'ls' (and maybe later GNU 'chmod') use the > platform's native syntax for ACLs does not allow the user to use the > same commands on different platforms, and does not allow for platform > independent scripts. I cons

Re: test-memchr failure on rawhide

Bruno Haible writes: > What is "the object"? See section 3.14 in the C standard. region of data storage in the execution environment, the contents of which can represent values Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5

grep -R hangs when issued upon certain directory

I am not sure what grep does not like about my home directory, but as soon as I issue a "grep -R Testtext *" in my home dir grep will start to hang not triggering any further disk access after a short while. Tried to get a backtrace by installing coreutils-debuginfo and coreutils-debugsource but

cpio terminates prematurely if its output is piped through head

cpio terminates prematurely if its output is piped through head: using cpio-2.9-75.45 cpio -idv './usr/include/*' 'usr/include/*' <$a 2>&1 ... fully unpacks the archive $a cpio -idv './usr/include/*' 'usr/include/*' <$a 2>&1 | head ... unpacks apparently non-deterministically just some but not al

Re: grep -R hangs when issued upon certain directory

Elmar Stellnberger wrote: > I am not sure what grep does not like about my home directory, but as > soon as I issue a "grep -R Testtext *" in my home dir grep will start to > hang not triggering any further disk access after a short while. Bugs in grep should be reported to bug-grep. But you ha

Re: cpio terminates prematurely if its output is piped through head

Elmar Stellnberger wrote: > cpio terminates prematurely if its output is piped through head: > using cpio-2.9-75.45 Bugs in cpio should be reported to bug-cpio. But you have contacted the bug-coreutils list instead. We don't know much about cpio here. The bug reporting address for most programs

Re: test-memchr failure on rawhide

Andreas Schwab wrote: > > What is "the object"? > > See section 3.14 in the C standard. > > region of data storage in the execution environment, the contents of > which can represent values And in the context of memchr's return value: "The memchr function returns a pointer to the loca

[bug #26512] ls: it's no longer possible to change the default (NORMAL) text color

URL: Summary: ls: it's no longer possible to change the default (NORMAL) text color Project: GNU Core Utilities Submitted by: None Submitted on: Sat 09 May 2009 04:38:02 PM UTC Catego

Re: test-memchr failure on rawhide

Bruno Haible writes: > Andreas Schwab wrote: >> > What is "the object"? >> >> See section 3.14 in the C standard. >> >> region of data storage in the execution environment, the contents of >> which can represent values > > And in the context of memchr's return value: The context is irr

Re: test-memchr failure on rawhide

Bruno Haible writes: > Do you mean to say that none of the functions > memchr > memcmp > memcpy > memmove > memset > wmemchr > wmemcmp > wmemcpy > wmemmove > wmemset > may be called with arguments ptr = NULL and n = 0 ? Yes. C99 7.2.21p2 says: Where an argument declare

Re: grep -R hangs when issued upon certain directory

Bob Proulx schrieb: > Elmar Stellnberger wrote: >> I am not sure what grep does not like about my home directory, but as >> soon as I issue a "grep -R Testtext *" in my home dir grep will start to >> hang not triggering any further disk access after a short while. > > Bugs in grep should be repo