On Wed, Mar 27, 2019 at 09:52:21AM -0500, David Wright wrote:
[...]
> But my point was that prodding the program with signals seemed a
> better fit than just forcing line buffering.
...and I still disagree with that (under most conditions, that is).
Cheers
-- t
signature.asc
Description:
On Tue 26 Mar 2019 at 17:55:28 (+0100), to...@tuxteam.de wrote:
> On Tue, Mar 26, 2019 at 11:43:24AM -0500, David Wright wrote:
>
> [...]
>
> > So these are issues beyond the scope of the OP's problem domain.
> > OTOH, IMO, trapping a USR1 signal [...]
>
> In this case, an atexit handler seems
On Tue, Mar 26, 2019 at 05:37:49PM -, Curt wrote:
> On 2019-03-26, wrote:
> >
> >
> > On Tue, Mar 26, 2019 at 11:43:24AM -0500, David Wright wrote:
> >
> > [...]
> >
> >> So these are issues beyond the scope of the OP's problem domain.
> >> OTOH, IMO, trapping a USR1 signal [...]
> >
> > In
On 2019-03-26, wrote:
>
>
> On Tue, Mar 26, 2019 at 11:43:24AM -0500, David Wright wrote:
>
> [...]
>
>> So these are issues beyond the scope of the OP's problem domain.
>> OTOH, IMO, trapping a USR1 signal [...]
>
> In this case, an atexit handler seems the right tool. Since the
> OP is using
On Tue, Mar 26, 2019 at 11:43:24AM -0500, David Wright wrote:
[...]
> So these are issues beyond the scope of the OP's problem domain.
> OTOH, IMO, trapping a USR1 signal [...]
In this case, an atexit handler seems the right tool. Since the
OP is using Perl, the END {...} block is our friend.
On Mon 25 Mar 2019 at 10:47:08 (+0100), to...@tuxteam.de wrote:
> On Sun, Mar 24, 2019 at 11:17:54AM -0500, David Wright wrote:
> > On Sat 23 Mar 2019 at 18:23:47 (+0100), to...@tuxteam.de wrote:
> > > On Sat, Mar 23, 2019 at 10:27:01AM -0500, David Wright wrote:
> > > > On Fri 22 Mar 2019 at
On Sun, Mar 24, 2019 at 11:17:54AM -0500, David Wright wrote:
> On Sat 23 Mar 2019 at 18:23:47 (+0100), to...@tuxteam.de wrote:
> > On Sat, Mar 23, 2019 at 10:27:01AM -0500, David Wright wrote:
> > > On Fri 22 Mar 2019 at 17:45:50 (+0100), to...@tuxteam.de wrote:
> >
> > > Reading the OP's
Martin McCormick wrote:
> deloptes writes:
>> I just wonder why one would do that, but it is again your business.
>
> In all but a very small handful of countries around the
> world, the hobby of amateur radio exists and it's justification
> for existence is to allow people to self-train as to
deloptes writes:
> I just wonder why one would do that, but it is again your business.
In all but a very small handful of countries around the
world, the hobby of amateur radio exists and it's justification
for existence is to allow people to self-train as to how
electronic
Martin McCormick wrote:
> Apparently, the flush after each new cycle of data isn't
> taxing the system too much as the output looks correct. This is
> a 600 MHZ Pentium which would have gone in to the recycle bin
> years ago if not for Linux. Older systems like this tend to
> accentuate the
On Sunday 24 March 2019 14:25:47 Martin McCormick wrote:
> David Wright writes:
> > On Sat 23 Mar 2019 at 18:23:47 (+0100), to...@tuxteam.de wrote:
> > > On Sat, Mar 23, 2019 at 10:27:01AM -0500, David Wright wrote:
> > > > On Fri 22 Mar 2019 at 17:45:50 (+0100), to...@tuxteam.de wrote:
> > > >
David Wright writes:
> On Sat 23 Mar 2019 at 18:23:47 (+0100), to...@tuxteam.de wrote:
> > On Sat, Mar 23, 2019 at 10:27:01AM -0500, David Wright wrote:
> > > On Fri 22 Mar 2019 at 17:45:50 (+0100), to...@tuxteam.de wrote:
> >
> > > Reading the OP's problem, I wonder how you're meant to detect
>
On Sat 23 Mar 2019 at 18:23:47 (+0100), to...@tuxteam.de wrote:
> On Sat, Mar 23, 2019 at 10:27:01AM -0500, David Wright wrote:
> > On Fri 22 Mar 2019 at 17:45:50 (+0100), to...@tuxteam.de wrote:
>
> > Reading the OP's problem, I wonder how you're meant to detect
> > "any whiff of a problem"
Lee writes:
> https://unix.stackexchange.com/questions/25372/turn-off-buffering-in-pipe/
>
> Regards,
> Lee
Thank you and all others. It turns out that getting the
autoflush to work in perl is on a par with falling off of a log
for ease of execution.
There is a perl variable
On Sat, Mar 23, 2019 at 10:27:01AM -0500, David Wright wrote:
> On Fri 22 Mar 2019 at 17:45:50 (+0100), to...@tuxteam.de wrote:
> Reading the OP's problem, I wonder how you're meant to detect
> "any whiff of a problem" [...]
Torture tests.
> The main concern raised in the OP was flushing before
On Fri 22 Mar 2019 at 17:45:50 (+0100), to...@tuxteam.de wrote:
> On Thu, Mar 21, 2019 at 07:52:33PM -0500, Martin McCormick wrote:
>
> [...]
>
> > Opening, appending and closing for each new line of
> > output made me a bit squeamish. The program is monitoring a
> > stream of data from a
On Thu, Mar 21, 2019 at 07:52:33PM -0500, Martin McCormick wrote:
[...]
> Opening, appending and closing for each new line of
> output made me a bit squeamish. The program is monitoring a
> stream of data from a radio scanner. The data spew in at about
> 20 or 30 lines per second.
Don't
On Fri, 22 Mar 2019, at 00:53, Martin McCormick wrote:
> Opening, appending and closing for each new line of
> output made me a bit squeamish. ...
You could always count lines written and do a close & reopen
every (say) 1000 lines. That way there's less overhead but
the amount of data
Martin McCormick wrote:
> Before reading this posting, I added code in my perl
> script to open, append and close the file but the suggestion to
> add a signal handler is a much better idea so thanks for the
> suggestion.
I always use
# Execute anytime before the .
# Causes the currently
David Wright writes:
> An efficient way of doing this is to trap a signal, like USR1,
> in your program, and react by either your close/open-append or
> just flushing the buffers. That way, the program will run
> normally most of the time, without wasting all that time
> opening/closing files.
>
On 3/21/19, Martin McCormick wrote:
> I have been using unix of various flavors for 30 years so
> this is a bit of a bone-head question except that different
> styles of unix handle this situation somewhat differently.
>
> Imagine that you run a process whose output you want to
>
On Thu 21 Mar 2019 at 11:35:51 (-0500), Martin McCormick wrote:
> I wrote the application that is creating this output in
> perl and there may be a unique solution there that solves this specific
> problem. That is not as good as a general course of action which
> works in all cases of
Try stdbuf.
On Thu, Mar 21, 2019 at 06:01:26PM -, Curt wrote:
> I'm reading a pty app won't buffer (script, screen, etc.).
Well, it's a convention, adopted by the C library functions in stdio.
stdio(3) says:
At program startup, three text streams are predefined and need not be
opened
On 2019-03-21, wrote:
>
>
> On Thu, Mar 21, 2019 at 10:32:06AM -0400, Kenneth Parker wrote:
>> Have you tried the Command Line: "sync"?
>
> That won't help in the OP's case, I think: sync is about writing out
> the operating system's buffers to the file system. In the OP's case
> it's about
On Thu, Mar 21, 2019 at 12:46:17PM -0400, Greg Wooledge wrote:
> On Thu, Mar 21, 2019 at 11:35:51AM -0500, Martin McCormick wrote:
> > I wrote the application that is creating this output in
> > perl
>
> https://perl.plover.com/FAQs/Buffering.html
This is it, thanks, Greg.
Most run times
On Thu, Mar 21, 2019 at 11:35:51AM -0500, Martin McCormick wrote:
> I wrote the application that is creating this output in
> perl
https://perl.plover.com/FAQs/Buffering.html
Kenneth Parker writes:
> Have you tried the Command Line: "sync"?
Excellent question and I did, in fact, try that command
just before killing the running process.
It had no effect.
also writes:
> That won't help in the OP's case, I think: sync is about writing out
> the
On Thu, Mar 21, 2019 at 10:32:06AM -0400, Kenneth Parker wrote:
> Have you tried the Command Line: "sync"?
That won't help in the OP's case, I think: sync is about writing out
the operating system's buffers to the file system. In the OP's case
it's about the process's I/O buffers which haven't
Have you tried the Command Line: "sync"?
Kenneth Parker
I have been using unix of various flavors for 30 years so
this is a bit of a bone-head question except that different
styles of unix handle this situation somewhat differently.
Imagine that you run a process whose output you want to
catch so you run it as someproc >catchfile. The
31 matches
Mail list logo
