Thanks to everyone for the answers.
Frederik
On Tue, Aug 22, 2006 at 12:29:24PM -0700, Paul Eggert wrote:
> Frederik Eaton <[EMAIL PROTECTED]> writes:
>
> > is there a reason why users wouldn't always want a "copyFile"
> > function to remove the destination first?
>
> Lots and lots and lots of
Jim Meyering <[EMAIL PROTECTED]> writes:
> I think it would be worth maintaining.
Me too. The gnulib stat-time should make it pretty easy. I can write
up a patch if you like.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/
[EMAIL PROTECTED] writes:
> dd if=/dev/zero of=obj/kern/bochs.img~ count=1 2>/dev/null
> /bin/sh: line 1: 5952 Segmentation Fault dd if=/dev/zero
> of=obj/kern/bochs.img~ count=1 2>/dev/null
I don't observe this bug. Perhaps it's a bug in your operating system,
outside of 'dd'? I'm af
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to James Youngman on 8/22/2006 1:58 PM:
>>
>> I thought about this a year or so ago. The obvious thing to do is to
>> change %A@ and friends so that they produce a number which is no
>> longer an integer. I enquired on the bug-findutils mail
"James Youngman" <[EMAIL PROTECTED]> wrote:
> On 6/16/06, James Youngman <[EMAIL PROTECTED]> wrote:
>> On 6/16/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
>> > Jim Meyering <[EMAIL PROTECTED]> writes:
>> >
>> > > find $PWD/* -printf '%A@ %p\n'|sort -nr
>> >
>> > Wow, learn something every day. Th
On 6/16/06, James Youngman <[EMAIL PROTECTED]> wrote:
On 6/16/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
> > find $PWD/* -printf '%A@ %p\n'|sort -nr
>
> Wow, learn something every day. Thanks.
>
> Alas, though, this mishandles files whose time stamp
Simon Josefsson <[EMAIL PROTECTED]> writes:
> If coreutils is updated to sync gnupload from gnulib, which I think
> would be a good idea, please drop gnupload from gnulib's
> config/srclist.txt.
Thanks for the heads-up. I did that, and installed the following
patches to gnulib and coreutils, res
Frederik Eaton <[EMAIL PROTECTED]> writes:
> is there a reason why users wouldn't always want a "copyFile"
> function to remove the destination first?
Lots and lots and lots of reasons. For example, the destination file
might be read-only, and the user might want the copy to fail in that
case.
I installed this:
2006-08-22 Paul Eggert <[EMAIL PROTECTED]>
* bootstrap (bootstrap_conf_cleanup): Remove.
(excluded_files): New var.
* bootstrap.conf: Likewise.
* bootstrap (slurp): Exclude files early if they're in the
excluded_files list. That way, th
I installed this. As the ChangeLog notes, there is still one
issue with m4/.cvsignore, but that needs to be fixed in the
bootstrap script.
2006-08-22 Paul Eggert <[EMAIL PROTECTED]>
* aclocal.m4, config.hin, configure:
Remove from CVS, since ./bootstrap generates them automatic
Bruno Haible <[EMAIL PROTECTED]> writes:
> 2006-08-19 Bruno Haible <[EMAIL PROTECTED]>
>
> BeOS portability.
> * m4/boottime.m4 (GNULIB_BOOT_TIME): Test also for utmp.h, utmpx.h,
> OS.h. Don't require to have utmp.h or utmpx.h. Enable boottime
> support if is found.
>
Bruno Haible <[EMAIL PROTECTED]> writes:
> 2006-08-19 Bruno Haible <[EMAIL PROTECTED]>
>
> * m4/readutmp.m4 (gl_READUTMP): Compile readutmp.c only if or
>exists.
> * lib/readutmp.h: Skip most definitions if neither nor
>exists.
Thanks for the port; I installed that
Hi Simon,
Compiling coreutils-6.0 on BeOS gives this:
source='getaddrinfo.c' object='getaddrinfo.o' libtool=no \
DEPDIR=.deps depmode=gcc /bin/sh ../build-aux/depcomp \
gcc -DHAVE_CONFIG_H -DLIBDIR=\"/boot/home/config/lib\" -I. -I. -I.. -I.. -I.
-Wall -I/boot/home/config/include -g -O2 -c get
On platforms without or , there is no need for the
read_utmp function (since 'pinky', 'users', 'who' are not built and
uptime.c doesn't call read_utmp with the previous proposed patch). Here are
minimal changes to avoid compilation errors in readutmp.h (still included
by uptime.c) and readutmp.c.
On BeOS, coreutils wouldn't install the 'uptime' program. But BeOS has a
system call that returns the boot time. This makes it possible to port
the 'uptime' program.
2006-08-19 Bruno Haible <[EMAIL PROTECTED]>
BeOS portability.
* m4/boottime.m4 (GNULIB_BOOT_TIME): Test also for
Frederik Eaton writes:
> The question is, is there a reason why users wouldn't always want a
> "copyFile" function to remove the destination first?
It effectively resets all ACLs on the destination.
Bob
___
Bug-coreutils mailing list
Bug-coreutils@gnu
Paul Eggert wrote:
> Also, we need to define HAVE_FCHMOD when fchmod is available.
Yes, sorry. Coreutils already provides the HAVE_FCHMOD in config.h.in;
I had forgotten that dirchownmod is also in gnulib.
Bruno
___
Bug-coreutils mailing list
Bug-core
Frederik Eaton <[EMAIL PROTECTED]> writes:
> The question is, is there a reason why users wouldn't always want a
> "copyFile" function to remove the destination first?
It breaks hard links.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 9040
Frederik Eaton <[EMAIL PROTECTED]> wrote:
...
> The question is, is there a reason why users wouldn't always want a
> "copyFile" function to remove the destination first?
Sometimes, cp --remove-dest will fail, because the destination
cannot be removed. Yet cp without that option would be able to
On 8/22/06, Frederik Eaton <[EMAIL PROTECTED]> wrote:
Perhaps the "Text file busy" error is Unix-specific, but I can imagine
cases where somebody (other than the OS) might open a file with a
well-known name and read from various parts of it, and expect it not
to change underneath them...
Then h
Perhaps the "Text file busy" error is Unix-specific, but I can imagine
cases where somebody (other than the OS) might open a file with a
well-known name and read from various parts of it, and expect it not
to change underneath them...
Regards,
Frederik
On Tue, Aug 22, 2006 at 05:19:42PM +0300, K
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Frederik Eaton on 8/22/2006 8:12 AM:
> Dear bug-coreutils,
>
> We are trying to decide what the semantics of the Haskell standard
> library function 'copyFile' should be. The first incarnation behaved
> roughly like 'cp', i.e. overwriting
Isn't this Unix specific bug? If that is the case then maybe unlinking
should be optional.
Cheers,
Krasimir
On 8/22/06, Frederik Eaton <[EMAIL PROTECTED]> wrote:
Dear bug-coreutils,
We are trying to decide what the semantics of the Haskell standard
library function 'copyFile' should be. The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to David Cermak on 8/22/2006 7:16 AM:
> Hello,
> as i really can't believe that it looks like a bug:
>
> [EMAIL PROTECTED]:~$ date -d "01/01/1830" +"%s"
> date: invalid date `01/01/1830'
This is due to limitations on platforms where time is
Dear bug-coreutils,
We are trying to decide what the semantics of the Haskell standard
library function 'copyFile' should be. The first incarnation behaved
roughly like 'cp', i.e. overwriting destination files without
unlinking them first. This isn't suitable for installing stuff, for
example, sin
If coreutils is updated to sync gnupload from gnulib, which I think
would be a good idea, please drop gnupload from gnulib's
config/srclist.txt.
/Simon
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreu
Hello,
as i really can't believe that it looks like a bug:
[EMAIL PROTECTED]:~$ date -d "01/01/1830" +"%s"
date: invalid date `01/01/1830'
that's ok, but >
[EMAIL PROTECTED]:~$ date -d "01/01/1902" +"%s"
-2145920400
[EMAIL PROTECTED]:~$ date -d "01/01/1901" +"%s"
-2147483648
[EMAIL PROTECTED]:~
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 8/22/2006 6:18 AM:
> Paul's latest updates to module dependencies pulled in several .m4 files
> that trigger gcc compiler warnings, breaking the configuration of m4 with
> '-Werror' where it had previously been working. Paul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul's latest updates to module dependencies pulled in several .m4 files
that trigger gcc compiler warnings, breaking the configuration of m4 with
'-Werror' where it had previously been working. Paul, Bruno, are these
okay to install?
Is bh_C_SIGNED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Sascha Kolb on 8/22/2006 2:53 AM:
> T:\Temp>rm -f *.obj
>
> rm: cannot remove `*.obj': Invalid argument
>
>
>
> T:\Temp>rm --version
>
> rm (fileutils) 4.1
You are in dire need of an upgrade. fileutils has been converted over to
cor
dd if=/dev/zero of=obj/kern/bochs.img~ count=1 2>/dev/null
/bin/sh: line 1: 5952 Segmentation Fault dd if=/dev/zero of=obj/kern/bochs.img~
count=1 2>/dev/null
make: *** [obj/kern/bochs.img] Error 139
dd if=p1.tar of=p2.tar
13500+0 records in
13500+0 records out
Segmentation Fault
___
2006/8/17, Daniel <[EMAIL PROTECTED]>:
Am Mittwoch, 16. August 2006 19:56 schrieb Sascha Kolb:
> Hi I am wondering,
>
> I have different versions of rm.exe with exits with error if I use
> wildcards with -f parameter and there is no file existing.
>
> RM:= rm -f
>
> We have many clean targets t
Bruno Haible <[EMAIL PROTECTED]> wrote:
> On BeOS 5, building coreutils shows, apart from the c89-c99 and the gzip
> --help
> issue (which have already been handled), a number of minor compilation
> failures.
...
> a "make check" attempts to builds the programs
> chroot - and fails because BeOS
Eric Blake <[EMAIL PROTECTED]> writes:
> 2006-08-21 Eric Blake <[EMAIL PROTECTED]>
>
> * Makefile.am (LDADD): Restore this line; it is still needed for
> t-fpending on platforms without __fpending.
Thanks, I installed that.
___
Bug-coreu
34 matches
Mail list logo
