Re: use of renameat2

2015-11-18 Thread Pádraig Brady
On 18/11/15 16:05, Eric Blake wrote: > Where could we use the new Linux renameat2() syscall within coreutils, > if it is available? Oftentimes, having a working client of a syscall > for a few filesystems is incentive for other filesystems to prioritize > implementing support for the syscall.

use of renameat2

2015-11-18 Thread Eric Blake
Where could we use the new Linux renameat2() syscall within coreutils, if it is available? Oftentimes, having a working client of a syscall for a few filesystems is incentive for other filesystems to prioritize implementing support for the syscall. I'm really impressed by renameat2()'s ability

Wishlist Feature Request: wc

2015-11-18 Thread Craig Sanders
wc would be improved if it had two new options: --no-total --no-filenames These would eliminate the need to pipe into `awk '$2 != "total" {print $1}'` or similar to remove totals and filenames from the output when wc has more than one file arg. thanks, craig -- craig sanders

Re: Wishlist Feature Request: wc

2015-11-18 Thread Stephane Chazelas
2015-11-18 22:55:34 +1100, Craig Sanders: > wc would be improved if it had two new options: > >--no-total >--no-filenames > > These would eliminate the need to pipe into `awk '$2 != "total" {print > $1}'` or similar to remove totals and filenames from the output when wc > has more than

Re: Wishlist Feature Request: wc

2015-11-18 Thread Pádraig Brady
On 18/11/15 13:26, Stephane Chazelas wrote: > 2015-11-18 22:55:34 +1100, Craig Sanders: >> wc would be improved if it had two new options: >> >>--no-total >>--no-filenames >> >> These would eliminate the need to pipe into `awk '$2 != "total" {print >> $1}'` or similar to remove totals and

[PATCH] build: fix VPATH build with --disable-dependency-tracking

2015-11-18 Thread Pádraig Brady
* src/local.mk: `mkdir -p src` in all our explicit rules, as in a VPATH build the src/ dir is only built as a side effect of dependency tracking generation. --- src/local.mk | 9 + 1 file changed, 9 insertions(+) diff --git a/src/local.mk b/src/local.mk index 0cfa7f5..31d0506 100644 ---

Re: Enhancement request for tee - please add the option to not quit on SIGPIPE when someother files are still opened

2015-11-18 Thread Bob Proulx
Pádraig Brady wrote: > Already done in the previous v8.24 release: Bob Proulx wrote: > If you ignore SIGPIPE in tee in the above then what will terminate the > tee process? Since the input is not ever terminated.

Re: Enhancement request for tee - please add the option to not quit on SIGPIPE when someother files are still opened

2015-11-18 Thread Pádraig Brady
On 18/11/15 22:50, Jirka Hladky wrote: > Hello tee developers, > > I have recently run into an issue that tee will finish as soon as first pipe > it's writing to is closed. Please consider this example: > > $cat /dev/zero | tee >(head -c1 | wc -c ) >(head -c100M | wc -c ) >/dev/null > 1 >

Re: Enhancement request for tee - please add the option to not quit on SIGPIPE when someother files are still opened

2015-11-18 Thread Bob Proulx
Jirka Hladky wrote: > I have recently run into an issue that tee will finish as soon as first > pipe it's writing to is closed. Please consider this example: > > $cat /dev/zero | tee >(head -c1 | wc -c ) >(head -c100M | wc -c ) >/dev/null > 1 > 65536 > > Second wc command will receive only 64kB

Enhancement request for tee - please add the option to not quit on SIGPIPE when someother files are still opened

2015-11-18 Thread Jirka Hladky
Hello tee developers, I have recently run into an issue that tee will finish as soon as first pipe it's writing to is closed. Please consider this example: $cat /dev/zero | tee >(head -c1 | wc -c ) >(head -c100M | wc -c ) >/dev/null 1 65536 Second wc command will receive only 64kB instead of