Re: dd: add braces as requested by HACKING coding standard

On 02/06/2012 06:26 AM, Jérémy Compostella wrote: >> >> You inconsistently use é and e in your name between git config >> and your emailer and patches on github. I adjusted to using é >> as I presume that's more correct? > You presume right. I stopped to use accent in my git config a few months >

bug#10735: chmod +x file

tags 10735 notabug On 02/06/2012 02:23 PM, francky.l...@telenet.be wrote: > > Hello, > > I perform the following: > > ubuntu@ubuntu-VirtualBox:~/.gvfs/account on stockholm/Documents/03 > professional/structured_documentation$ ls -l doc/filters_for_this_document > -rwx-- 1 ubuntu ubuntu

Re: dd: add 'skip_bytes' and 'count_bytes' operands

On 02/06/2012 02:01 PM, Jérémy Compostella wrote: > Pádraig, all, > > I took into account general comments on my commits. I attached the > improved patch for feature. Improvements are: > - Add by file description, > - I put back accents on my name (Jérémy instead of Jeremy), Great thanks. Hmm, s

Re: dd: add 'skip_bytes' and 'count_bytes' operands

On 02/06/2012 03:24 PM, Jérémy Compostella wrote: >> Hmm, shouldn't there be a seek_bytes param too for consistency? > That was effectively my first mail question. As you talk about it in > your explanation addition in coreutils.texi I guess I should start > implementing it ? I think so. Note it

Re: "ls -l": Avoid unnecessary getxattr() overhead

Thanks for taking a look Jérémy. This seems to have some related info. https://bugzilla.redhat.com/show_bug.cgi?id=662011 We might be able to cache something. We'll investigate. cheers, Pádraig.

Re: Adding humanize_number to coreutiles?

On 02/07/2012 03:36 AM, Peng Yu wrote: > Hi, > > Several commands in coreutils have the -h option. I'm wondering > whether anybody in the develop team also thinks that it is worthwhile > to export it as a standalone command. If so, I'd recommend add such > convenient command in coreutiles. As I do

Re: uniq --accumulate

On 02/07/2012 03:56 PM, Peng Yu wrote: > Hi, > > Suppose that I have a table of the following, where the last column is > a number. I'd like to accumulate the number of rows that are the same > for all the remaining columns. > > A 1 > A 3 > X 2 > X 3 > Y 3 > > The result will be the following. A

bug#10561: stat unclear about size on disk and type of blocks discussed

On 02/07/2012 06:26 PM, Filipus Klutiero wrote: > Hi Pádraig, > > On 2012-01-20 19:03, Pádraig Brady wrote: >> On 01/20/2012 05:47 PM, Filipus Klutiero wrote: >>> Hi Pádraig and Jim, >>> >>> On 2012-01-20 09:15, Pádraig Brady wrote: >>>> On

Re: dd: add 'skip_bytes' and 'count_bytes' operands

On 02/07/2012 06:25 PM, Jérémy Compostella wrote: >> On 02/06/2012 03:24 PM, Jérémy Compostella wrote: >> >> Hmm, shouldn't there be a seek_bytes param too for consistency? >> > That was effectively my first mail question. As you talk about it in >> > your explanation addition in coreutils.texi I g

Re: [PATCH] test: expose recent gnulib canonicalize bug

On 02/07/2012 12:33 AM, Eric Blake wrote: > https://lists.gnu.org/archive/html/bug-gnulib/2012-02/msg00038.html > detailed a couple of bugs in gnulib's canonicalize that were visible > through coreutils' readlink, but only on systems where // is distinct > from /. This particular test assumes that

Re: dd: add 'skip_bytes' and 'count_bytes' operands

On 02/08/2012 03:14 PM, Jérémy Compostella wrote: >> That leads onto the only other possible implementation I suppose. >> I.E. since we don't need to specify skip and skip_bytes together, >> the option value could select between each mode. I.E. >> >> skip=2 => skip2 blocks, >> skip=2b

Re: [PATCH] test: expose recent gnulib canonicalize bug

On 02/08/2012 04:14 PM, Eric Blake wrote: > Question before I push: Right now, we have: > > tests/readlink/can-{e,f,m} > tests/readlink/rl-1 > tests/misc/readlink-fp-loop > > This feels inconsistent; should we be consolidating all readlink-related > tests into the same directory, and if so, whic

Re: "ls -l": Avoid unnecessary getxattr() overhead

