On 08/04/10 11:18, Bakul Shah wrote:
bsdgrep when used this way doesn't quit but doesn't do
anything either (including printing what tail -f spits out
from existing file data).
Does adding --line-buffered to the grep command line change the behavior
at all?
--
Improve the effectiven
Em 2010.08.04. 20:06, Xin LI escreveu:
I'm able to reproduce the GNU behavior on 9.0-CURRENT which is IMO right.
I think we need to break at the line end to provide better interactivity
(the current code seems to do it (buffer is not full&& !eof), while
what we wanted is (buffer is not full&&
Hi,
On Wed, Aug 04, 2010 at 07:39:41PM +0900, Takanori Watanabe wrote:
> In message <201008040347.o743leer046...@sana.init-main.com>, wrote:
> >Quick review and hack:
> >
> >1.How about attaching it as acpi child driver?
> >
> >In some case, TPM may appear in ACPI namespace (with _HID) and
> >TPM
On Tue, 03 Aug 2010 20:21:56 +0200 Gabor Kovesdan wrote:
> Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
> > Hi,
> >
> > It seems bsdgrep does not work when piped from tail -f.
> > I'm running r210728.
> >
> > term0$ jot 10> /tmp/1
> > term0$ tail -f /tmp/1 | grep 0
> > [no outpu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2010/08/03 11:21, Gabor Kovesdan wrote:
> I've checked on 8.0 and GNU grep doesn't output anything either for me.
> If you use tail -f, you will enter more lines and end it with EOF, won't
> you? And then BSD grep will process the input and print
On Tue, 3 Aug 2010, Gabor Kovesdan wrote:
Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
Hi,
It seems bsdgrep does not work when piped from tail -f.
I'm running r210728.
term0$ jot 10> /tmp/1
term0$ tail -f /tmp/1 | grep 0
[no output]
otherterm$ jot 10>> /tmp/1
[no output to
On 4 August 2010 20:28, Lars Engels wrote:
> On Wed, Aug 04, 2010 at 10:51:08AM -0400, Alexandre Sunny Kovalenko wrote:
>> On Tue, 2010-08-03 at 20:21 +0200, Gabor Kovesdan wrote:
>> > Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
>> > > Hi,
>> > >
>> > > It seems bsdgrep does not
On Wed, Aug 04, 2010 at 06:28:10PM +0200, Lars Engels wrote:
> On Wed, Aug 04, 2010 at 10:51:08AM -0400, Alexandre Sunny Kovalenko wrote:
> > On Tue, 2010-08-03 at 20:21 +0200, Gabor Kovesdan wrote:
> > > Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
> > > > Hi,
> > > >
> > > > It s
On Wed, Aug 04, 2010 at 06:28:10PM +0200, Lars Engels wrote:
> On Wed, Aug 04, 2010 at 10:51:08AM -0400, Alexandre Sunny Kovalenko wrote:
> > On Tue, 2010-08-03 at 20:21 +0200, Gabor Kovesdan wrote:
> > > Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
> > > > Hi,
> > > >
> > > > It s
On Wed, Aug 04, 2010 at 10:51:08AM -0400, Alexandre Sunny Kovalenko wrote:
> On Tue, 2010-08-03 at 20:21 +0200, Gabor Kovesdan wrote:
> > Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
> > > Hi,
> > >
> > > It seems bsdgrep does not work when piped from tail -f.
> > > I'm running r21
Kostik Belousov wrote:
BTW, -1 is ERESTART, so if you have SIGINT catched with SA_RESTART
flag in the process that initiated kldload(2) syscall, then -1
is the right return code for cv_wait_sig.
Ah, makes sense. I hadn't considered that a BSD kernel
error could be negative. I should have ac
On Wed, Aug 04, 2010 at 06:46:04PM +0300, Kostik Belousov wrote:
> On Wed, Aug 04, 2010 at 10:36:24AM -0400, Andrew Gallatin wrote:
> > Hi,
> >
> > I recently noticed that cv_wait_sig() will return -1
> > rather than EINTR when a SIGINT is delivered. This is
> > in contrast to CONDVAR(9) which st
On Wed, Aug 04, 2010 at 10:36:24AM -0400, Andrew Gallatin wrote:
> Hi,
>
> I recently noticed that cv_wait_sig() will return -1
> rather than EINTR when a SIGINT is delivered. This is
> in contrast to CONDVAR(9) which states:
>
> <...>
> cv_wait_sig() and cv_timedwait_sig() return prematur
On Tue, 2010-08-03 at 20:21 +0200, Gabor Kovesdan wrote:
> Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
> > Hi,
> >
> > It seems bsdgrep does not work when piped from tail -f.
> > I'm running r210728.
> >
> > term0$ jot 10> /tmp/1
> > term0$ tail -f /tmp/1 | grep 0
> > [no output]
Hi,
I recently noticed that cv_wait_sig() will return -1
rather than EINTR when a SIGINT is delivered. This is
in contrast to CONDVAR(9) which states:
<...>
cv_wait_sig() and cv_timedwait_sig() return prematurely with a
value of EINTR or ERESTART if a signal is caught
<...>
To demo
On 08/03/2010 14:21, Gabor Kovesdan wrote:
Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
Hi,
It seems bsdgrep does not work when piped from tail -f.
I'm running r210728.
term0$ jot 10> /tmp/1
term0$ tail -f /tmp/1 | grep 0
[no output]
otherterm$ jot 10>> /tmp/1
[no output to t
On Tue, 03.08.2010 at 17:21:45 -0700, Steve Kargl wrote:
> On Tue, Aug 03, 2010 at 05:40:05PM -0400, Thomas Dickey wrote:
> > On Tue, Aug 03, 2010 at 11:22:36AM -0700, Julian Elischer wrote:
> > > On 8/3/10 2:34 AM, pluknet wrote:
> > > >Hi.
> > > >
> > > >I looked into sys/kern/* files to fix a bu
In message <201008040347.o743leer046...@sana.init-main.com>, wrote:
>Quick review and hack:
>
>1.How about attaching it as acpi child driver?
>
>In some case, TPM may appear in ACPI namespace (with _HID) and
>TPM spec defines ACPI method to handle TPM specific request.
>
>2. Is identify method need
Hi,
On 3 Aug 2010, at 18:58, Jamie Gritton wrote:
> I always understood that is was a style error *not* to have at least
> some whitespace before a label, that only top-level objects should be
> pushed all the way to the left column. Style(9) appears to be silent on
> this issue.
Labels are spec
On Tue, 27 Jul 2010, Anton Shterenlikht wrote:
> On Tue, Jul 27, 2010 at 05:53:25PM +0100, Gavin Atkinson wrote:
> > On Tue, 2010-07-27 at 15:47 +0100, Anton Shterenlikht wrote:
> > > db> bt
> > > Tracing pid 0 tid 10 td 0x80b40de0
> > > kdb_enter() at kdb_enter+0x3d
> > > panic() at p
20 matches
Mail list logo
