I was just looking at this line in cat.c: http://url.ie/1aq1
if (input_pending)
write_pending (outbuf, &bpout);
Shouldn't that be?
if (!input_pending)
write_pending (outbuf, &bpout);
The checkin I think is 790892db: http://url.ie/1aq1
If this is incorrect, how about jus
Pádraig Brady wrote:
> Bruno Haible wrote:
>> Hi Jim,
>
> Thanks for looking at this Bruno.
>
>> In coreutils/src/join.c, there is a FIXME mentioning that the -i option for
>> case insensitive comparison of the input lines does not work in multibyte
>> locales.
>
> Utils that have this issue are
Bruno Haible wrote:
> Hi Jim,
Thanks for looking at this Bruno.
> In coreutils/src/join.c, there is a FIXME mentioning that the -i option for
> case insensitive comparison of the input lines does not work in multibyte
> locales.
Utils that have this issue are:
join -i, uniq -i, sort -f, ptx -f
Pádraig Brady wrote:
Matthew Woehlke wrote:
(* what happened to adding a coreutil to fix [block buffering vs.
line buffering], did it ever happen?)
Are you talking about stdbuf?
That's on the way soon.
That sounds familiar. Thanks for the info.
--
Matthew
Please do not quote my e-mail addre
James Youngman wrote:
> Signed-off-by: James Youngman
> ---
> README-prereq |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/README-prereq b/README-prereq
> index 91676f4..d7c9c36 100644
> --- a/README-prereq
> +++ b/README-prereq
> @@ -27,5 +27,8 @@ getting the pr
Hi Jim,
In coreutils/src/join.c, there is a FIXME mentioning that the -i option for
case insensitive comparison of the input lines does not work in multibyte
locales. And indeed, in an UTF-8 locale, I see this:
$ cat > in1 < in2 < in1 < in2 <--- coreutils-7.1/src/join.c.bak 2008-11-10 14:17:52.
Signed-off-by: James Youngman
---
README-prereq |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/README-prereq b/README-prereq
index 91676f4..d7c9c36 100644
--- a/README-prereq
+++ b/README-prereq
@@ -27,5 +27,8 @@ getting the prerequisites for particular systems.
$
Matthew Woehlke wrote:
> Pádraig Brady wrote:
>> Note there have been a few patches to add progress bars to cp/mv. For
>> e.g..:
>> http://lists.gnu.org/archive/html/bug-coreutils/2007-12/msg00212.html
>> However you can use `rsync -aP my_file my_file.2` to copy locally with
>> progress.
>
> FWIW,
Pádraig Brady wrote:
Note there have been a few patches to add progress bars to cp/mv. For e.g..:
http://lists.gnu.org/archive/html/bug-coreutils/2007-12/msg00212.html
However you can use `rsync -aP my_file my_file.2` to copy locally with progress.
FWIW, I most often would find a progress bar f
On Tue, Mar 10, 2009 at 02:40:32PM +, Eric Blake wrote:
> Most likely, this is due to your choice of locales, and not a bug
> in sort nor in ls.
>
> http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021
> http://www.gnu.org/software/coreutils/faq/
On Tue, 10 Mar 2009, Major Péter wrote:
But here is some list-related problems of mine:
ls:
If it has a null parameter e.g. in
"find blah -print0 | xargs -0 ls" find gives no hit,
the ls writes on the output (maybe on error output, I'm not sure) a message,
that incorrect argumentum has camed, B
Rafal Maszkowski wrote:
> I wonder if a wrapper around the system trunc(3) call could be included
> into coreutils. It could be a separate command like:
>
> trunc my_file 234M
>
> (I have made such for myself) or maybe an extension to the touch
> comand syntax. The command can shorten an e
> I wonder if a wrapper around the system trunc(3) call could be
> included
> into coreutils. It could be a separate command like:
>
> trunc my_file 234M
Already written, in coreutils 7.0, under the name truncate. You
probably need to upgrade; the latest stable version is 7.1.
> The conse
Eric Blake wrote:
>> coreutils/src/factor.c #defines NDEBUG after including .
>> It's supposed to be defined before.
>
> Why is factor.c even messing with NDEBUG? The point of the gnulib assert
> module is to allow ./configure-time control over whether assertions
> are enabled, and this patch woul
Rogier Wolff wrote:
> Dear coreutils-developers,
>
> I just noticed that ls sorted my directory in an unusual way. I was
> writing up a bugreport, and was saying: It's odd that ls would sort
> differently than "sort" would, and found out that sort has been
> changed as well.
>
> Sort has an opti
> coreutils/src/factor.c #defines NDEBUG after including .
> It's
> supposed to be defined before.
Why is factor.c even messing with NDEBUG? The point of the gnulib assert
module is to allow ./configure-time control over whether assertions
are enabled, and this patch would mean that for this fil
> Dear coreutils-developers,
>
> I just noticed that ls sorted my directory in an unusual way. I was
> writing up a bugreport, and was saying: It's odd that ls would sort
> differently than "sort" would, and found out that sort has been
> changed as well.
Most likely, this is due to your choice
Dear coreutils-developers,
I just noticed that ls sorted my directory in an unusual way. I was
writing up a bugreport, and was saying: It's odd that ls would sort
differently than "sort" would, and found out that sort has been
changed as well.
Sort has an option to trigger the observed behaviou
I wonder if a wrapper around the system trunc(3) call could be included
into coreutils. It could be a separate command like:
trunc my_file 234M
(I have made such for myself) or maybe an extension to the touch
comand syntax. The command can shorten an existing file or create a
sparse new
Sorry about the off-topic.
But here is some list-related problems of mine:
ls:
If it has a null parameter e.g. in
"find blah -print0 | xargs -0 ls" find gives no hit,
the ls writes on the output (maybe on error output, I'm not sure) a
message, that incorrect argumentum has camed, BUT it still wr
Hi!
I have a more or less trivial patch for the nanosleep replacement for
interix. The problem I ran into is, that select() has a bug, making it fail
with "bad address" if the number of fd's to select on is zero. Setting the
set-size to 1 solves the problem, and should not damage anything else aro
On Sun, 8 Mar 2009, Major P?ter wrote:
The main problem with du is, that it doesn't care with users, so I need a
"find" before (using the -user will solve the problem). But I can't use du
`find ...` because it will contain the subfolders too, so it will duplicate,
and the measure won't be corr
On Tuesday 10 March 2009 06:47:11 Pádraig Brady wrote:
> Mike Frysinger wrote:
> > On Tuesday 10 March 2009 06:11:47 Jim Meyering wrote:
> >> Mike Frysinger wrote:
> >>> mkudir() { (u=$1; g=$2; shift 2; install -d -o"$u" -g"$g" "$@"); }
> >>
> >> Good idea.
> >> I prefer to use "local", and thus to
Mike Frysinger wrote:
> On Tuesday 10 March 2009 06:11:47 Jim Meyering wrote:
>> Mike Frysinger wrote:
>>> mkudir() { (u=$1; g=$2; shift 2; install -d -o"$u" -g"$g" "$@"); }
>> Good idea.
>> I prefer to use "local", and thus to avoid forking a subshell.
>
> in general, i agree. however, some peop
On Monday 09 March 2009 15:18:25 hggdh wrote:
> Every so often I run a make check, and (more eventually) a root make
> check. After a git pull & remake this morning, I ran a root check, and
> got a failure on install-C-root.
Thank you for the report. Unfortunately I am not able to reproduce it. Ca
On Tuesday 10 March 2009 06:11:47 Jim Meyering wrote:
> Mike Frysinger wrote:
> > mkudir() { (u=$1; g=$2; shift 2; install -d -o"$u" -g"$g" "$@"); }
>
> Good idea.
> I prefer to use "local", and thus to avoid forking a subshell.
in general, i agree. however, some people like to omit "local" suppo
Mike Frysinger wrote:
..
> mkudir() { (u=$1; g=$2; shift 2; install -d -o"$u" -g"$g" "$@"); }
Good idea.
I prefer to use "local", and thus to avoid forking a subshell.
Also, you can drop the semicolon between the assignments:
mkudir() { local u=$1 g=$2; shift 2; install -d -o"$u" -g"$g" "$@"; }
On Tuesday 10 March 2009 05:54:49 Jim Meyering wrote:
> Pádraig Brady wrote:
> > Caleb Cushing wrote:
> >> be awesome if mkdir had a way to specify the user:group ownership
> >> being made. given this would be limited by perms. but as root it could
> >> be good.
> >>
> >> just throwing it out there
Pádraig Brady wrote:
> Caleb Cushing wrote:
>> be awesome if mkdir had a way to specify the user:group ownership
>> being made. given this would be limited by perms. but as root it could
>> be good.
>>
>> just throwing it out there.
>
> Perhaps a simple wrapper around install would be better?
Oh,
Pádraig Brady wrote:
> Caleb Cushing wrote:
>> be awesome if mkdir had a way to specify the user:group ownership
>> being made. given this would be limited by perms. but as root it could
>> be good.
>>
>> just throwing it out there.
>
> Perhaps a simple wrapper around install would be better?
>
> m
Caleb Cushing wrote:
> be awesome if mkdir had a way to specify the user:group ownership
> being made. given this would be limited by perms. but as root it could
> be good.
>
> just throwing it out there.
Perhaps a simple wrapper around install would be better?
mkudir() { u="$1"; g="$2"; shift 2
be awesome if mkdir had a way to specify the user:group ownership
being made. given this would be limited by perms. but as root it could
be good.
just throwing it out there.
--
Caleb Cushing
http://xenoterracide.blogspot.com
___
Bug-coreutils mailin
Hi,
I need to write a script, which will print out on the standard output,
that each user how many disk space (in blocks) are using in a directory
(and subdirectories, the directory is a parameter).
So an example output would look like this:
root:101711
user1:940258
The main problem with du i
Paul Eggert wrote:
> * src/csplit.c (ALLOC_SIZE): Remove.
> * src/dd.c (max): Remove.
> * src/expand.c (OUTPUT_BLOCK): Remove.
> * src/install.c (INITIAL_HASH_MODULE, INITIAL_ENTRY_TAB_SIZE, READ_SIZE):
> Remove.
> * src/ls.c (ASSERT_MATCHING_DEV_INO): Remove.
> * src/mv.c (INITIAL_HASH_MODULE, IN
* src/csplit.c (ALLOC_SIZE): Remove.
* src/dd.c (max): Remove.
* src/expand.c (OUTPUT_BLOCK): Remove.
* src/install.c (INITIAL_HASH_MODULE, INITIAL_ENTRY_TAB_SIZE, READ_SIZE):
Remove.
* src/ls.c (ASSERT_MATCHING_DEV_INO): Remove.
* src/mv.c (INITIAL_HASH_MODULE, INITIAL_ENTRY_TAB_SIZE): Remove.
*
coreutils/src/factor.c #defines NDEBUG after including . It's
supposed to be defined before. Here's a patch:
---
src/factor.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/factor.c b/src/factor.c
index 83cd0a8..203b45b 100644
--- a/src/factor.c
+++ b/src/factor.c
36 matches
Mail list logo