On 02/09/2012 11:32 AM, Jim Meyering wrote: > @@ -2918,10 +2935,17 @@ gobble_file (char const *name, enum filetype type, > ino_t inode, > { >bool have_selinux = false; >bool have_acl = false; > - int attr_len = (do_deref > - ? get

Re: "ls -l": Avoid unnecessary getxattr() overhead

On 02/09/2012 02:17 PM, Jim Meyering wrote: > Pádraig Brady wrote: >> On 02/09/2012 11:32 AM, Jim Meyering wrote: >>> Technically, we could probably exempt all files on that device, but >>> ... >> >> So you avoid symlinks as they can point outside the devi

Re: "ls -l": Avoid unnecessary getxattr() overhead

On 02/09/2012 09:17 PM, Sven Breuner wrote: > Jim Meyering wrote on 02/09/2012 03:17 PM: >> Pádraig Brady wrote: >>> On 02/09/2012 11:32 AM, Jim Meyering wrote: >>>> Technically, we could probably exempt all files on that device, but >>>> ... >>>

Re: dd: add 'skip_bytes' and 'count_bytes' operands

On 02/10/2012 04:21 PM, Jérémy Compostella wrote: > Pádraig, others, > > First, I added the missing seek_bytes feature. > Second, I re-wrote the patch in order to replace the _bytes operands by the > corresponding input/output flags. > Finally, I added some tests to check the new seek_bytes flag.

Re: sort complexity on nearly sorted input

On 02/11/2012 04:20 PM, Peng Yu wrote: > Hi, > > I assume the time complexity of 'sort' is log N, where N is the input size. > > But I'm not familiar with 'sort' enough to tell the complexity of > sorting a nearly sorted input. Suppose that I have a listed of N > numbers, there only k numbers (k

Re: "ls -l": Avoid unnecessary getxattr() overhead

On 02/12/2012 01:01 AM, Sven Breuner wrote: > Pádraig Brady wrote on 02/10/2012 02:03 AM: >> On 02/09/2012 09:17 PM, Sven Breuner wrote: >>> Current git version patched... >>> >>> $ time ~/tmp/ls-8.15.34-31eee_patched -l>/dev/null >>> >>> re

Re: dd: add 'skip_bytes' and 'count_bytes' operands

On 02/10/2012 04:57 PM, Pádraig Brady wrote: > On 02/10/2012 04:21 PM, Jérémy Compostella wrote: >> Pádraig, others, >> >> First, I added the missing seek_bytes feature. >> Second, I re-wrote the patch in order to replace the _bytes operands by the >> correspondi

Re: Paste more than two files

On 02/12/2012 02:36 AM, goodman@gmail.com wrote: > Hi Coreutils, > > I posted to the list about a month ago and haven't gotten any > response. Perhaps it got overlooked because of the holidays (or > post-holiday email glut), so I'm reposting it: > > --- > > Hello, > > I fairly recently disc

Re: dd: add 'skip_bytes' and 'count_bytes' operands

On 02/13/2012 07:50 AM, Bernhard Voelker wrote: > On 02/10/2012 05:21 PM, Jérémy Compostella wrote: > > Sorry, this is a bit late, but I have 2 notes about the > new dd/bytes test: > >> diff --git a/tests/dd/bytes b/tests/dd/bytes >> new file mode 100755 >> index 000..6038742 >> --- /dev/null

Re: dd: add 'skip_bytes' and 'count_bytes' operands

On 02/13/2012 10:13 AM, Bernhard Voelker wrote: > > > On 02/13/2012 11:00 AM, Pádraig Brady wrote: >> On 02/13/2012 07:50 AM, Bernhard Voelker wrote: >>> On 02/10/2012 05:21 PM, Jérémy Compostella wrote: >>> >>> Sorry, this is a bit late, but I ha

Re: dd: add 'skip_bytes' and 'count_bytes' operands

I've just noticed a couple of edge case issues. The first hunk is for when not doing I/O, ftruncate() should be on the full size. The second, will not invalidate cache for the whole file, if 0 < count < ibs cheers, Pádraig. --- a/src/dd.c +++ b/src/dd.c @@ -2170,7 +2170,7 @@ main (int argc, cha

Re: dd: add 'skip_bytes' and 'count_bytes' operands

On 02/13/2012 02:28 PM, Bernhard Voelker wrote: > > > On 02/13/2012 02:09 PM, Pádraig Brady wrote: >>> BTW: shouldn't >>>>echo abcdefghijklm | src/dd bs=5 seek=8 oflag=seek_bytes >>>> receive EPIPE? When run on a terminal, dd waits in read()

Re: dd: add 'skip_bytes' and 'count_bytes' operands

On 02/13/2012 06:41 PM, Jérémy Compostella wrote: > Pádraig, > > I took a closer look to the last test case. I wrote it during the > development phase. At this time, I forced the skip() function to failed > in order to test the line 1896 algorithm. > > I just made some test and was unable to make

Re: Adding humanize_number to coreutiles?

On 02/13/2012 03:45 AM, Peng Yu wrote: > 2012/2/7 Pádraig Brady : >> On 02/07/2012 03:36 AM, Peng Yu wrote: >>> Hi, >>> >>> Several commands in coreutils have the -h option. I'm wondering >>> whether anybody in the develop team also thinks that

Re: join on multiple field

On 02/13/2012 01:54 PM, Peng Yu wrote: >> Can't you already do this with awk? > > This is not a very useful comment. Take things on this list as discussion, rather than a mandate. We're all very open here. > Everything that coreutils do can be > done with some other software. Since 'join' can do

Re: Adding humanize_number to coreutiles?

On 02/14/2012 12:59 PM, Jim Meyering wrote: > Pádraig Brady wrote: > ... >> Looking more at this, you might be right. >> Now printf already has related formatting functionality: >> >> $ env LANG=fa_IR.utf8 printf "%I'd\n" 1234 >> ۱٬۲۳۴ >>

Re: [PATCH]: add an option for quiet copy operations

On 02/16/2012 07:21 AM, Guido Trentalancia wrote: > Hello. > > I am writing to propose a simple patch for review. The patch adds an > option "-q" or "--quiet" to cp, mv and install so that they can support > quiet operation on missing SOURCE files. > > Such behavior might be useful for example wh

Re: [PATCH]: add an option for quiet copy operations

On 02/16/2012 02:01 PM, Pádraig Brady wrote: > On 02/16/2012 07:21 AM, Guido Trentalancia wrote: >> Hello. >> >> I am writing to propose a simple patch for review. The patch adds an >> option "-q" or "--quiet" to cp, mv and install so that they c

Re: bug#9085: 'split' feature request: an option to uses e.g. '.001' as first suffix.

On 02/16/2012 09:30 PM, Jérémy Compostella wrote: > Pádraig, all, > > I rebased my branch for this feature and make the syntax-check > success. I attached the new patch which I hope will satisfy you. > > Feel free to comment it, I will take into account whatever you want. Thanks for continuing w

Re: "ls -l": Avoid unnecessary getxattr() overhead

On 02/16/2012 07:39 PM, Jim Meyering wrote: > diff --git a/src/ls.c b/src/ls.c > +/* st_dev of the most recently processed device for which > + we've found that getfilecon or lgetfilecon fails with > + e.g., ENOTSUP or EOPNOTSUPP. */ > +static dev_t selinux_challenged_device; > + > +/* Cache

[PATCH] doc: fix a typo about seek_bytes in NEWS

* NEWS: s/count_bytes/seek_bytes/2 --- NEWS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/NEWS b/NEWS index 2080790..7973b55 100644 --- a/NEWS +++ b/NEWS @@ -4,7 +4,7 @@ GNU coreutils NEWS-*- outline -*- ** New features - dd no

Re: bug#9085: 'split' feature request: an option to uses e.g. '.001' as first suffix.

On 02/17/2012 05:56 PM, Jérémy Compostella wrote: > I attached the new patch. I tried to make it as simple as possible but > feel free to comment. Thanks! I just grouped the operations in next_file_name() a little for clarity, tweaked a couple of strings, and pushed. cheers, Pádraig.

Re: bug#6554: [PATCH] split: Additional suffix for split (bug#6554)

On 02/18/2012 12:52 PM, Jérémy Compostella wrote: > All, > > I'm continuing with this feature implementation. Getting advantage on my > newly acquired experience on this project I made some changes in my > implementation. > > Now I have a concern about the option name "--suffix". I think the > --

Re: bug#6554: [PATCH] split: Additional suffix for split (bug#6554)

On 02/18/2012 02:51 PM, Jérémy Compostella wrote: >> That's a good point. --additional-suffix is better. >> >> Note csplit has a more general --suffix-format option >> (which can be shortened to --suffix). >> So one can do: --suffix="%02d.txt". >> However that's only possible, because csplit >> su

Re: [PATCH] doc: fix filenames in split --filter=command example

On 02/18/2012 07:02 PM, Jérémy Compostella wrote: > All, > > A very small fix in documentation. Good catch. pushed. cheers, Pádraig.

Re: "ls -l": Avoid unnecessary getxattr() overhead

On 02/19/2012 08:57 AM, Jim Meyering wrote: > Sven Breuner wrote: > >> Jim Meyering wrote on 02/09/2012 03:17 PM: >>> Here's that simpler patch: >>> [...] >> >> Jim Meyering wrote on 02/17/2012 01:11 PM: >>> Here's the updates series, along with this addition to NEWS: >>> [...] >> >> Thanks for al

Re: bug#6554: [PATCH] split: Additional suffix for split (bug#6554)

On 02/19/2012 12:54 PM, Jérémy Compostella wrote: > Pádraig, > > I replaced --suffix with --additional-suffix and made some cleaning. > > Feel free to comment the attached patch. Logic is perfect again. I adjusted the help output a little like: - -a, --suffix-length=N use suffixes of length

Re: bug#6554: [PATCH] split: Additional suffix for split (bug#6554)

On 02/19/2012 06:30 PM, Jérémy Compostella wrote: >> On 02/19/2012 12:54 PM, Jérémy Compostella wrote: >> > Pádraig, >> > >> > I replaced --suffix with --additional-suffix and made some cleaning. >> > >> > Feel free to comment the attached patch. >> >> Logic is perfect again. > Thanks :) > >> I a

Re: "ls -l": Avoid unnecessary getxattr() overhead

On 02/19/2012 10:22 PM, Sven Breuner wrote: > Jim Meyering wrote on 02/19/2012 06:00 PM: >> Pádraig Brady wrote: >>> > From Sven's strace it seems that lgetfilecon() is interpreting >>> the "unlabeled" return from lgetxattr() and converting that >&g

Re: "ls -l": Avoid unnecessary getxattr() overhead

On 02/20/2012 02:06 AM, Sven Breuner wrote: > Pádraig Brady wrote on 02/20/2012 12:54 AM: >> On 02/19/2012 10:22 PM, Sven Breuner wrote: >>> Is there maybe another check that could be used to find out if selinux is >>> disabled? (e.g. is_selinux_enabled(3) ) >> &

Re: "ls -l": Avoid unnecessary getxattr() overhead

On 02/19/2012 05:00 PM, Jim Meyering wrote: > Pádraig Brady wrote: >> Also I was a bit surprised to see EBUSY and ENOENT in errno_unsupported(). >> Can one assume there are no other attributes on a device if you get those? > > I added those to align with ACL_NOT_WELL_SUP

Re: [PATCH v2] ln: add the --relative option

On 02/23/2012 09:28 PM, Eric Blake wrote: > On 02/23/2012 12:50 PM, har...@redhat.com wrote: >> From: Harald Hoyer >> >> With the "--relative --symbolic" options, ln computes the relative >> symbolic link for the user. >> >> So, ln works just as cp, but creates relative symbolic links instead >> o

Re: [PATCH v2] ln: add the --relative option

On 02/24/2012 07:58 AM, Voelker, Bernhard wrote: > har...@redhat.com wrote: > >> With the "--relative --symbolic" options, ln computes the relative >> symbolic link for the user. > > I also like this idea. > >> $ ln -s -v --relative usr/bin/foo usr/lib/foo/link-to-foo >> 'usr/lib/foo/link-to-foo

Re: split: support unlimited number of split files

On 02/24/2012 10:08 PM, Jérémy Compostella wrote: > All, > > I'm interesting in implementing this feature. In fact, I already made a > quick implementation to play with. > > I refer to the original thread : "split behavior" > http://lists.gnu.org/archive/html/bug-coreutils/2009-09/msg00217.html >

unix core command index

I look this stuff up all the time, so I decided to create an index. Hopefully others find it useful: http://www.pixelbeat.org/docs/unix_commands/ cheers, Pádraig.

Re: "ls -l": Avoid unnecessary getxattr() overhead

On 02/26/2012 10:56 PM, Sven Breuner wrote: > Pádraig Brady wrote on 02/20/2012 11:54 AM: >> On 02/20/2012 02:06 AM, Sven Breuner wrote: >>> Pádraig Brady wrote on 02/20/2012 12:54 AM: >>>> I just booted RHEL 6.2 with selinux=0 on the kernel command line, >>>

Re: [PATCH] doc: fix a wrong option reference in split invocation

On 02/26/2012 02:12 PM, Jérémy Compostella wrote: > All, > > I think there is a mistake in the output file names format description > of the split invocation section. Indeed, there is a reference to a > nonexistent option (-r). I think the right option is --number with r/n > (round-robin distribut

[PATCH] maint: refactor copy to use is_nul()

* src/dd.c: Move is_nul() from here to ... * src/system.h: ... here * src/copy.c (sparse_copy): Adjust to use the refactored is_nul() --- src/copy.c | 33 +++-- src/dd.c | 21 - src/system.h | 21 + 3 files changed, 28

Re: split: support unlimited number of split files

On 03/01/2012 07:44 PM, Jérémy Compostella wrote: > Hi Pádraig, > > Finally, I found time to work again on this patch. I provided it as > attachment. > > I'm not completely satisfied with the documentation part. I've tried to > be more specific but it becomes quickly complicated. So I get back th

[PATCH] tests: work around a block alignment issue in dd/sparse

Prompted by the continuous integration build failure at: http://hydra.nixos.org/build/2188210 (which uses XFS). * tests/dd/sparse (alloc_equal): Add a block allocation comparison function that accounts for variations due to alignment. --- tests/dd/sparse | 14 -- 1 files changed, 12

Re: split: support unlimited number of split files

On 03/02/2012 04:27 PM, Jérémy Compostella wrote: >>> [...] >> That's problematic. >> Is your locale ar_SA? as that's the only one >> on my system that triggers: > My locale is fr_FR.utf8 > >> for loc in $(locale -a | grep -vF .); do >>echo $loc; printf "%s\n" 2 1 . | LC_ALL=$loc sort >> do

bug#10926: Minor problem with static building of coreutils-8.1[345]

On 03/02/2012 09:35 AM, Heinz-Ado Arnolds wrote: > Hi, > > I have a minor problem with the *static* building of coreutils. Building > "timeout" requires libpthread in addition to librt. > > A simple patch is enclosed. > > Thanks a lot for your great work and kind regards, Is this on an older gl

Re: split: support unlimited number of split files

On 03/02/2012 05:07 PM, Jérémy Compostella wrote: >> Ah drats, yes you need to check the combinations. >> >> $ printf "%s\n" .b a. | LC_ALL=en_US sort >> a. >> .b >> >> $ printf "%s\n" . a | LC_ALL=en_US sort >> . >> a > Yep. BTW, do you know where I could find the sorting rules for each > locale?

Re: split: support unlimited number of split files

On 03/02/2012 05:39 PM, Jérémy Compostella wrote: > Pádraig, others, > > Do you know where I could find the sorting rules for each locale (for my > personal interest)? They're part of glibc and installed on my Fedora system by default. /usr/share/i18n/locales/fr_FR /usr/share/i18n/locales/iso1

Re: basename BSD compatibility and filter mode

On 03/03/2012 02:10 PM, Jérémy Compostella wrote: > All, > > I'm interesting in implementing these features: > > 1. basename BSD options and behavior compatibility: > > Add the following options: > -s, --suffix: specify the suffix > -a, --multiple: every argument is treated as a string as if bas

Re: basename BSD compatibility and filter mode

On 03/03/2012 07:58 PM, Jérémy Compostella wrote: >> On 03/03/2012 02:10 PM, Jérémy Compostella wrote: >>> All, >>> >>> I'm interesting in implementing these features: >>> >>> 1. basename BSD options and behavior compatibility: >>> >>> Add the following options: >>> -s, --suffix: specify the suffix

Re: basename BSD compatibility and filter mode

On 03/04/2012 07:19 PM, Jérémy Compostella wrote: >> BTW, dirname suffers the same limitation I propose to add the BSD >> options support too to this command. What do you think? > I made a mistake. BSD does not provide any option to the dirname > command, however it supports multiple arguments. > $

Re: basename BSD compatibility and filter mode

On 03/05/2012 09:07 AM, Bernhard Voelker wrote: > On 03/03/2012 10:00 PM, Pádraig Brady wrote: >> Yes, I agreed with Eric that -0 was useful, > > If basename is used as a filter in the middle of pipe, > then I think it maybe would make sense to have a 0-option > for the outp

Re: basename BSD compatibility and filter mode

On 03/04/2012 07:09 PM, Jérémy Compostella wrote: >> [...] >> I just logged onto an OS X box there and you're right: >> >> $ printf "%s\n" 1/1 2/2 | xargs basename >> 1 >> >> $ printf "%s\n" 1/1 2/2 3/3| xargs basename >> 1 >> 2 >> 3 >> >> However I think it's dangerous to do that. >> If I was writ

Re: basename BSD compatibility and filter mode

On 03/07/2012 02:02 AM, Pádraig Brady wrote: > On 03/04/2012 07:09 PM, Jérémy Compostella wrote: >>> [...] >>> I just logged onto an OS X box there and you're right: >>> >>> $ printf "%s\n" 1/1 2/2 | xargs basename >>> 1 >&g

Re: [PATCH] doc: NEWS: correct "bug introduced in ..." version number

On 03/09/2012 06:37 AM, Bernhard Voelker wrote: > This fixes a typo in the NEWS of commit > f7f398a du: fix -x: don't ignore non-directory arguments > yesterday. > > Have a nice day, > Berny > > >>From e3d303036345db49ace5fcd7216ac64c52bf024a Mon Sep 17 00:00:00 2001 > From: Bernhard Voelker

Re: [PATCH] basename: add -z option missing documentation

On 03/09/2012 03:10 PM, Jérémy Compostella wrote: > All, > > The basename -z option documentation is missing. > > The attached patch provides it. Ouch. Thanks will apply. cheers, Pádraig.

Re: bug#10983: ready for a release?

tag 10983 notabug On 03/09/2012 05:47 PM, Jim Meyering wrote: > There are more than enough new features to justify a release, > not to mention the three bug fixes. > > Anything worth waiting for? Well the dirname multi argument processing to complement the basename seems simple and worth waiting

Re: split: support unlimited number of split files

On 03/01/2012 07:44 PM, Jérémy Compostella wrote: > Hi Pádraig, > > Finally, I found time to work again on this patch. I provided it as > attachment. > > I'm not completely satisfied with the documentation part. I've tried to > be more specific but it becomes quickly complicated. So I get back th

Re: split: support unlimited number of split files

On 03/10/2012 11:13 AM, Jérémy Compostella wrote: > BTW, reviewing your changes I discovered that when a user specifies a > suffix length zero the old behavior was to use the default length of 2 > and the new is, of course, the suffix auto length way. Well spotted. I noticed that too, but thought

Re: split: support unlimited number of split files

On 03/10/2012 02:25 PM, Jérémy Compostella wrote: > 2012/3/10 Pádraig Brady : >> On 03/10/2012 11:13 AM, Jérémy Compostella wrote: >> >>> BTW, reviewing your changes I discovered that when a user specifies a >>> suffix length zero the old behavior was to use the de

Re: [PATCH 4/6] realpath: let --relative-to default to --relative-base

On 03/14/2012 08:38 PM, Eric Blake wrote: > Most of the time, if someone wants to filter which paths are > relative while leaving all others absolute, they also want to > to the filtering based on the same --relative-to directory. > Make this easier to specify. > --- a/src/realpath.c > +++ b/src/r

Re: [PATCH 0/6] realpath cleanups

On 03/14/2012 08:38 PM, Eric Blake wrote: > As promised, here's my cleaned up series for http://debbug.gnu.org/10472 This is very thorough. I can't find any logic issues at all. > I'm not sure whether to squash 2 and 3 into one patch. separate is fine > I'm not sure whether we want patch 6/6, s

Re: [PATCH 0/6] realpath cleanups

On 03/14/2012 10:15 PM, Eric Blake wrote: > On 03/14/2012 04:04 PM, Pádraig Brady wrote: >> On 03/14/2012 08:38 PM, Eric Blake wrote: >>> As promised, here's my cleaned up series for http://debbug.gnu.org/10472 >> >> This is very thorough. >> I can'

Re: new snapshot available: coreutils-8.15.74-be17e3

t.c |1 + 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index e600a1d..61a1ef0 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2012-03-16 Pádraig Brady + + localecharset: don't map US-ASCII to UTF-8 on Darwin + * lib/localch

Re: new snapshot available: coreutils-8.15.74-be17e3

I see the new sort-discrim test fails on systems without GMP (in this case solaris). The attached should fix it. cheers, Pádraig. >From 020469e65861bac3d62a7d0bb197431bfb957647 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= Date: Fri, 16 Mar 2012 11:23:13 + Subject: [PATCH] t

[PATCH] tests: avoid an ls-time false positive on Solaris 10

There was a spurious failure on tmpfs on Solaris 10. The attached should avoid it. cheers, Pádraig. >From 48cffb9656e8ed9f243ca9ab21f271980f618819 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= Date: Fri, 16 Mar 2012 12:51:04 + Subject: [PATCH] tests: avoid an ls-time false p

Re: new snapshot available: coreutils-8.15.74-be17e3

After my patches mentioned previously in this thread, I get no failures on Fedora 15 2.6.40.4-5.fc15.x86_64 Mac OS X 10.6.8 Kernel 10.8.0: i386 Debian 5.0 2.6.26-2-sparc64-smp Solaris 10 SPARC-Enterprise-T5220 cheers, Pádraig.

Re: coreutils-8.15.74-be17e3 on FreeBSD 6.4

On 03/17/2012 02:18 AM, Bruno Haible wrote: > On FreeBSD 6.4/x86, the following tests fail: > > FAIL: misc/sort-discrim > FAIL: misc/sort-float > FAIL: cp/preserve-slink-time > FAIL: dd/sparse > > Two of these were already reported in >

Re: coreutils-8.15.74-be17e3 on OpenBSD

This is from the dd/sparse failure: On 03/17/2012 02:31 AM, Bruno Haible wrote: > + alloc_equal file.in file.out > + : 4 > +++ stat -c %b file.in > +++ stat -c %b file.out > ++ expr 4160 - 4128 > + alloc_diff=32 > ++ echo 32 > ++ tr -d -- - > + alloc_diff=32 > + test 32 -le 4 > + fail=1 That conf

Re: coreutils-8.15.74-be17e3 on OpenBSD

On 03/17/2012 10:11 AM, Jim Meyering wrote: > Pádraig Brady wrote: >> This is from the dd/sparse failure: >> >> On 03/17/2012 02:31 AM, Bruno Haible wrote: >>> + alloc_equal file.in file.out >>> + : 4 >>> +++ stat -c %b file.in >>> +++ sta

Re: coreutils-8.15.74-be17e3 on Solaris

On 03/17/2012 04:16 PM, Jim Meyering wrote: > Bruno Haible wrote: > >> On Solaris 9 and 10, there are 2 test failures: >> >> FAIL: misc/sort-discrim >> >> FAIL: dd/sparse >> >> These were not present in the previous test >> . > >

Re: [PATCH] maint: fix typo in comment in stat.c

On 03/19/2012 11:23 PM, Bernhard Voelker wrote: > -/* Print the context information of FILENAME, and return true iff the > +/* Print the context information of FILENAME, and return true if the I think that's more correct/descriptive as is. cheers, Pádraig.

Re: [PATCH v2] ln: add the --relative option

On 02/24/2012 12:12 AM, Pádraig Brady wrote: > On 02/23/2012 09:28 PM, Eric Blake wrote: >> On 02/23/2012 12:50 PM, har...@redhat.com wrote: >>> From: Harald Hoyer >>> >>> With the "--relative --symbolic" options, ln computes the relative >>>

Re: [PATCH v2] ln: add the --relative option

Attached is a mergeable version. I'd be inclined to include this in the imminent release given the unlikely impact on existing code? cheers, Pádraig. >From d8889826af3f5eec1e19ef10f964c9b037f4b5a5 Mon Sep 17 00:00:00 2001 From: Harald Hoyer Date: Thu, 23 Feb 2012 20:50:27 +0100 Subject: [PATCH] l

[PATCH] maint: ensure PATH_MAX is set correctly

* src/system.h: Include gnulib's pathmax.h to ensure we set PATH_MAX only if needed. --- src/system.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/system.h b/src/system.h index 49cd08a..e3773bf 100644 --- a/src/system.h +++ b/src/system.h @@ -41,6 +41,7 @@ you must

Re: [PATCH] maint: ensure PATH_MAX is set correctly

On 03/22/2012 10:53 AM, Eric Blake wrote: > On 03/21/2012 10:53 PM, Pádraig Brady wrote: >> * src/system.h: Include gnulib's pathmax.h to ensure >> we set PATH_MAX only if needed. >> --- >> src/system.h |1 + >> 1 files changed, 1 insertions(+), 0 deleti

Re: [PATCH v2] ln: add the --relative option

Thanks for the review. I agree with all points, and split the patch as Eric suggested, and pushed. cheers, Pádraig.

Re: dd/sparse test failure on Solaris (zfs-backed?) NFS

Maybe just require_local_dir_ ? Offline for a few hours now. cheers, Pádraig.

Re: How to explicte specify -t be the "non-blank to blank transition"?

On 03/28/2012 11:07 PM, Peng Yu wrote: > Hi, > > I don't see a way to explicit set -t to "non-blank to blank > transition", although implicit it is set so. Is there a way to > explictly set -t to "non-blank to blank transition"? No. > More general, is > there a way to set the separator to other

Re: [PATCH v2] ln: add the --relative option

On 02/24/2012 01:04 PM, Eric Blake wrote: > On 02/24/2012 04:11 AM, Pádraig Brady wrote: >>> >>> Why restrict this to symlinks - it could also be useful for >>> hardlinks, right? >> >> Well hardlinks reference inodes and so are independent >>

Re: scp sparse dd file

On 04/02/2012 10:30 PM, Simon Hintermann wrote: > Hello all, > > I have a tricky one (so do I think)... > > My virtual machines are raw-based files, created with a "dd if=/dev/zero > of=.. bs=1M count=0 seek=12", for example. > > As I want to have native I/O performances on my servers, I do

Re: [PATCH] maint: replace a use of strcpy in chmod.c with memcpy

On 04/16/2012 04:45 PM, Jim Meyering wrote: > This is on the edge... > I generally prefer to use memcpy when the length is already computed, > so I propose to do that here. However, this is certainly not > performance sensitive, and the strcpy invocation is slightly simpler > and hence a little mo

[PATCH] maint: fix common spelling errors in comments

From: Kevin Lyda These were identified using: https://github.com/lyda/misspell-check * src/cat.c: Correct a single spelling error. * src/comm.c: Likewise. * src/expr.c Likewise. * src/pr.c Likewise. * src/tac.c Likewise. * src/test.c Likewise. --- src/cat.c |4 ++-- src/comm.c |2 +- s

Re: crusade against strncpy/strcpy ;-)

On 04/19/2012 12:15 PM, Jim Meyering wrote: > strncpy is particularly bad, but even strcpy is best avoided. Yep, strncpy may not NUL terminate, so using it is awkward as detailed here: http://www.pixelbeat.org/programming/gcc/string_buffers.html stpcpy/stpncpy are appropriate here as the buffer i

[PATCH] maint: avoid reading lots of data from /dev/urandom

On Solaris 10 at least you need to use dd iflag=fullblock to avoid short reads. Also it's relatively slow when you just want non NUL data as opposed to pseudo random data. * cp/fiemap-empty: Convert /dev/zero rather than using /dev/urandom. * dd/sparse: Likewise. --- tests/cp/fiemap-empty |2

Re: [PATCH] maint: avoid reading lots of data from /dev/urandom

On 04/24/2012 11:48 AM, Jim Meyering wrote: > Pádraig Brady wrote: >> On Solaris 10 at least you need to use dd iflag=fullblock >> to avoid short reads. Also it's relatively slow when >> you just want non NUL data as opposed to pseudo random data. >> >> * cp/

Re: [PATCH] maint: avoid reading lots of data from /dev/urandom

On 04/24/2012 12:53 PM, Bernhard Voelker wrote: > > > On 04/24/2012 01:15 PM, Pádraig Brady wrote: >>> With those changes, the affected files are then very compressible. >>>> With some file system types/options, won't they occupy far fewer >>>> bloc

Re: Split command wait - Request

On 04/26/2012 01:39 AM, Quinton Dunning wrote: > To whom it may concern, > > Sometimes when I execute the split command I want to use removable media and > take a file part over to another machine. To do this, the split command would > have to have a switch that would pause and wait for a keystr

Re: mkdir -pm bug?

On 04/27/2012 12:52 PM, Henrikki Almusa wrote: > Hi, > > I have a situation where I want to create with a script a directory path > based on input. The mkdir -p allows this nicely. However since I want to > enforce certain permissions on it I thought that I can use mkdir -pm to > create this. H

Re: Another rfe: "cp" this time

On 04/27/2012 03:32 PM, Bruce Korb wrote: > Our corporate infrastructure only allows CIFS shares. No FTP access. > No scp access. Nope. Gotta be CIFS. One of these is on the other > side of the pond. The pipe is fairly fat, but very, very long. > Sometimes, like yesterday, after 8 hours of cop

Re: Another rfe: "cp" this time

I was just comparing all options. > 2012/4/27 Pádraig Brady : >>> I can either add this to cp, or roll my own toy. What say you? >> >> Yes, cp is bad for high latency links as it has a >> 32KiB buffer which it serially reads to and writes from. > > The throughput is

Re: Another rfe: "cp" this time

On 04/27/2012 06:47 PM, Pádraig Brady wrote: > On 04/27/2012 06:15 PM, Bruce Korb wrote: >> Thank you for the suggestions. I did finish my particular task with rsync, >> but I'd still like something that finishes in less than 10 hours. > > Just to be clear, you

<    1   2   3   4   5   6   7   8   9   10   >