inal report.
> If you require more details, please reply to 12...@debbugs.gnu.org.
>
> --
> 12365: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12365
> GNU Bug Tracking System
> Contact help-debb...@gnu.org with problems
>
>
> -- Forwarded message --
>
When -n (--no-clobber) option of cp is used and the DEST file exists, then, as
expected, cp is not able to copy the SOURCE to DEST.
However, cp returns 0 in this case.
Shouldn't it return 1 to indicate that copy operation could not be completed?
In absence of this indication how is one to know t
On Thu, Jun 7, 2012 at 11:15 PM, Eric Blake wrote:
> [please don't top-post on technical lists]
>
> On 06/07/2012 08:37 AM, Anoop Sharma wrote:
>> The thought behind the proposed change was that lseek should reflect
>> the amount of data that head has actually been abl
On Thu, Jun 7, 2012 at 11:08 PM, Jim Meyering wrote:
> Anoop Sharma wrote:
>> The thought behind the proposed change was that lseek should reflect
>> the amount of data that head has actually been able to print.
>>
>> For example, how do we want head to behave in a situ
The thought behind the proposed change was that lseek should reflect
the amount of data that head has actually been able to print.
For example, how do we want head to behave in a situation like the
following where files more than a particular size are not allowed
(with bash shell on a machine with
org
> Date: Tue, 05 Jun 2012 22:35:13 +0200
> Subject: Re: bug#11631: Head command does not position file pointer correctly
> for negative line count
> Jim Meyering wrote:
> > Thanks, and thanks for the review. Pushed.
>
> And with this message, I've closed the issue.
&g
xed because how much
data read() actually reads is not fixed (See point 4 above). It is also
possible that no data is lost!!
I tried the following example and it worked as expected:
$ seq 10 >p
$ ( head -n 2 ; echo xxx ; cat ) wrote:
> Anoop Sharma wrote:
>
> > Head command does
Head command does not position file pointer correctly for negative line
count. Here is a demonstration of the problem.
Step 1 - Create a file with 10 lines in it.
$ yes "ABC" | head -c 40 >ip.txt
$
Step 2 - If head behaves correctly, then 2 lines should get printed after
"" but nothin
Hi,
md5sum was made line buffered sometime back. However, cksum was left out of
that patch.
I tried running the following test on my machine for cksum, on the lines of
test for md5sum, given in bug archives at:
http://lists.gnu.org/archive/html/bug-coreutils/2009-10/msg00190.html. The
test failed
