Re: RFC: new cp option: --efficient-sparse=HOW

2011-02-04 Thread Pádraig Brady
On 03/02/11 20:29, Jim Meyering wrote: Does anyone know how to determine if a file system (say the one with .) supports the FIEMAP ioctl, but without compiling/running a C program? I.e., via perl or python? I've written a tiny C program that works and a Perl one that is supposed to be

two portability fixes

2011-02-04 Thread Jim Meyering
The first is just to fix a failing test. For mv/i-3, the output file, out is empty on FreeBSD 8.1 Also, (and this is telling), it seems that no one is testing on non-linux kernels. On the first one I tried, just before I was planning to release, make check reported 30+ failing tests, all having

Re: { mv test test; } should not fail

2011-02-04 Thread Eric Blake
On 02/04/2011 09:07 AM, Krzysztof Żelechowski wrote: I know exactly which implementation of mv will be used. Not necessarily. The point of open source is that someone can copy your scripts into their setup, which might be different than yours. Since POSIX already says you have to be

Re: { mv test test; } should not fail

2011-02-04 Thread Jim Meyering
Krzysztof Żelechowski wrote: At any rate, I don't see any reason for coreutils to change its behavior; although I might be persuaded otherwise if someone writes up a patch (including testsuite and documentation), Whereas I hoped to be persuaded that failing makes sense and is *not*

coreutils-8.10 released [stable]

2011-02-04 Thread Jim Meyering
This is to announce coreutils-8.10, a stable release. There have been some minor bug fixes, along with two new features. The join feature is enabled via a new option, -o auto. The cp feature makes copying sparse files much more efficient on several common file systems. It takes advantage of a

Re: coreutils-8.10 released [stable]

2011-02-04 Thread Dmitry V. Levin
On Fri, Feb 04, 2011 at 08:20:39PM +0100, Jim Meyering wrote: This is to announce coreutils-8.10, a stable release. There have been some minor bug fixes, along with two new features. The join feature is enabled via a new option, -o auto. The cp feature makes copying sparse files much more

Re: coreutils-8.10 released [stable]

2011-02-04 Thread Dmitry V. Levin
On Sat, Feb 05, 2011 at 03:11:12AM +0300, Dmitry V. Levin wrote: On Fri, Feb 04, 2011 at 08:20:39PM +0100, Jim Meyering wrote: This is to announce coreutils-8.10, a stable release. There have been some minor bug fixes, along with two new features. The join feature is enabled via a new

Re: df -t fails to filter fs type

2011-02-04 Thread Dmitry V. Levin
On Sat, Feb 05, 2011 at 03:28:01AM +0300, Dmitry V. Levin wrote: [...] + df -T -t btrfs -t xfs -t ext4 -t ocfs2 -t gfs2 . df: Warning: cannot read table of mounted file systems FilesystemType 1K-blocks Used Available Use% Mounted on --10485760793504 9692256

Generating pseudo-random integers

2011-02-04 Thread Melikamp T. Medley
Hi! I want to generate pseudo-random integers from a shell, and I wonder if coreutils can be used to do that. I really like randint.c , and I basically want a shell front end to randint_choose. Or is there a standard way to do this I am not aware of?

Re: Generating pseudo-random integers

2011-02-04 Thread Eric Blake
On 02/04/2011 08:48 PM, Melikamp T. Medley wrote: Hi! I want to generate pseudo-random integers from a shell, and I wonder if coreutils can be used to do that. I really like randint.c , and I basically want a shell front end to randint_choose. Or is there a standard way to do this I am not

Re: Generating pseudo-random integers

2011-02-04 Thread Melikamp T. Medley
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks! I think I want to write a utility that prints pseudo-random integers (I have in CL, but I like it fast, so this time in C), and link it with coreutils. I looked at Paul Eggert's work, and I won't be able to do any better than that if I spend

Re: Generating pseudo-random integers

2011-02-04 Thread Bob Proulx
Melikamp T. Medley wrote: I think I want to write a utility that prints pseudo-random integers (I have in CL, but I like it fast, so this time in C), I am confused by the connection of using the shell on one hand and by saying you need speed on the other. The shell is quite fast and good

bug#7981: error in getopt1.c library file of the coreutils project (from the http download)

2011-02-04 Thread Eric Blake
On 02/04/2011 07:45 AM, Robert Dell wrote: This is being emailed to you because you are the maintainers of the coreutils project. I don't know who is responsible but one of you four should be able to get this done. The information about who maintains this project may even be obsolete and if

bug#7985: Inconsistancy

2011-02-04 Thread Tom Tijerina
I have a friend I'm trying to get into learning Linux, not wanting to hand feed him every command I've instructed him to use man when he get stuck or needs help on how to use a command. He ran man rm and it says at the top its for removing files OR directories. That is not correct as it does not

bug#7985: Inconsistancy

2011-02-04 Thread Eric Blake
On 02/03/2011 04:22 PM, Tom Tijerina wrote: I have a friend I'm trying to get into learning Linux, not wanting to hand feed him every command I've instructed him to use man when he get stuck or needs help on how to use a command. He ran man rm and it says at the top its for removing files

bug#7985: Inconsistancy

2011-02-04 Thread Pádraig Brady
On 03/02/11 23:22, Tom Tijerina wrote: I have a friend I'm trying to get into learning Linux, not wanting to hand feed him every command I've instructed him to use man when he get stuck or needs help on how to use a command. He ran man rm and it says at the top its for removing files OR

bug#7985:

2011-02-04 Thread Tom Tijerina
Thank you for your replies guys, I'm sorry we both managed to miss it. The wording is a bit on the odd side but it is fine the way it is. Sorry I wasted your time and thanks for making this wonderful system work on such a consistent basis. I wouldn't know how to operate with a buggy commercial

bug#7963: 16-bit wchar_t on Windows and Cygwin

2011-02-04 Thread Warren Young
On 2/2/2011 9:35 AM, Corinna Vinschen wrote: If only the one's who decided that wchar_t in Cygwin should have the same size as WCHAR_T in the underlying Windows would have thought twice about the implications... Cygwin 1.9? Or maybe 2.0, if it breaks ABIs?