Re: suggested feature/patch for ls: -P TYPES, --select-file-type=TYPES

I don't think that fits. As I see it, ls is an end user tool, i.e. output generally goes direct to the end user. If you would like a more progamatic way of selecting files then `find` is more appropriate. (find has a -type option for example). The shell can also be used to expand just directorie

Re: on "dd" using "seek" vs. "read" & >32-bit sizes

Linda Walsh wrote: > Sometimes I would like "dd" to copy the contents of > "Random-Block-Object-A" > to "Random-Block-Object-B", starting from the middle of of the file. > > I can specify the "seek=BLOCKS" param, but it appears that "dd" doesn't > translate this to a "seek" command but instead use

Re: "sort" utility short comming or bug: cannot sort according to "human format" criterion.

Andre Gompel wrote: >Dear colleague: > it looks like a bug... or at least a short comming. > >If I use the -n or -g option I cannot sort according to the output format of >the "du" or "ls" commands. > >Example: > > du -chs * |sort -n |more > >I am not sure what would be the best approach,

Re: "sort" utility short comming or bug: cannot sort according to "human format" criterion.

Pádraig Brady wrote: >Andre Gompel wrote: > > > >>Dear colleague: >> it looks like a bug... or at least a short comming. >> >>If I use the -n or -g option I cannot sort according to the output format of >>the "du" or "ls" command

Re: rln, a potential new core util

David Laurence Emerson wrote: ># rln by David Laurence Emerson <[EMAIL PROTECTED]> ># version 0.01 ># 2006-02-21 ># ># This bash script is insanely slow and would be well replaced by a c ># implementation. ># ># rln stands for "relative (sym)link". It helps create symlinks by ># intelligently fin

controlling stdio buffering

I was trying today to filter my access.log apache log with some coreutils and was annoyed by the default buffering applied by glibc. I was trying to do `tail -f ~/access.log | cut ... | uniq` but I was only getting output when cut had more than 4K written to stdout. So how to control this? Well ea

Re: controlling stdio buffering

