Vincent Lefevre <[EMAIL PROTECTED]> writes:
> In fact the problem seems to be due to the combining character under
> Mac OS X. The filename É is encoded as 45 cc 81.
Most likely this has something to do with how mbrtowc and/or
wcwidth behaves on MacOS X. Perhaps you can debug the quote_name
func
Thanks very much for looking into that. Some comments:
Dan Hipschman <[EMAIL PROTECTED]> writes:
> + /* This is so the child process won't delete our temp files
> + if it receives a signal before exec-ing. */
> + sigprocmask (SIG_BLOCK, &caught_signals, &oldset);
> + saved_temphead = tem
On 2007-01-15 20:13:02 -0700, Eric Blake wrote:
> According to Vincent Lefevre on 1/15/2007 8:05 PM:
> > Under Mac OS X 10.4.8 with ls (GNU coreutils) 5.97 (installed via
> > MacPorts), in a 80-column terminal (uxterm), I get:
> >
> > $ ls
> > É y123456789012345678901
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Vincent Lefevre on 1/15/2007 8:05 PM:
> Hi,
>
> Under Mac OS X 10.4.8 with ls (GNU coreutils) 5.97 (installed via
> MacPorts), in a 80-column terminal (uxterm), I get:
>
> $ ls
> É y1234567890123456789012345
Hi,
Under Mac OS X 10.4.8 with ls (GNU coreutils) 5.97 (installed via
MacPorts), in a 80-column terminal (uxterm), I get:
$ ls
É y123456789012345678901234567890
x123456789012345678901234567890 z123456789012345678901234567890
instead of:
$ ls
É
On Sat, Jan 13, 2007 at 10:07:59PM -0800, Paul Eggert wrote:
> 3. I can see where the user might be able to specify a better
> algorithm, for a particular data set. For that, how about if we have
> a --compress-program=PROGRAM option, which lets the user plug in any
> program that works as a pipe
On Sat, Jan 13, 2007 at 10:07:59PM -0800, Paul Eggert wrote:
> 3. I can see where the user might be able to specify a better
> algorithm, for a particular data set. For that, how about if we have
> a --compress-program=PROGRAM option, which lets the user plug in any
> program that works as a pipe
<[EMAIL PROTECTED]> writes:
> I wonder if Apple is using the FreeBSD /src/bin tree, then, rather than
> configuring coreutils with --prefix=/ ... let me check on that...
As far as I know, FreeBSD mv merely uses acl_get_fd and acl_set_fd for
ACLs, and coreutils should do that stuff fine. (I have
On 2007-01-10 15:20:46 -0600, Jim Meyering <[EMAIL PROTECTED]> said:
<[EMAIL PROTECTED]> wrote:
I've been running coreutils-6.7 on Darwin/MacOSX 10.4.8 ever
since it went final. The "make check" tests that failed
probably can be explained. Haven't seen any real problems, but
all I usually do
"Daniel Richard G." <[EMAIL PROTECTED]> wrote:
> Building coreutils CVS on AIX 4.3 with GCC 4.1 ends with...
>
> BEGIN
> gcc -std=gnu99 -I.-D_THREAD_SAFE -O0 -g3 -MT readutmp.o -MD -MP -MF
> .deps/readutmp.Tpo -c -o readutmp.o readutmp.c
> In file included from readutmp.h:39,
>
"Jon Grosshart" <[EMAIL PROTECTED]> wrote:
> Alex van Hout <[EMAIL PROTECTED]> wrote:
>> Afther building coreutils 6.7, make check fails on the rm check:
>> one-file-system.
>>
>> The check in "src/rm/one-file-system" is to compare the output of rm to a
>> predefined string.
>>
>> The expected stri
Building coreutils CVS on AIX 4.3 with GCC 4.1 ends with...
BEGIN
gcc -std=gnu99 -I.-D_THREAD_SAFE -O0 -g3 -MT readutmp.o -MD -MP -MF
.deps/readutmp.Tpo -c -o readutmp.o readutmp.c
In file included from readutmp.h:39,
from readutmp.c:24:
/usr/include/utmpx.h:90: er
Hello
Afther building coreutils 6.7, make check fails on the rm check:
one-file-system.
The check in "src/rm/one-file-system" is to compare the output of rm to a
predefined string.
The expected string at "one-file-system" line: 50 is:
rm: skipping `a/b', since it's on a different device
The
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Following Jim's and Paul's ideas for portability of the coreutils to
> BeOS, Woe32 and DJGPP, which all lack an fchdir(), here is a first working
> fchdir module.
>
> The module installs wrappers around open(), close(), opendir(), closedir(),
> dup(), dup2(
14 matches
Mail list logo
