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

Eric Sandeen mentioned that dd's O_DIRECT-exposing code didn't always work. The problem is that the kernel imposes draconian restrictions on the size of buffer that one may write to an FD opened with O_DIRECT. Currently, at least on ext4 and with a recent linux kernel, that buffer size must be a

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

Jim Meyering wrote: Eric Sandeen mentioned that dd's O_DIRECT-exposing code didn't always work. The problem is that the kernel imposes ... Here's the patch I expect to push soon: From 2f4004be6131e049a1452ee68377ae1756673bd4 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com

[PATCH] maint: move selinux-at module from gl/ to gnulib

FYI, I've just pushed this: From c5c15884dfef11379720bf360599b11a33d49ac0 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Thu, 6 Aug 2009 14:30:46 +0200 Subject: [PATCH] maint: move selinux-at module from gl/ to gnulib * gl/lib/selinux-at.c: Remove file. *

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

Jim Meyering wrote: Eric Sandeen mentioned that dd's O_DIRECT-exposing code didn't always work. The problem is that the kernel imposes draconian restrictions on the size of buffer that one may write to an FD opened with O_DIRECT. Currently, at least on ext4 and with a recent linux kernel,

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

Eric Sandeen wrote: Jim Meyering wrote: ... diff --git a/doc/coreutils.texi b/doc/coreutils.texi index acec76e..6fa2602 100644 --- a/doc/coreutils.texi +++ b/doc/coreutils.texi @@ -7861,6 +7861,10 @@ dd invocation @opindex direct @cindex direct I/O Use direct I/O for data, avoiding

tailing files that match a certain pattern

All, I was wondering how easy would it be to alter tail so that it looks for new files that match a certain pattern every few seconds to tail? I have an application where several temp files are created, and I don't know what they are in advance, eg: /tmp/newlog.$$ would create

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

Diego Pettenò complained that ls -l doesn't use the UTF-8 arrow character to show where symlinks point to. This tiny patch fixes that. With this applied the character is used when the CODESET is UTF-8 otherwise we fall back to the traditional - arrow. Ah, ls -l is so much prettier now with this

Re: tailing files that match a certain pattern

Edward Peschko wrote: All, I was wondering how easy would it be to alter tail so that it looks for new files that match a certain pattern every few seconds to tail? I have an application where several temp files are created, and I don't know what they are in advance, eg:

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

Hello Lennart, On Thu, Aug 06, 2009 at 07:24:42PM +0200, Lennart Poettering wrote: Diego Pettenò complained that ls -l doesn't use the UTF-8 arrow character to show where symlinks point to. This tiny patch fixes that. With this applied the character is used when the CODESET is UTF-8 otherwise

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

On Thu, 6 Aug 2009, Lennart Poettering wrote: Diego Petten? complained that ls -l doesn't use the UTF-8 arrow character to show where symlinks point to. This tiny patch fixes that. With this applied the character is used when the CODESET is UTF-8 otherwise we fall back to the traditional -

Re: tailing files that match a certain pattern

ok, thanks, I've been looking into inotify, I'll take a look at it.. Although I don't see why this functionality couldn't be integrated into tail.. would be exceedingly useful, instead of having to support two separate toolsets.. Ed

Re: tailing files that match a certain pattern

( ps - for everyone's consideration, http://distanz.ch/inotail/, which looks exactly like I want, but I would rather maintain one package.. would it be possible to merge the two? )