Re: djbwares version 9
황병희 wrote: > On Wed, Mar 20 2019, Jonathan de Boyne Pollard wrote: > > ...snip... > >http://jdebp.eu./Softwares/djbwares/qmail-patches.html#any-to-cname > > just comment: > whenever i see these patches, i think qmail is not easy to handle. qmail is the easiest mail server to understand and configure. -dsr-
Program behaves differently depending on how started
Dear all, I have a problem with a program that once works well and once has a problem, depending on the way I start it. If I start kdenlive (video editing) by clicking on a file in dolphin, it works as expected, i.e. it can play music files as well as video clips including video and audio. If I start kdenlive by clicking on a desktop icon (KDE), via the start menu or by just typing kdenlive in a shell, it play video clips well but cannot play music files (I cannot hear them). I already checked using ps and both times /usr/bin/kdenlive is shown, both times running inside firejail, but if I start it in a shell circumventing firejail that doesn't change anything. So, there has to be a difference in "process context", right? How I can I check that? Unfortunately I'm all completely stumped in this case. Are there any ways how to compare two programs running in what they can do, can access, ...? Any idea how to proceed? Thanks for ideas and pointers, Bernd
Re: Program behaves differently depending on how started
Hi On 21. 03. 19 11:57, B.M. wrote: > So, there has to be a difference in "process context", right? How I can > I check that? Unfortunately I'm all completely stumped in this case. Most of the process context is available in the proc filesystem (see "man proc" for a list of what's in there) Get the PID of your kdenlive process from ps (first column usually). Then look in the /proc/[pid] (e.g. /proc/29937). First thing I would check is the process environment (/proc/[pid]/environ). You can format that file to be more readable with: xargs -0 -L1 -a /proc/[pid]/environ Best regards Tomaž signature.asc Description: OpenPGP digital signature
Flushing all Buffers Before Exiting
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 process has an end point so anything it produced gets saved in catchfile and all is well. Now imagine you run someproc and it either has no end condition or you haven't reached it yet so you kill it with Control-C. Some unixen like FreeBSD seem to flush all the buffers and you still get your output but Debian appears to not flush the buffers and you get nothing or maybe a partial capture with the most recent data lost. Is there a way to make sure we got everything that was produced? I have noticed that the tee program in Debian also appears to buffer data that get lost if you end early. Many thanks. Martin McCormick
Re: Flushing all Buffers Before Exiting
Have you tried the Command Line: "sync"? Kenneth Parker
Re: youtube video downloader for chrome
On Wed, 20 Mar 2019, Celejar wrote: On Wed, 20 Mar 2019 10:34:42 +0100 (CET) Pierre Frenkiel wrote: On Tue, 19 Mar 2019, riveravaldez wrote: Maybe worth mentioning: youtube-dl, exceptionally useful and simple CLI tool. useful and simple... but it works only for urls with alphanumeric characters I tried with an url containing ? and &, and I got nothing I tried also by escaping ? and & with \, and it was not better. I'll send you an example later, if you are not convinced... You can also try putting the url(s) in a file, and feeding the file to youtube-dl via its -a option. Celejar At last, I fixed everything just by loadind the last version of youtube-dl from the yt-dl site wget https://yt-dl.org/latest/youtube-dl -O /usr/local/bin/youtube-dl after that, I can do either youtube-dl --no-playlist 'https://www.youtube.com/watch?v=VQd1IOyhKS4&list=RDEMlHFFKeq-aYlBhg-LtJ-SHw&start_radio=1' or youtube-dl https://www.youtube.com/watch?v=VQd1IOyhKS4 both give exactly the same result. My question is why the Debian version so obsolte ans uneliable? best regards, -- Pierre Frenkiel
Re: Flushing all Buffers Before Exiting
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 yet gone to the operating system. Cheers -- t signature.asc Description: Digital signature
Re: youtube video downloader for chrome
On Thu 21 Mar 2019 at 15:38:41 (+0100), Pierre Frenkiel wrote: > On Wed, 20 Mar 2019, Celejar wrote: > > On Wed, 20 Mar 2019 10:34:42 +0100 (CET) Pierre Frenkiel > > wrote: > > > On Tue, 19 Mar 2019, riveravaldez wrote: > > > > > > > Maybe worth mentioning: youtube-dl, exceptionally useful and simple CLI > > > > tool. > > > > > >useful and simple... but it works only for urls with alphanumeric > > > characters > > >I tried with an url containing ? and &, and I got nothing > > >I tried also by escaping ? and & with \, and it was not better. > > >I'll send you an example later, if you are not convinced... > > > > You can also try putting the url(s) in a file, and feeding the file to > > youtube-dl via its -a option. > > > > Celejar > > > > At last, I fixed everything just by loadind the last version of youtube-dl > from the > yt-dl site > wget https://yt-dl.org/latest/youtube-dl -O /usr/local/bin/youtube-dl > > after that, I can do either > youtube-dl --no-playlist > 'https://www.youtube.com/watch?v=VQd1IOyhKS4&list=RDEMlHFFKeq-aYlBhg-LtJ-SHw&start_radio=1' > or >youtube-dl https://www.youtube.com/watch?v=VQd1IOyhKS4 both give > exactly the same result. > > My question is why the Debian version so obsolte ans uneliable? The latest version on the website is three days old. The version I installed from backports on Jan 28 was 11 days old. You have to understand that sites like youtube and the BBC can obsolete youtube-dl and get_iplayer overnight, and they do. Then some clever people come up with a fix and release a new version, and I heave a big sigh of relief and thanks. (Most BBC programmes expire after four weeks, and I'm usually two or three weeks behind, so a quick fix is vital.) Debian mainstream doesn't work to that timetable, so you should check out the backports, where those sorts of package appear. Fortunately, get_iplayer is a single Perl script so I just download it from its site and put it in ~/bin, as you can see from my examples. Cheers, David.
Re: Flushing all Buffers Before Exiting
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 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 yet gone to the > operating system. Thanks to both of you. I hadn't thought of that but that probably explains why nothing happened other than the command "sync" successfully ran. 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 output redirection but it beats nothing. A suggestion on a posting in stackoverflow was that one could open the file for appending, append your new output and then close it. I'll give that a try which should solve this one case. Apparently others have dealt with how to shake the most recent data out of buffers and commit it to disk and it is highly dependant on the operating system as to when the write actually goes to disk. Again many thanks. Martin McCormick
Re: Systemd files on a Raspberry Pi
the resistance is still strong ... Systemd-Free Debian "Devuan" Planning Their First Developer Gathering This Spring https://www.phoronix.com/scan.php?page=news_item&px=Devuan-Conference-2019 On Tue, Feb 12, 2019 at 2:15 PM Andrew McGlashan < andrew.mcglas...@affinityvision.com.au> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi, > > On 13/2/19 3:14 am, Jonathan Dowland wrote: > > On Sun, Feb 10, 2019 at 09:24:39AM +0100, to...@tuxteam.de wrote: > >> On Tue, Jun 23, 2015 at 01:47:20AM +1000, Andrew McGlashan > >> wrote: > > > > Did I miss 4 years of posts or did you (accidentally?) reply to a > > 4 year old message? > > No, there was a new message in relation to a recent video at Linux > Conf 2019. and the discussion sparked up again in relation to that. > > Cheers > A. > -BEGIN PGP SIGNATURE- > > iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXGMXIQAKCRCoFmvLt+/i > +w3nAP0XVSJU88QWAiNbgFNmfSLlJDmW5+Ov4q9RGuv66ZTgBwEA2iatxjSLsOev > eac0GfhP5ro8djVJ6ixxBrPTwbAREec= > =Lh8d > -END PGP SIGNATURE- > >
Re: Flushing all Buffers Before Exiting
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
devscripts 'bts' mail setup
I'm having trouble configuring bts via ~/.devscripts, though similar settings do work for Reportbug, and I'm looking for help solving this. I want bts to send mail via SMTP, so this is how the relevant lines of .devscripts looks right now. BTS_SMTP_HOST=posteo.de:587 BTS_SMTP_AUTH_USERNAME=jsc...@posteo.net The man page says * BTS_SMTP_AUTH_USERNAME, BTS_SMTP_AUTH_PASSWORD If these options are set, then it is the same as the --smtp-username and -- smtp-password options being used. * --smtp-username=USERNAME, --smtp-password=PASSWORD If a username is specified but not a password, bts will prompt for the password before sending the mail. But bts never prompts for a password, saying only "mailx: Null message body; hope that's ok." Even putting the password in .devscripts doesn't make it work, and the mails don't send. The last thing I tried was setting BTS_SMTP_HELO. "Note that some SMTP servers may reject the use of a HELO which either does not resolve or does not appear to belong to the host using it." My /etc/mailname says X200, the name I gave this computer which clearly doesn't resolve. Is that normal? I put my public IPv4 address in BTS_SMTP_HELO which didn't make a difference. Thanks, I look forward to figuring this out. P.S. please CC me, I'm not subscribed to the list signature.asc Description: This is a digitally signed message part.
Re: Flushing all Buffers Before Exiting
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 (C's FILE interface, i.e. fopen() and friends also) have this interface. An abnormal end (i.e. signal) don't give the application time to flush the buffers. You might want to catch the signals and flush, but depending on the signal that might be iffy (you sure you want to crawl on after having received a SIGSEGV?) and sometimes impossible (SIGKILL, e.g.). Cheers -- t signature.asc Description: Digital signature
Re: youtube video downloader for chrome
On 03/21/2019 08:41 AM, David Wright wrote: On Thu 21 Mar 2019 at 15:38:41 (+0100), Pierre Frenkiel wrote: On Wed, 20 Mar 2019, Celejar wrote: On Wed, 20 Mar 2019 10:34:42 +0100 (CET) Pierre Frenkiel wrote: On Tue, 19 Mar 2019, riveravaldez wrote: Maybe worth mentioning: youtube-dl, exceptionally useful and simple CLI tool. useful and simple... but it works only for urls with alphanumeric characters I tried with an url containing ? and &, and I got nothing I tried also by escaping ? and & with \, and it was not better. I'll send you an example later, if you are not convinced... You can also try putting the url(s) in a file, and feeding the file to youtube-dl via its -a option. Celejar At last, I fixed everything just by loadind the last version of youtube-dl from the yt-dl site wget https://yt-dl.org/latest/youtube-dl -O /usr/local/bin/youtube-dl after that, I can do either youtube-dl --no-playlist 'https://www.youtube.com/watch?v=VQd1IOyhKS4&list=RDEMlHFFKeq-aYlBhg-LtJ-SHw&start_radio=1' or youtube-dl https://www.youtube.com/watch?v=VQd1IOyhKS4 both give exactly the same result. My question is why the Debian version so obsolte ans uneliable? The latest version on the website is three days old. The version I installed from backports on Jan 28 was 11 days old. You have to understand that sites like youtube and the BBC can obsolete youtube-dl and get_iplayer overnight, and they do. Then some clever people come up with a fix and release a new version, and I heave a big sigh of relief and thanks. (Most BBC programmes expire after four weeks, and I'm usually two or three weeks behind, so a quick fix is vital.) Debian mainstream doesn't work to that timetable, so you should check out the backports, where those sorts of package appear. Fortunately, get_iplayer is a single Perl script so I just download it from its site and put it in ~/bin, as you can see from my examples. Cheers, David. Hi, I think you would be better off with: youtube-dl --update also: youtube-dl --help will show all the options. Best regards, Fred
Re: Flushing all Buffers Before Exiting
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 the process's I/O buffers which haven't yet gone to the > operating system. I'm reading a pty app won't buffer (script, screen, etc.). And then there's a program called 'unbuffer'? > Cheers -- “Let us again pretend that life is a solid substance, shaped like a globe, which we turn about in our fingers. Let us pretend that we can make out a plain and logical story, so that when one matter is despatched--love for instance-- we go on, in an orderly manner, to the next.” - Virginia Woolf, The Waves
Re: Flushing all Buffers Before Exiting
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 explicitly: standard input (for reading conventional input), standard output (for writing conventional output), and standard error (for writing diagnostic output). These streams are abbreviated stdin,stdout and stderr. When opened, the standard error stream is not fully buffered; the standard input and output streams are fully buffered if and only if the streams do not refer to an interactive device. Output streams that refer to terminal devices are always line buffered by default; pending output to such streams is written automatically whenever an input stream that refers to a terminal device is read. In cases where a large amount of computation is done after printing part of a line on an output terminal, it is necessary to fflush(3) the stan‐ dard output before going off and computing so that the output will appear. > And then there's a program called 'unbuffer'? It's a hack, built around Expect. It basically tries to fool the application into thinking that standard output is a terminal, so the application will operate in line-buffering mode. I've been told that it works quite often, but you can't ever guarantee success with it.
Re: Flushing all Buffers Before Exiting
Try stdbuf.
Re: Flushing all Buffers Before Exiting
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 output redirection but it beats nothing. > A suggestion on a posting in stackoverflow was that one > could open the file for appending, append your new output and > then close it. 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. If there's not too much output compared with the computation necessary to generate it, just setting line-buffering on the output stream can be sufficient. I've read that when the program is already running, some languages (like Python, so probably Perl too) offer a debugger that can allow you to flush the buffers from "within", but I've not tried it. Cheers, David.
Re: Flushing all Buffers Before Exiting
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 > catch so you run it as someproc >catchfile. The process has an > end point so anything it produced gets saved in catchfile and all > is well. > > Now imagine you run someproc and it either has no end > condition or you haven't reached it yet so you kill it with > Control-C. Some unixen like FreeBSD seem to flush all the > buffers and you still get your output but Debian appears to not > flush the buffers and you get nothing or maybe a partial capture > with the most recent data lost. > > Is there a way to make sure we got everything that was > produced? https://unix.stackexchange.com/questions/25372/turn-off-buffering-in-pipe/ Regards, Lee
Re: youtube video downloader for chrome
On Thu, 21 Mar 2019, Fred wrote: I think you would be better off with: youtube-dl --update ==> youtube-dl --update It looks like you installed youtube-dl with a package manager, pip, setup.py or a tarball. Please use that to update.
Re: youtube video downloader for chrome
On Thu 21 Mar 2019 at 10:17:11 (-0700), Fred wrote: > On 03/21/2019 08:41 AM, David Wright wrote: > > On Thu 21 Mar 2019 at 15:38:41 (+0100), Pierre Frenkiel wrote: > > > On Wed, 20 Mar 2019, Celejar wrote: > > > > On Wed, 20 Mar 2019 10:34:42 +0100 (CET) Pierre Frenkiel > > > > wrote: > > > > > On Tue, 19 Mar 2019, riveravaldez wrote: > > > > > > > > > > > Maybe worth mentioning: youtube-dl, exceptionally useful and simple > > > > > > CLI tool. > > > > > useful and simple... but it works only for urls with alphanumeric > > > > > characters > > > > > I tried with an url containing ? and &, and I got nothing > > > > > I tried also by escaping ? and & with \, and it was not better. > > > > > I'll send you an example later, if you are not convinced... > > > > You can also try putting the url(s) in a file, and feeding the file to > > > > youtube-dl via its -a option. > > > > > > > > Celejar > > > > > > >At last, I fixed everything just by loadind the last version of > > > youtube-dl from the > > >yt-dl site > > >wget https://yt-dl.org/latest/youtube-dl -O > > > /usr/local/bin/youtube-dl > > > > > > after that, I can do either > > > youtube-dl --no-playlist > > > 'https://www.youtube.com/watch?v=VQd1IOyhKS4&list=RDEMlHFFKeq-aYlBhg-LtJ-SHw&start_radio=1' > > > or > > > youtube-dl https://www.youtube.com/watch?v=VQd1IOyhKS4 both give > > > exactly the same result. > > > > > > My question is why the Debian version so obsolte ans uneliable? > > The latest version on the website is three days old. The version I > > installed from backports on Jan 28 was 11 days old. > > > > You have to understand that sites like youtube and the BBC can > > obsolete youtube-dl and get_iplayer overnight, and they do. > > Then some clever people come up with a fix and release a new > > version, and I heave a big sigh of relief and thanks. (Most > > BBC programmes expire after four weeks, and I'm usually two or > > three weeks behind, so a quick fix is vital.) > > > > Debian mainstream doesn't work to that timetable, so you should > > check out the backports, where those sorts of package appear. > > Fortunately, get_iplayer is a single Perl script so I just > > download it from its site and put it in ~/bin, as you can see > > from my examples. > > > Hi, > I think you would be better off with: > > youtube-dl --update a) Why? b) How? $ youtube-dl --update Usage: youtube-dl [OPTIONS] URL [URL...] youtube-dl: error: youtube-dl's self-update mechanism is disabled on Debian. Please update youtube-dl using apt(8). See https://packages.debian.org/sid/youtube-dl for the latest packaged version. $ > also: > > youtube-dl --help > > will show all the options. … and, of course, --update is missing. But which of these options did you mean to draw my attention to? Cheers, David.
devscripts 'bts' mail setup
I'm having trouble configuring bts via ~/.devscripts, though similar settings do work for Reportbug, and I'm looking for help solving this. I want bts to send mail via SMTP, so this is how the relevant lines of .devscripts looks right now. BTS_SMTP_HOST=posteo.de:587 BTS_SMTP_AUTH_USERNAME=jsc...@posteo.net The man page says * BTS_SMTP_AUTH_USERNAME, BTS_SMTP_AUTH_PASSWORD If these options are set, then it is the same as the --smtp-username and -- smtp-password options being used. * --smtp-username=USERNAME, --smtp-password=PASSWORD If a username is specified but not a password, bts will prompt for the password before sending the mail. But bts never prompts for a password, saying only "mailx: Null message body; hope that's ok." Even putting the password in .devscripts doesn't make it work, and the mails don't send. The last thing I tried was setting BTS_SMTP_HELO. "Note that some SMTP servers may reject the use of a HELO which either does not resolve or does not appear to belong to the host using it." My /etc/mailname says X200, the name I gave this computer which clearly doesn't resolve. Is that normal? I put my public IPv4 address in BTS_SMTP_HELO which didn't make a difference. Thanks, I look forward to figuring this out. P.S. please CC me, I'm not subscribed to the list signature.asc Description: This is a digitally signed message part.
Re: youtube video downloader for chrome
On 03/21/2019 11:57 AM, David Wright wrote: On Thu 21 Mar 2019 at 10:17:11 (-0700), Fred wrote: On 03/21/2019 08:41 AM, David Wright wrote: On Thu 21 Mar 2019 at 15:38:41 (+0100), Pierre Frenkiel wrote: On Wed, 20 Mar 2019, Celejar wrote: On Wed, 20 Mar 2019 10:34:42 +0100 (CET) Pierre Frenkiel wrote: On Tue, 19 Mar 2019, riveravaldez wrote: Maybe worth mentioning: youtube-dl, exceptionally useful and simple CLI tool. useful and simple... but it works only for urls with alphanumeric characters I tried with an url containing ? and &, and I got nothing I tried also by escaping ? and & with \, and it was not better. I'll send you an example later, if you are not convinced... You can also try putting the url(s) in a file, and feeding the file to youtube-dl via its -a option. Celejar At last, I fixed everything just by loadind the last version of youtube-dl from the yt-dl site wget https://yt-dl.org/latest/youtube-dl -O /usr/local/bin/youtube-dl after that, I can do either youtube-dl --no-playlist 'https://www.youtube.com/watch?v=VQd1IOyhKS4&list=RDEMlHFFKeq-aYlBhg-LtJ-SHw&start_radio=1' or youtube-dl https://www.youtube.com/watch?v=VQd1IOyhKS4 both give exactly the same result. My question is why the Debian version so obsolte ans uneliable? The latest version on the website is three days old. The version I installed from backports on Jan 28 was 11 days old. You have to understand that sites like youtube and the BBC can obsolete youtube-dl and get_iplayer overnight, and they do. Then some clever people come up with a fix and release a new version, and I heave a big sigh of relief and thanks. (Most BBC programmes expire after four weeks, and I'm usually two or three weeks behind, so a quick fix is vital.) Debian mainstream doesn't work to that timetable, so you should check out the backports, where those sorts of package appear. Fortunately, get_iplayer is a single Perl script so I just download it from its site and put it in ~/bin, as you can see from my examples. Hi, I think you would be better off with: youtube-dl --update a) Why? b) How? $ youtube-dl --update Usage: youtube-dl [OPTIONS] URL [URL...] youtube-dl: error: youtube-dl's self-update mechanism is disabled on Debian. Please update youtube-dl using apt(8). See https://packages.debian.org/sid/youtube-dl for the latest packaged version. $ also: youtube-dl --help will show all the options. … and, of course, --update is missing. But which of these options did you mean to draw my attention to? Cheers, David. HI, Well, it would appear that I did not use the downlevel version from the Debian repository. If you install from the youtube-dl website and then use the --update command you can be sure of having the latest version. If one uses the --help command the update option will be shown. I didn't know that was missing in the Debian version. One option that might have helped with a problem that was posted in about the last week is the --restrict-filenames option which may prevent the need to quote the URL. Best regards, Fred
Re: Flushing all Buffers Before Exiting
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. > > If there's not too much output compared with the computation necessary > to generate it, just setting line-buffering on the output stream > can be sufficient. > > I've read that when the program is already running, some languages > (like Python, so probably Perl too) offer a debugger that can > allow you to flush the buffers from "within", but I've not tried > it. > > Cheers, > David. 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. 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. When nothing is happening, there are 3 possible strings that indicate nothing is happening right now. When something changes, the strings stop matching 3 comparison strings i put in which match each of the 3 "nothing is happening right now" strings and the different strings get printed to the screen and to the disk. In reality, these strings don't exactly mean that nothing is happening but that the same non events are happening. When things change and there is output of interest, that output also spews in at 20 or 30 lines per second so I need to do as little as possible to handle that so the system doesn't get swamped. The signal handler is most likely far more efficient a method to capture the data of interest as it will essentially not have to make any decisions until time to shut down the program and look at the data. Even with the open, append and close routine, the strings it is capturing appear to be good but it could be capturing for minutes on end at times and it needs to just be able to run like the wind and store lines as quickly as it can. Thank you. Martin McCormick amateur radio WB5AGZ
Re: Flushing all Buffers Before Exiting
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 selected handle to be flushed after every print. $| = 1; when needed - but not sure if applies to your case
