Re: [PATCH] build: allow ./bootstrap --srcdir=... to work with a git submodule
Jim Meyering wrote: > When using git-bisect to see exactly when pr -oN broke, > I was dismayed to see that I couldn't easily build some older > versions from git due to their dependency on older versions > of gnulib. Of course, this isn't at all surprising, once you > think about it, and I've been remiss for not doing this sooner... > > So I'm about to make gnulib a "git submodule" of coreutils. > > However, first, there's a small portability problem in the bootstrap > script that makes --scrdir=... fail to run module init with versions > of git newer than the one mentioned in the log below. > > I confess I haven't tried this with an older version of git (I don't > even have an old enough version installed), so if someone can confirm > bootstrap --srcdir=... succeeds and a subsequent "git submodule status" > prints something, I'd appreciate it. Works fine here... $ git --version git version 1.5.3.6 $ ./bootstrap --gnulib-srcdir=/home/padraig/git/gnulib $ git submodule status 8a4dc70a0d4efd5f53abb1f7a1c24fe67915f96b gnulib (v0.0-1958-g8a4dc70) cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Did I found a bug in "ls"?
On Sun, Mar 8, 2009 at 3:15 PM, Major Péter wrote: > Hi! > > I would like to list some folders with they block-sizes, but only specific > folders am I interested. > So I would like to use find to list the correct folders for me: > ls `find . -type d -user foo -name "*"` -name "*" is redundant I think. > this is not working because ls can't find folders with spaces in there name, > so I am using a pipe and sed, to make it comfortable: This is a very dangerous way to try to solve this problem. See the findutils Texinfo manual, in particular the section "Safe File Name Handling". > ls `find . -user major -type d -name "*" | sed 's,\ ,\\\ ,g'` > If I'm using echo instead ls, the output is: > ./foo\ bar > So I tried to use: > ls ./foo\ bar > And it worked! > The easiest way to check this is using this command in a folder where are > folders with spaces in they names: > ls `ls -a | sed 's,\ ,\\\ ,g'` > Is there may an other way to find out the folders block-size belonging to a > specific user? Do you mean the total size in blocks of the contents of each directory owned by a user?Or the size in blocks occupied by each directory (i.e. list of files) itself?I'm not sure I clearly understand what you wanted to do, so it is hard for me to be sure this is the correct answer, but this is a reasonable guess I think: $ find glpk -depth -type d -user youngman -print0 | du -s --files0-from=- 1936glpk/glpk-4.8/doc 12 glpk/glpk-4.8/examples/.deps 1756glpk/glpk-4.8/examples 356 glpk/glpk-4.8/include 176 glpk/glpk-4.8/src/.deps 3528glpk/glpk-4.8/src 8 glpk/glpk-4.8/sysdep/gnu 12 glpk/glpk-4.8/sysdep/w32 24 glpk/glpk-4.8/sysdep 7880glpk/glpk-4.8 960 glpk/tarfile 8844glpk > Thanks for your help. > > Regards, > Peter Major > > > ___ > Bug-coreutils mailing list > Bug-coreutils@gnu.org > http://lists.gnu.org/mailman/listinfo/bug-coreutils > ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug in comm --check-order
Bruno Haible wrote:
> "comm --check-order" does not detect all cases of misordered input.
...
> Attached is a fix. Feel free to add a unit test for this; I'm not familiar
> enough with coreutils to do that.
Thank you for the fine report and patch.
And thanks for adding memcmp2 to gnulib.
Here's your patch again, with your ChangeLog entry and
a slightly different one-line summary.
I'll apply it tomorrow, along with the following test and NEWS entry:
>From 739b9740202b6c1a0bd22a6868f81496cb9cbf3c Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Sun, 8 Mar 2009 18:25:29 +0100
Subject: [PATCH 1/2] comm: fix a bug in its new --check-order option
* src/comm.c: Include memcmp2.h.
(check_order): Use memcmp2 instead of memcmp.
* bootstrap.conf (gnulib_modules): Add memcmp2.
---
bootstrap.conf |2 +-
src/comm.c |9 -
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/bootstrap.conf b/bootstrap.conf
index e61e241..0747bb8 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -71,7 +71,7 @@ gnulib_modules="
manywarnings
mbrtowc
mbswidth
- memcasecmp mempcpy
+ memcasecmp memcmp2 mempcpy
memrchr mgetgroups
mkancesdirs mkdir mkdir-p mkstemp mktime modechange
mountlist mpsort obstack pathmax perl physmem
diff --git a/src/comm.c b/src/comm.c
index 4ec7e4a..c60936f 100644
--- a/src/comm.c
+++ b/src/comm.c
@@ -1,5 +1,5 @@
/* comm -- compare two sorted files line by line.
- Copyright (C) 86, 90, 91, 1995-2005, 2008 Free Software Foundation, Inc.
+ Copyright (C) 86, 90, 91, 1995-2005, 2008-2009 Free Software Foundation,
Inc.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -25,6 +25,7 @@
#include "error.h"
#include "quote.h"
#include "stdio--.h"
+#include "memcmp2.h"
#include "xmemcoll.h"
/* The official name of this program (e.g., no `g' prefix). */
@@ -199,10 +200,8 @@ check_order (struct linebuffer const *prev,
order = xmemcoll (prev->buffer, prev->length - 1,
current->buffer, current->length - 1);
else
- {
- size_t len = min (prev->length, current->length) - 1;
- order = memcmp (prev->buffer, current->buffer, len);
- }
+ order = memcmp2 (prev->buffer, prev->length - 1,
+current->buffer, current->length - 1);
if (0 < order)
{
--
1.6.2.rc1.285.gc5f54
>From da82fef936a80b7fd3d4914c3e14f67abdb29088 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 8 Mar 2009 18:37:08 +0100
Subject: [PATCH 2/2] tests: add a test for newly-fixed bug in comm --check-order
* tests/misc/comm (ooo-prefix): Add a test for today's fix.
* NEWS (Bug fixes): Mention it.
---
NEWS|5 +
tests/misc/comm |9 -
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/NEWS b/NEWS
index 0f6e853..608307e 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,11 @@ GNU coreutils NEWS-*-
outline -*-
** Bug fixes
+ comm's new --check-order option would fail to detect disorder on any pair
+ of lines where one was a prefix of the other. For example, this would
+ fail to report the disorder: printf 'Xb\nX\n'>k; comm --check-order k k
+ [bug introduced in coreutils-7.0]
+
cp once again diagnoses the invalid "cp -rl dir dir" right away,
rather than after creating a very deep dir/dir/dir/... hierarchy.
The bug strikes only with both --recursive (-r, -R) and --link (-l).
diff --git a/tests/misc/comm b/tests/misc/comm
index 81a8529..80a0c2d 100755
--- a/tests/misc/comm
+++ b/tests/misc/comm
@@ -2,7 +2,7 @@
# -*- perl -*-
# Test comm
-# Copyright (C) 2008 Free Software Foundation, Inc.
+# Copyright (C) 2008-2009 Free Software Foundation, Inc.
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -116,6 +116,13 @@ my @Tests =
{OUT => "\t\t2\n"},
{ERR => "$prog: file 1 is not in sorted order\n"}],
+ # out-of-order, line 2 is a prefix of line 1
+ # until coreutils-7.2, this test would fail -- no disorder detected
+ ['ooo-prefix', '--check-order', {IN=>{a=>"Xa\nX\n"}}, {IN=>{b=>""}},
+{EXIT=>1},
+{OUT => "Xa\n"},
+{ERR => "$prog: file 1 is not in sorted order\n"}],
+
# alternate delimiter: ','
['delim-comma', '--output-delimiter=,', @inputs,
{OUT=>"1\n,2\n,,3\n"} ],
--
1.6.2.rc1.285.gc5f54
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Did I found a bug in "ls"?
On Sun, 8 Mar 2009, Major Péter wrote: I would like to list some folders with they block-sizes, but only specific folders am I interested. So I would like to use find to list the correct folders for me: ls `find . -type d -user foo -name "*"` this is not working because ls can't find folders with spaces in there name, find uses an implicit "-print" argument, but in this case please look at find's "-print0" option. This version of the above command should work: $ find . -type d -user foo -print0 | xargs -0 ls (-name "*" is redundant, as everything matches) I'm still not sure what you're referring to by folders with block-sizes? Would the du command be helpful here? Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Did I found a bug in "ls"?
Hi, On Sun, Mar 08, 2009 at 04:15:16PM +0100, Major Péter wrote: > I would like to list some folders with they block-sizes, but only > specific folders am I interested. > So I would like to use find to list the correct folders for me: > ls `find . -type d -user foo -name "*"` > this is not working because ls can't find folders with spaces in there > name, so I am using a pipe and sed, to make it comfortable: You could use find . -type d -print0 | xargs -0 ls to solve the problem of spaces in folder names. Regards, Erik ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Did I found a bug in "ls"?
Hi! I would like to list some folders with they block-sizes, but only specific folders am I interested. So I would like to use find to list the correct folders for me: ls `find . -type d -user foo -name "*"` this is not working because ls can't find folders with spaces in there name, so I am using a pipe and sed, to make it comfortable: ls `find . -user major -type d -name "*" | sed 's,\ ,\\\ ,g'` If I'm using echo instead ls, the output is: ./foo\ bar So I tried to use: ls ./foo\ bar And it worked! The easiest way to check this is using this command in a folder where are folders with spaces in they names: ls `ls -a | sed 's,\ ,\\\ ,g'` Is there may an other way to find out the folders block-size belonging to a specific user? Thanks for your help. Regards, Peter Major ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: split.c - size_t overflow
Chris Penev wrote: > Line 153 - 157 > ... > 153:size_t outbase_length = strlen (outbase); > 154:size_t outfile_length = outbase_length + suffix_length; > 155:if (outfile_length + 1 < outbase_length) > 156:xalloc_die (); > 157:outfile = xmalloc (outfile_length + 1); > ... > > If suffix_length SIZE_MAX the check on line 155 is bypassed. Thanks for the analysis and the report. That is true. However, the code that sets suffix_length ensures that it is no larger than SIZE_MAX / sizeof (size_t), so there's no problem. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
split.c - size_t overflow
Line 153 - 157 ... 153:size_t outbase_length = strlen (outbase); 154:size_t outfile_length = outbase_length + suffix_length; 155:if (outfile_length + 1 < outbase_length) 156:xalloc_die (); 157:outfile = xmalloc (outfile_length + 1); ... If suffix_length SIZE_MAX the check on line 155 is bypassed. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
