Re: Possible bug with grep/sed/tail?

Pádraig Brady wrote: > It's probably useful to add this functionality to all coreutil filters. > I still need to be convinced that glibc is not the correct place for this. > If it was there then any users of stdio could be controlled. It has been said before in previous threads but I want to re-s

Re: Possible bug with grep/sed/tail?

It's probably useful to add this functionality to all coreutil filters. Wouldn't it suffice to add buffer control options to cat, rather than every program? I still need to be convinced that glibc is not the correct place for this. If it was there then any users of stdio could be con

[PATCH] Don't do unneccesary memory copies in dd.

I was surprised that dd did memcpy() by default, which one can see using: ltrace -e memcpy dd if=/dev/zero of=/dev/null count=10 Now if you specify bs=512 for example a memcpy() is not done, which seems inconsistent to me. What about the attached patch to not do a memory copy in any of the combi

Re: Possible bug with grep/sed/tail?

On Thu, 20 Nov 2008, David Corlette wrote: Hello there, Wow, that's quite a cross-post you have there. Thoughts? Is there some limitation of which I am not aware that prevents this from working? Where does the data go in case D? It's all to do with buffering. The data is being held in a b

Possible bug with grep/sed/tail?

Hello there, I am not sure this is actually a bug as there may be reasons why it has to be this way, but certainly these tools work counter to my expectations. I am trying to read lines from a log file and pass them through grep or sed, and then on to another tool (netcat, for example). What I

Re: Possible bug with grep/sed/tail?

Paolo Bonzini wrote: >> A) # tail trace.txt | grep "com" >> - WORKS: produces output >> B) # tail trace.txt | grep "com" | cat >> - WORKS: produces output >> C) # tail -f trace.txt | grep "com" >> - WORKS: produces output, then waits and reports new lines >> D) # tail -f trace.txt | grep "com" | ca

Re: Possible bug with grep/sed/tail?

> Is there currently a way to do that? This problem has certainly caught > me out in the past (admittedly about ten years ago). sed has -u (unbuffered). I guess you can then emulate grep with "sed -un /foo/p". Paolo ___ Bug-coreutils mailing list Bu

Re: [PATCH]: ls: add --user-format option for user defined format

Jim Meyering wrote: > - is it worthwhile to add a --printf option to ls? > I don't like the --user-format name) You know my opinion ... I guess it is worthwhile, as the consumer of ls output is generally human and human wishes do differ. I'm ok with --printf option, you are right - it wo

Re: Possible bug with grep/sed/tail?

> A) # tail trace.txt | grep "com" > - WORKS: produces output > B) # tail trace.txt | grep "com" | cat > - WORKS: produces output > C) # tail -f trace.txt | grep "com" > - WORKS: produces output, then waits and reports new lines > D) # tail -f trace.txt | grep "com" | cat > - FAILS: no output from

Re: [PATCH] Add getlimits utility for use in tests

Take 4 attached >From 54322f168c42cd7f4bb4f62081a4866d18598a41 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= <[EMAIL PROTECTED]> Date: Thu, 20 Nov 2008 11:02:15 + Subject: [PATCH] Add getlimits utility for use in tests * src/getlimits.c: A utility to print platform dependent

Re: [PATCH]: ls: add --user-format option for user defined format

Jim Meyering wrote: > Actually, ever since find got its -printf option, I've thought of > adding the same to ls. But the size of the code addition as well as > the logistics (this was before gnulib) were off-putting, not to mention > the fact that this is ls, after all. That combined to make the

Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them

Andreas Schwab wrote: > Eric Blake <[EMAIL PROTECTED]> writes: > > > Would a double --verbose make sense? > > --verbose=2 Rather than some level-numbers I do prefer --verbose and --verbose=high ... Ondřej signature.asc Description: Toto je digitálně podepsaná část zprávy ___

Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them

Eric Blake <[EMAIL PROTECTED]> writes: > Would a double --verbose make sense? --verbose=2 Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And no

Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them

Eric Blake <[EMAIL PROTECTED]> wrote: > According to Ondřej Vašík on 11/20/2008 5:51 AM: >> For me verbose mode is something useful to track problems. Therefore I >> do prefer more informations there. Common usage of >> chown/chmod/chgrp/chcon utilities is without --verbose/--changes mode, >> so it

Re: [PATCH]: ls: add --user-format option for user defined format

Ondřej Vašík <[EMAIL PROTECTED]> wrote: > Pádraig Brady wrote: >> Ondřej Vašík wrote: >> > Let's do some summary, feel free to add/comment items if you have >> > something not mentioned here: >> > >> > What patched ls --user-format can and upstream find -printf not: >> > 1) colored files by LS_COLO

Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ondřej Vašík on 11/20/2008 5:51 AM: > For me verbose mode is something useful to track problems. Therefore I > do prefer more informations there. Common usage of > chown/chmod/chgrp/chcon utilities is without --verbose/--changes mode, > so

Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them

