minor-details merge from gnulib

I installed these gnulib-related changes into coreutils. This should finish most of the merging for now (I hope!). 2004-08-07 Paul Eggert [EMAIL PROTECTED] * lib/canonicalize.h, lib/cycle-check.h, lib/stat-macros.h, lib/strdup.h, lib/strftime.h, lib/xnanosleep.c: Merge from

Bad cp -a behaviour

When using 'cp -a' to copy a directory structure, it has some unexpected behaviour. See the attached Makefile, which compares the behaviour between tar, cpio, and cp. The problem seems to be that when a destination file is written it is done so by opening the file without removing it first. If

Re: UTF8 and printf '%2s' (coreutils 5.2.1)

Hello, I (Tobias Burnus) wrote: /usr/bin/printf 'A%2sB\n' '²' # Prints A²B instead of A ²B In other words: printf counts 2byte UTF-8 characters as two characters instead of one. Re-reading the POSIX standard, I've to admit that coreutils' prinf does the right thing: POSIX requires that the bytes

Sort failed tests

I built coreutils-5.2.1 on an AIX 5.2 box using the vac.C 6.0.0.0 compiler. The commands used to configure and build this was ./configure --prefix=/fsapps/test/fssys make make check The last lines of make check were make[3]: Leaving directory `/fsapps/test/build/coreutils/5.2.1

Portability issue

Hello all :)) I have a portability problem with 'expr'. I have a script that depends on 'expr', namely in the 'substr' expression, and I've noted that this expression is not supported in the SUSv3 standard, so I would like to know (if you have such information, of course) which 'expr's

system.h:214 ?

Hi everyone I decided to compile coreutils for qnx 6.3 and ran into an intersting issue on system.h:214. it uses #if O_BINARY and #else #define O_BINARY 0 well, qnx *DO* define O_BINARY... as 0. :) Gives a bunch of anoying compiler messages, parhaps this should be changed to #ifdef ? /Johan

Re: Bad cp -a behaviour

Tim Waugh [EMAIL PROTECTED] writes: The problem seems to be that when a destination file is written it is done so by opening the file without removing it first. If it is a hardlink to a previous destination file from the same command it will be overwritten. This is required by POSIX. If

Re: Bugs

On Wed, 4 Aug 2004 [EMAIL PROTECTED] wrote: should I send here (possible) bug requests about linux utils? You should if they are GNU coreutils utilities. You can tell whether this is the case by running the util with the --version argument, e.g. $ ls --version ls (coreutils) 5.2.1 Written by

Re: Bad cp -a behaviour

On Tue, 3 Aug 2004, Tim Waugh wrote: When using 'cp -a' to copy a directory structure, it has some unexpected behaviour. See the attached Makefile, which compares the behaviour between tar, cpio, and cp. I might be missing something here; I can't reproduce this with a recent cp (from FC2): $

Re: Bad cp -a behaviour

Andreas Schwab [EMAIL PROTECTED] writes: Tim Waugh [EMAIL PROTECTED] writes: The problem seems to be that when a destination file is written it is done so by opening the file without removing it first. If it is a hardlink to a previous destination file from the same command it will be

Re: system.h:214 ?

Johan [EMAIL PROTECTED] writes: well, qnx *DO* define O_BINARY... as 0. :) Gives a bunch of anoying compiler messages, parhaps this should be changed to #ifdef ? Thanks for the report. I installed this patch: does it work for you? 2004-08-07 Paul Eggert [EMAIL PROTECTED] *

Re: Portability issue

DervishD [EMAIL PROTECTED] writes: I would like to know (if you have such information, of course) which 'expr's out there support 'substr' expressions in addition to the GNU coreutils one, of course. Sorry, haven't a clue. But you shouldn't need substr: you can always get the equivalent by