Andreas Schwab wrote: >Pádraig Brady <[EMAIL PROTECTED]> writes: > > > >>p. p.s. Note glibc changes the buffering automatically for stdout only like: >>if (isatty(fileno(stdout)) setlinebuf(stdout) >>Also it always leaves

Re: controlling stdio buffering

Paul Eggert wrote: >If this is merely for debugging, can't you write a wrapper that forces >line buffering for a program? The wrapper could substitute your own C >library functions via LD_PRELOAD, or could run the program inside a >pseudotty a la 'expect'. > > No I was thinking of a more simple

Re: controlling stdio buffering

Paul Eggert wrote: >Pádraig Brady <[EMAIL PROTECTED]> writes: > > > >>Paul Eggert wrote: >> >> >>>If this is merely for debugging, can't you write a wrapper that forces >>>line buffering for a program? The wrapper could substitu

Re: possible bug in coreutils?

Bob Proulx wrote: >Scott Griffith wrote: > > >>I was just looking at the man page for grep, and wouldn't you know >>it.. --line-buffer is not very well documented. Infact, all it >>says about that is: >> >>(excerpt from man page) >>--line-buffering >> Use line buffering, it can be

Re: Support for SIGSTOP/SIGCONT in nice?

Jim Meyering wrote: >Simon Josefsson <[EMAIL PROTECTED]> wrote: >... > > >>Still, maybe not all programs have similar rate-limiting features, so >>that this nice-extension may be useful anyway... >> >> > >I agree. Maybe even as a separate program, for when you start something >important and

Re: uniq -z

Egmont Koblinger wrote: >Hi, > >Plenty of text utilities are able to work with lines terminated by zero >bytes instead of newlines. "sort" is one example, which has an internal uniq >support, so "sort -z -u" sorts the input and removes adjacent identical >zero-terminated strings. > >However, stand

Re: stty is braind dead or I am

mark manning wrote: > >stty -F /dev/tts/12 returns "speed 9600 baud" and some other stuff. yet when i connect that port to a cable going to a windows box running hyperterm i get NO data at all at that baud rate. set windows box to 2400 and i get the transmitted data just right. this means that

Re: Not sure how to best reply re: dir_colors situation

Michael Kerrisk wrote: > 2009/6/8 Pádraig Brady : >> Michael Kerrisk wrote: >>> 2009/6/7 Pádraig Brady : >>>> So I guess the middle ground is best of "not enable by default", >>>> though that will require adding documentation for the option. &g

Re: [PATCH] stdbuf work in progress

Update with fixed whitespace and added copyright message to libstdbuf.c: http://www.pixelbeat.org/patches/stdbuf.diff Eric mentioned that cygwin might support LD_PRELOAD also, but again libtool might be involved in supporting that correctly? cheers, Pádraig. ___

Re: Not sure how to best reply re: dir_colors situation

Kamil Dudka wrote: > Hi Pádraig, > > On Sunday 07 June 2009 16:35:23 Pádraig Brady wrote: >> Turn off completely is my vote, as hardlinks have their own column. >> I polled my local LUG with a non leading question and >> nobody came up with a reason for coloring hard

Re: Not sure how to best reply re: dir_colors situation

Hmm, it's worth adding a test at least to demonstrate that file permissions take precedence over hardlink coloring I.E. multi hardlinked png and exectuable files will be colored inconsistently. diff attached. cheers, Pádraig. >From 656b4273135e50746956dc04b47d1ed96f851d96 Mon Sep 17 00:00:00 2001

Re: bug in "sort -n -k1.4,1.2"

Thanks for the analysis and patch! I'll take a look at this this evening as I've been looking at this area recently. cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [PATCH] stdbuf work in progress

Jim Meyering wrote: > Pádraig Brady wrote: >> Update with fixed whitespace and added copyright message to libstdbuf.c: >> >> http://www.pixelbeat.org/patches/stdbuf.diff > > Thanks. > I tried to build on Fedora 10 x86_64 and got this: > > /usr/bin/ld: ../lib

Re: Not sure how to best reply re: dir_colors situation

Matthew Woehlke wrote: > Pádraig Brady wrote: >> Hmm, it's worth adding a test at least to demonstrate that >> file permissions take precedence over hardlink coloring >> I.E. multi hardlinked png and exectuable files will be colored >> inconsistently. > > I

Re: bug in "sort -n -k1.4,1.2"

Cliff Miller wrote: > hi, > > i have a bug to report in coreutils-7.4. the problem occurs with > empty fields under -n/-g, specifically in sub-field specifications where > end < start. according to the docs, > >> If the start position in a sort field specifier falls after the end of >> the lin

sort --key-debug

I find it quite difficult to determine correct key positions to use, especially given the complicated rules for (global) -b options etc. I wonder would it be useful to add a --key-debug option, which would mark in the output the keys used. For multibyte locales you could use: ⌜key1⌟ blah blah⌜ ke

Re: wc

Iram CHELLI wrote: > Hello, > > > i am using wc in shell scripts > > the exact command is: > > wc FILE | cut -d " " -f 2 You probably want to squeeze adjacent blanks: wc FILE | tr -s '[:blank:]' ' ' | cut -d' ' -f2 cheers, Pádraig. ___ Bug-co

Re: wc

Pádraig Brady wrote: > > You probably want to squeeze adjacent blanks: > > wc FILE | tr -s '[:blank:]' ' ' | cut -d' ' -f2 Note you might wonder why cut doesn't support -d'[:blank:]' to auto skip runs of horizontal whitespace. Details he

Re: [PATCH] Rebasing on Padraig's gnulib fallocate module and cleaning up

Matěj Cepl wrote: > Hi, > > the craziness around F11 finished so I am using a little bit of > time I have to make one more round of my truncate/fallocate > patch (together with mkfile script). I wanted to make my patch > working with the Pádraig's fallocate gnulib module and clean up > tests (they

Re: bug in "sort -n -k1.4,1.2"

Cliff Miller wrote: > > the non-trivial case here is when -b is present in the form > > sort -k2.1b,2.3 > > where the start and end positions could be in either order depending > on the number of blanks that start field 2. Right, good point. I've added a test for that case also and pushed

Re: [PATCH] stdbuf work in progress

Pádraig Brady wrote: > Jim Meyering wrote: >> I tried to build on Fedora 10 x86_64 and got this: >> >> /usr/bin/ld: ../lib/libcoreutils.a(quote.o): relocation R_X86_64_32 against >> `a local symbol' can not be used when making a shared object; recompile with &

Re: [PATCH] Rebasing on Padraig's gnulib fallocate module and cleaning up

Eric Sandeen wrote: > Pádraig Brady wrote: > > ... > >> On a related note it looks like fallocate64() which is required >> on 32 bit systems will not be supported in glibc-2.10 as it >> was released as a glibc-2.11 symbol. That means that 32 bit `cp` >> b

Re: [PATCH] stdbuf work in progress

Jim Meyering wrote: > Pádraig Brady wrote: >> http://www.pixelbeat.org/patches/stdbuf.diff > > Looking at the latest, I see this: > > + else > +{ > + setvbuf_mode = _IOFBF; > + /* Note this is done elsewhere in coreutils: > + verify (SIZE_M

Re: [PATCH] Rebasing on Padraig's gnulib fallocate module and cleaning up

Matej Cepl wrote: > Pádraig Brady, Sat, 13 Jun 2009 01:19:36 +0100: >> I was thinking that truncate --allocate would call posix_fallocate() >> which guarantees that the file is allocated even if the filesystem does >> not support fallocate(). I.E. we would need to add a posix_

Re: [PATCH] Rebasing on Padraig's gnulib fallocate module and cleaning up

Matej Cepl wrote: > Pádraig Brady, Mon, 15 Jun 2009 13:48:47 +0100: >> http://www.pixelbeat.org/patches/gnulib-fallocate.diff > > Could I get a branch of it? I hate following patches... I'll look at creating a github branch, though for this particular case it may be handi

Re: inotify back end for tail -f on linux

Jim Meyering wrote: > diff --git a/NEWS b/NEWS > index d7695e4..754f9e2 100644 > --- a/NEWS > +++ b/NEWS > @@ -28,6 +28,8 @@ GNU coreutils NEWS-*- > outline -*- >sort accepts a new option, --human-numeric-sort (-h): sort numbers >while honoring human re

Re: inotify back end for tail -f on linux

Jim Meyering wrote: > Pádraig Brady wrote: >> Jim Meyering wrote: >>> diff --git a/NEWS b/NEWS >>> index d7695e4..754f9e2 100644 >>> --- a/NEWS >>> +++ b/NEWS >>> @@ -28,6 +28,8 @@ GNU coreutils NEWS-*- >

Re: Shred recursive

Patterson, Shaun M Mr CTR USA AMC wrote: > I have implemented a -r/-R/--recursive option in shred. Anyone > interested or is piping shred with a find command enough? Hmm, it's one of those marginal ones. You wouldn't gain much really over using find. Though in saying that, rm has this option, so i

Re: Human readable sort

I was thinking that the mixed IEC/SI check should be applied to each key separately rather than globally. What do you think? Patch attached. cheers, Pádraig. >From ef06a30d122fc9ccac51a682a3abf6868d8832d6 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= Date: Tue, 30 Jun 2009 00:52

Re: README-prereq update

Matej Cepl wrote: > Eric Blake, Wed, 03 Jun 2009 06:58:02 -0700: > I'll update the automake info... >>> I just pushed this: >>> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=ba6e08c >> That's still misleading. Automake 1.11 is a stable release, and distros >> are starting to

[PATCH] doc: update the description of sort -b and -k

Updates and clarifications to sort --key and sort -b info cheers, Pádraig. >From 40fb295c23658596931684c50f34bd21cbd6f7f7 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= Date: Wed, 1 Jul 2009 15:07:19 +0100 Subject: [PATCH] doc: update the description of sort -b and -k * doc/core

Re: README-prereq update

Jim Meyering wrote: > Pádraig Brady wrote: >> automake-1.11 just went into Fedora 11 >> which started an interesting discussion :) >> https://www.redhat.com/archives/fedora-devel-list/2009-June/msg02451.html >> >> Anyway I've updated the development prerequi

Re: add "min" and "max" to coreutils?

Joshua Bronson wrote: > I was looking for a command line utility to get the min and max from a file > (rather than the much less efficient "sort | {head,tail} -1") and I couldn't > find one. Someone on linuxquestions.org directed me toward the Generic > Mapping Tools ,

Re: feature request: add optional $DESTDIR support to install

Etienne Laurin wrote: > Hello, > > By modifying install to support DESTDIR I was able to effortlessly > create packages for many source distributions that do not support > DESTDIR but use install. > > This patch adds the -P and --destdir options, which, if present, > prefix their argument or the

Re: add "min" and "max" to coreutils?

Joshua Bronson wrote: > > What are your concerns? Adding the kitchen sink to `sort`. Though if we were to add this functionality to coreutils, sort seems like the right place. I've often used sort | tail, but only for small data sets where the overhead is negligible. I'm leaning towards this be

Re: Feature request: rm should implement option -p, --parents

Guido Flohr wrote: > Hi, > > desired behavior: > > $ mkdir /usr/share/myapp > $ mkdir /usr/share/myapp/pixmaps > $ mkdir /usr/share/myapp/pixmaps/8x16 > $ install -m 644 icon.png /usr/share/myapp/pixmaps/8x16/ The above can be simplified to: dir="/usr/share/myapp/pixmaps/8x16" i

Re: Feature request: rm should implement option -p, --parents

Guido Flohr wrote: > > The case where the directory part is not known is quite frequent imho. I > configured a random GNU package (in this case gettext from the current > git sources), configured it with "--prefix=/tmp/my_gettext", then > "make", "make install", and "make uninstall", and finally r

sort default buffer size

I was surprised to notice sort was accessing the disk on multiple runs on a 500MB file on my 2GB RAM laptop. Here was my memory situation: $ free -m | head -n2 total used free sharedbuffers cached Mem: 2006603 1403 0 67

Re: [PATCH]: remove one duplicity in copy.c caused by factorization

Ondřej Vašík wrote: > Hello, > while making coreutils update for F-11, I spotted one duplicity in > copy.c caused by > http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=e0cf592f48b4e67dc31d0482ae4f4dbc820e883e > factorization commit. Attached patch removes this duplicity. Well spotted. I

Re: continuity error in ls man page

Eric K. Greer wrote: > --sort=WORD > extension -X, none -U, size -S, time -t, version -v, status -c, > time -t, atime -u, access -u, use -u > > > Time is listed twice Thanks. That was fixed quite a while ago (in coreutils-6.0): http://url.ie/1zd1 cheers, Pádraig.

Re: Broken --inverse flag.

Daniel Kersten wrote: > Hi, > > There appears to be a bug in coreutils. The --inverse flag appears to > be missing or broken from most utils. Hi Daniel, I see you're on the drink again. > Example: > > $ ps --inverse > -- ERROR: Unknown gnu long option. not a coreutil > $ ls --inverse > ls: un

Re: [PATCH] build: avoid build warn/failure due to -Wstack-protector

Jim Meyering wrote: > I got this build failure on i686/ubuntu-9.04: > > cc1: warnings being treated as errors > df.c: In function 'find_mount_point': > df.c:524: error: not protecting local variables: variable length buffer > [-Wstack-protector] > make[3]: *** [df.o] Error 1 I no

GSoC 2009

Just a note to inform you that Glen Lenker has has unfortunately dropped out of the Google summer of Code program due to other commitments. He was working on improving the performance when using the sort command on multicore machines. cheers, Pádraig. ___

Re: New sort(1) feature -- sort by length

Ethan Baldridge wrote: > I had a list to sort at work today that needed to be in the format "A B > C D E... AA BB CC DD" but sort(1) only returns results as "A AA B BB C > CC". > > > > So I wrote a patch to add -length-sort as an option. (-l was not taken > as a short option so I added that too

Re: ln documentation clarification

Sittser, Steven wrote: > I would like to suggest that you add a clarification to your > documentation of ln: > > In the invocation "ln [option]... target linkname", the target parameter > is interpreted very differently depending on whether or not the "-s" > option is present. If it is not, then

Re: New sort(1) feature -- sort by length

Ethan Baldridge wrote: > Pádraig Brady wrote: > >> Also it's quite easy to achieve with existing tools: >> awk '{print length, $0}' > That doesn't help in the case where you only need to sort on a given key in > the file. > A more complicated awk

Re: New sort(1) feature -- sort by length

Erik Auerswald wrote: > Hi, > > On Mon, Jul 20, 2009 at 01:54:18PM +0100, Pádraig Brady wrote: >> Ethan Baldridge wrote: >>> I'd argue on terms of obviousness: "I'm trying to sort these differently... >>> I should look at the options for sort!&q

Re: A request for addition of a command

Jim Meyering wrote: > +...@cindex canonical file name > +...@cindex canonicalize a file name Perhaps we should also index "realpath" since FreeBSD has realpath(1) as well as realpath(3)? cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gn

Re: A request for addition of a command

Jim Meyering wrote: > Pádraig Brady wrote: >> Jim Meyering wrote: >>> +...@cindex canonical file name >>> +...@cindex canonicalize a file name >> Perhaps we should also index "realpath" since FreeBSD has >> realpath(1) as well as realpath(3)? >

Re: New sort(1) feature -- sort by length

Jim Meyering wrote: > Pádraig Brady wrote: >> >> Also it's quite easy to achieve with existing tools: >> awk '{print length, $0}' > IMHO, this is a decisive argument for not adding the option. > However, I would welcome a paragraph documenting the techn

Re: A request for addition of a command

Jim Meyering wrote: > Kamil Dudka wrote: > >> Actually I don't know if we have some utility equivalent to >> canonicalize_file_name() function in coreutils now. > > We do. It's called readlink: > > Usage: readlink [OPTION]... FILE > Display value of a symbolic link on standard output. > > -f

[PATCH] doc: add a sort by line length example to sort info

Pádraig Brady wrote: > Jim Meyering wrote: >> Pádraig Brady wrote: >>> Also it's quite easy to achieve with existing tools: >>> awk '{print length, $0}' > IMHO, this is a decisive argument for not adding the option. >> However, I would welcome a p

[PATCH] doc: mention realpath in the readlink info

Pádraig Brady wrote: > Jim Meyering wrote: >> Pádraig Brady wrote: >>> Jim Meyering wrote: >>>> +...@cindex canonical file name >>>> +...@cindex canonicalize a file name >>> Perhaps we should also index "realpath" since FreeBSD has >

Re: BTRFS file clone support for cp

Giuseppe Scrivano wrote: > Hello, > > the BTRFS file system, avaiable on Linux since its 2.6.29 version, > supports file cloning. This simple patch adds the support for this > feature to the cp utility. Right, so using the COW feature of BTRFS to speed up copies, and reduce space by only writing

Re: table of contents of manual contains mistake

Benno Schulenberg wrote: > Hi, > > Instead of showing the six system-context commands under section 21 > (http://www.gnu.org/software/coreutils/manual/html_node/index.html#toc_System-context) > they are shown under section 22 (SELinux context) and in a slightly > different order. Maybe a newer ma

Re: [PATCH] tr: more descriptive help text

Heikki Orsila wrote: > --- > src/tr.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/tr.c b/src/tr.c > index e9338d4..8084447 100644 > --- a/src/tr.c > +++ b/src/tr.c > @@ -291,7 +291,7 @@ Usage: %s [OPTION]... SET1 [SET2]\n\ > Translate, squeeze, and/or delet

Re: [PATCH] tr: more descriptive help text

Jim Meyering wrote: > Pádraig Brady wrote: >> Heikki Orsila wrote: >>> --- >>> src/tr.c |2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/src/tr.c b/src/tr.c >>> index e9338d4..8084447 100644 >

Re: BTRFS file clone support for cp

Giuseppe Scrivano wrote: > Jim Meyering writes: > >>> Another possible issue with this I can think of is >>> depending on the modification pattern of the COW files, >>> the modification processes could fragment the file or >>> more seriously be given ENOSPC errors. >> I hope btrfs takes care of t

Re: table of contents of manual contains mistake

Pádraig Brady wrote: > Benno Schulenberg wrote: >> Hi, >> >> Instead of showing the six system-context commands under section 21 >> (http://www.gnu.org/software/coreutils/manual/html_node/index.html#toc_System-context) >> they are shown under section 22 (S

Re: BTRFS file clone support for cp

Chris Mason wrote: > On Tue, Jul 28, 2009 at 10:06:35PM +0200, Giuseppe Scrivano wrote: >> >> I can't replicate it now, all tests I am doing report that blocks used >> before and after the clone are the same. Probably yesterday the >> difference I noticed was in reality the original file flushed t

Re: BTRFS file clone support for cp

Chris Mason wrote: > On Wed, Jul 29, 2009 at 03:14:49PM +0100, Pádraig Brady wrote: >> >> We may need to play around with fallocate() >> if we want to get back to the original >> cp semantics of actually allocating space >> on the file system for the new file

Re: BTRFS file clone support for cp

Giuseppe Scrivano wrote: > Hi, > > I cleaned a bit the Pádraig's example in a new test case. tests, great! comments below. > The second patch fixes a problem that I introduced with the commit > e81c4d88c2fce526c02693d539e22c7468dc452b. I would have posted that patch in the other "tail" thread.

Re: BTRFS file clone support for cp

Jim Meyering wrote: > Joel Becker wrote: > >> On Wed, Jul 29, 2009 at 07:14:37PM +0100, Pádraig Brady wrote: >>> >>> At the moment we have these linking options: >>> >>> cp -l, --link #for hardlinks >>> cp -s, --symbolic-link #for symlink

Re: BTRFS file clone support for cp

Andi Kleen wrote: > Jim Meyering writes: >> Thanks. I haven't looked, but after reading about the reflink syscall >> [http://lwn.net/Articles/332802/] had come to the same conclusion: >> this feature belongs with ln rather than with cp. > > cp already has -l so it would make sense to extend that

Re: tail -f: --pid *and* inotify

I found another bug I think. Hopefully the attached is OK, but I'm not able to compile/test/push at the moment due to gnulib submodule weirdness. cheers, Pádraig. >From 45e2e5f26d4d7641c3ef2bfc3e47aab5bc93b8fe Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= Date: Thu, 30 Jul 2009

Re: BTRFS file clone support for cp

Jim Meyering wrote: > diff --git a/tests/tail-2/pid b/tests/tail-2/pid > > +# Ensure that tail --pid=PID exits successfully when PID is dead. > +# Use an unlikely-to-be-live PID: 2^31-1 > +getlimits_ > +tail --pid=$INT_MAX -f /dev/null || fail=1 Probably should use $PID_T_MAX You could speed up t

Re: BTRFS file clone support for cp

Joel Becker wrote: > In some sense, using btrfs, nilfs2i, ocfs2 with refcount trees > enabled, or any other CoW-ish filesystem is a tacit approval of the > delayed ENOSPC. The same can be said of "thin provisioning" LUNs. > However, the other concerns are still valid. A user invoking vanill

Re: BTRFS file clone support for cp

Giuseppe Scrivano wrote: > Hi Pádraig, > > thanks for the comments. > > Pádraig Brady writes: > >> # 300MB seems to be the minimum size for a btrfs with default >> parameters. > > Actually, it seems the minimum space required is 256MB. Using a 255MB >

Re: BTRFS file clone support for cp

Giuseppe Scrivano wrote: > Pádraig Brady writes: > >>> +#expensive_ >> That comment is just for testing I presume? >> Note you can run a single expensive test like: >> (cd tests && make check TESTS=cp/file-clone VERBOSE=yes >> RUN_EXPENSIVE_TESTS=y

Re: [RFC] fallocate utility

Eric Sandeen wrote: > Pádraig Brady wrote: >> Eric Sandeen wrote: > >>> TBH I think "truncate --allocate" sounds a little odd. (Now that I >>> think back, I think I mentioned this before). truncate(1) and >>> truncate(2) specifically refer to i_

Re: [PATCH] cp: preserve time stamps on symlinks, too

Jim Meyering wrote: > This patch may not be ready for prime time. > I wrote it and the test a few days ago, but haven't > gone back and looked closely. There are just too many > branches and use cases, and I'm sure I haven't considered > all of them. However, all tests do pass, at least on > rece

Re: [RFC] fallocate utility

Tilman Schmidt wrote: > Pádraig Brady schrieb: >> I don't see a problem in extending the meaning of the truncate command. >> Now truncate isn't the best name for the command but that name >> already existed in BSD and so I thought it best to align with that.

Re: [RFC] fallocate utility

Eric Sandeen wrote: > Giuseppe Scrivano wrote: >> Hello, >> >> Pádraig Brady writes: >> >>> Tilman Schmidt wrote: > > ... > >>>> Why not make it, in the best Unix tradition, a single >>>> executable whose action depends on

Re: BTRFS file clone support for cp

Giuseppe Scrivano wrote: > Jim Meyering writes: > >> I am now convinced that cp's new behavior belongs on >> a separate option, --reflink (i.e., it should not be the default). >> Giuseppe, do you feel like adding that option and adjusting your >> test accordingly? > > I attached two separate pat

Re: [PATCH] dd: work around buffer length restrictions with oflag=direct (O_DIRECT)

Jim Meyering wrote: > +#ifdef POSIX_FADV_DONTNEED > + off_t off = lseek (STDOUT_FILENO, 0, SEEK_CUR); > + if (0 <= off) > +ignore_value (posix_fadvise (STDOUT_FILENO, > + off, 0, POSIX_FADV_DONTNEED)); > +#endif That reminds me that it would be

Re: chmod feature request: setting different modes for files and directories

Tobia Conforto wrote: > Dear coreutils maintainers, > > I'd like to ask for an often needed feature of chmod: the ability to set > different modes for files and directories. I will briefly explain the > need, and then propose a possible syntax. > current: find some/path -type d -exec chmod g+s

Re: [PATCH] ls: Use pretty UTF-8 arrow when showing where symlinks point to

Lennart Poettering wrote: > [Second version of the patch, makes this feature optional with --fancy-chars] --fancy-chars :) I'm not sure how serious this patch is. How about: alias lsf='ls -l --color | sed "s/ -> / $(tput bold)\u25aa\u25b6$(tput sgr0) /"' cheers, Pádraig. p.s. this chunk is far

Re: [PATCH] ls: Use pretty UTF-8 arrow when showing where symlinks point to

Lennart Poettering wrote: > On Tue, 11.08.09 22:27, Pádraig Brady (p...@draigbrady.com) wrote: > >> this is equivalent I think: >> >>static const char *arrow = " -> "; >> #ifdef HAVE_NL_LANGINFO >>if (fancy_chars &&

Re: [PATCH] ls: Use pretty UTF-8 arrow when showing where symlinks point to

Jim Meyering wrote: > > - It's easy to get nearly the same effect with a simple filter, > as Pádraig suggested. (of course, a naive filter fails if > a file name contains " -> ", but the end result is solely for > human consumption, not for mechanical parsing, so that's ok) >

Re: [PATCH] ls: Use pretty UTF-8 arrow when showing where symlinks point to

Pádraig Brady wrote: > > Oh right, so something like: > > static const char *arrow; > if (!arrow) > { > if (fancy_chars && STREQ (locale_charset(), "UTF-8")) > arrow = " \xe2\x86\x92 "; > else > arrow = " ->

Re: no feedback on snapshot? coreutils-7.5 coming soon

Jim Meyering wrote: > AFAIK, I am the only one who has built the latest snapshot: > > http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/17604 > > Though it's been only two days. > > Unless I hear of new bug reports or portability problems soon, > expect coreutils-7.5 to be released in th

Re: no feedback on snapshot? coreutils-7.5 coming soon

Jim Meyering wrote: > > Thanks for the testing and report! > Are these new failures? If they are, it might be worth fixing. > Otherwise, FC5 is so old that I won't worry. > Reverting the symlink timestamp patch make the tests pass $ wget -q -O- 'http://git.savannah.gnu.org/gitweb/'\ '?p=coreut

Re: no feedback on snapshot? coreutils-7.5 coming soon

C de-Avillez wrote: > > Sorry for the delay, got busy. I just built & make check, and got two > errors. > > First one is here, I will re-run the second error by itself in a few. > > Running on Ubuntu 9.10 (kernel 2.6.31.5 with Ubuntu mods, libc6 > 2.10.1-0ubuntu6). > > FAIL: tail-2/pid > + tai

Re: no feedback on snapshot? coreutils-7.5 coming soon

Pádraig Brady wrote: > C de-Avillez wrote: >> Sorry for the delay, got busy. I just built & make check, and got two >> errors. >> >> First one is here, I will re-run the second error by itself in a few. >> >> Running on Ubuntu 9.10 (kernel 2.6.31.5

Re: no feedback on snapshot? coreutils-7.5 coming soon

While I'm at it here's a patch to improve that test. cheers, Pádraig. >From c720e160a96b813a7c24c5ac8a9a9a37590f4190 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= Date: Wed, 12 Aug 2009 19:46:27 +0100 Subject: [PATCH] tests: improve one of the tail --pid tests * tests/tail-2/pi

Re: no feedback on snapshot? coreutils-7.5 coming soon

Pádraig Brady wrote: > Jim Meyering wrote: >> AFAIK, I am the only one who has built the latest snapshot: >> >> http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/17604 >> >> Though it's been only two days. >> >> Unless I hear of new b

Re: dd killed with USR1 right after ftruncate()

Voelker, Bernhard wrote: > Hi *, > > short question: > is there a particular reason why the signal handlers are installed after > ftruncate() in dd? > > Long story: > I ran dd for a new backup of my 150GB partition to an external USB drive > while I started > while kill -USR1 pid ; do sle

Re: AW: dd killed with USR1 right after ftruncate()

Jim Meyering wrote: > Voelker, Bernhard wrote: >> Pádraig wrote: >> >>> What is your exact dd command please, and destination file system. >> I was running KNOPPIX 5.3.1; the source was a harddisk partition, and >> the target was a file in an ext2 filesystem on a harddisk in an USB device >> mounte

Re: AW: AW: dd killed with USR1 right after ftruncate()

Voelker, Bernhard wrote: > Pádraig wrote: >> Yep I think so. Moving just the install_signal_handlers() to the top, > > can we expect this to happen in one of the next releases? > >> p.s. I'm still unsure as to why open(O_TRUNC) takes "a while". >> Perhaps there is a trunc=paranoid mount option I'

Re: no feedback on snapshot? coreutils-7.5 coming soon

Jim Meyering wrote: > Pádraig Brady wrote: >> Subject: [PATCH] tail: fix tail -f failure when inotify used >> >> * src/tail.c (tail_inotify_forever): Use the correct bounds >> in the error check of the return from inotify_add_watch(). >> Reported by C de-Avil

Re: no feedback on snapshot? coreutils-7.5 coming soon

Jim Meyering wrote: > Pádraig Brady wrote: >> These highlighted a couple of issues I think on systems without utimensat(). >> >> 1. The symlink _target_ gets its time updated >> 2. If 1 fails then the process returns a failure >> >> I've fixed both in t

[PATCH] doc: clarify the cp --reflink NEWS

>From 3214858c9b53dcd8d2ef47473427fcd29dc56a7d Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= Date: Thu, 13 Aug 2009 17:25:09 +0100 Subject: [PATCH] doc: clarify the cp --reflink NEWS * NEWS: Remove the description associated with the removed experimental code which unconditional

Re: [RFC] fallocate utility

Karel Zak wrote: > On Fri, Jul 31, 2009 at 09:27:57PM +0100, Pádraig Brady wrote: >> I was thinking the new fallocate util would have the >> same options as the existing truncate util. >> I.E. -n or -o would not be needed or supportable in all situations. >> If you

Linus' sha1 is much faster!

I've noticed before that coreutils hashing utils were a little behind in performance, but was prompted to look at it again when I noticed the recently updated sha1 implementation in git: http://git.kernel.org/?p=git/git.git;a=history;f=block-sha1;h=d3121f7;hb=pu Testing that with the attached prog

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