Jim Meyering wrote: > Ondřej Vašík <[EMAIL PROTECTED]> wrote: > > Throwing out "--changes" should be ok, if user wants to be informed, he > > can parse verbose output easily and common case is to use it without > > verbose mode at all. Anyway --verbose output is affected by this "issue" > > as well

Re: [PATCH] Add getlimits utility for use in tests

Pádraig Brady wrote: > Pádraig Brady wrote: >> First pass of tool to be used in test scripts >> internal to the coreutils project. > > Take 2. Previous one added erroneous '-' chars to > output depending on what was in memory. Take 3 passes `make syntax-check` EBUSY, Pádraig. >From 741e43bb68638

Re: [PATCH] Add getlimits utility for use in tests

Pádraig Brady <[EMAIL PROTECTED]> wrote: > Pádraig Brady wrote: >> First pass of tool to be used in test scripts >> internal to the coreutils project. > > Take 2. Previous one added erroneous '-' chars to > output depending on what was in memory. ... > +#include Thanks! Just a few nits... How a

Re: [PATCH] Add getlimits utility for use in tests

Pádraig Brady wrote: > First pass of tool to be used in test scripts > internal to the coreutils project. Take 2. Previous one added erroneous '-' chars to output depending on what was in memory. >From 31bf300f0ff2ab5b786bd6951e30a47e3c2db08c Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=

Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them

Ondřej Vašík <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> Ondřej Vašík <[EMAIL PROTECTED]> wrote: >> > as reported in >> > https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/187315 by Aaron >> > Toponce , chmod could display confusing messages when used for >> > SGID/SUID/sticky bits w

Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them

Jim Meyering wrote: > Ondřej Vašík <[EMAIL PROTECTED]> wrote: > > as reported in > > https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/187315 by Aaron > > Toponce , chmod could display confusing messages when used for > > SGID/SUID/sticky bits without permissions to change them. > > > > e.g.

Re: [PATCH]: ls: add --user-format option for user defined format

Pádraig Brady wrote: > Ondřej Vašík wrote: > > Let's do some summary, feel free to add/comment items if you have > > something not mentioned here: > > > > What patched ls --user-format can and upstream find -printf not: > > 1) colored files by LS_COLORS or automatically if requested > > 2) could b

[PATCH] Add getlimits utility for use in tests

First pass of tool to be used in test scripts internal to the coreutils project. >From 195f503da983966718d50e6e25482472e8dc4af4 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= <[EMAIL PROTECTED]> Date: Thu, 20 Nov 2008 11:02:15 + Subject: [PATCH] Add getlimits utility for use in

Re: Bug#505979: ls output format option

martin f krafft <[EMAIL PROTECTED]> wrote: > Package: coreutils > Version: 6.10-6 > Severity: wishlist > File: /bin/ls > > I wish ls supported something like > > ls --format='%n %s %u %t' > > or somesuch so that I can select which columns I actually want in > the output, and still have their widt

Re: Bug#412688: cp -la takes big amounts of memory

Jim Meyering <[EMAIL PROTECTED]> wrote: ... >>From 3ece0355d52e41a1b079c0c46477a32250278c11 Mon Sep 17 00:00:00 2001 > From: Jim Meyering <[EMAIL PROTECTED]> > Date: Wed, 19 Nov 2008 19:36:45 +0100 > Subject: [PATCH] cp: use far less memory in some cases > > cp --link was "remembering" many name,de

Re: Bug#412688: cp -la takes big amounts of memory

Jim Meyering <[EMAIL PROTECTED]> wrote: > This is following up on . > I realized that with --preserve=link --link, cp can do much better > on the memory front. It can avoid saving a lot of data that it > normally needs to reconstruct hard-link relationships. > > Wher

[PATCH] tests: add a test of cp --preserve=links

Just add a test... Before, we tested -L only with symlinked a and b (the primary case, since -L makes cp dereference symlinks). This also tests with them hard-linked. >From 3cc091a2afe244d222156e1d62e73b3fe612b2d7 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Wed, 19 Nov 20

[PATCH] cp: remove unused code

I noticed an unused function. >From e4c3f141f5e418e4c3336aaee6a4fadadae7eb97 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Wed, 19 Nov 2008 10:24:52 +0100 Subject: [PATCH] cp: remove unused code * src/cp-hash.c (remember_created): Remove unused function. Remove thus-obviat