Re: Reading a file as it fills up by another program
Re: Reading a file as it fills up by another program
- Subject: Re: Reading a file as it fills up by another program
- From: Harald E Brandt <email@hidden>
- Date: Sun, 14 Dec 2003 23:18:36 +0100
+--> Christopher Nebel wrote 03-12-14:
Redirecting through stderr might work, though; I expect the phrase
"1>&2" would be involved somewhere.
+-
I have already tried all kinds of variations building upon '1>&2', in
vain - just wouldn't work!? I did both input and output
redirections/duplications of these file descriptors, of all kinds,
but no matter what I did, I could never redirect a stdout stream into
a stderr so that the later redirection to a file got the short
buffering of stderr!? It beats me...
However, I found an alternate method, inspired by your suggestion to
have Perl print to stderr: It is possible to make the whole thing
work just fine by modifying the Perl script I showed in an earlier
post, by simply telling it to print to stderr; and after the perl
script, redirect it as usual to a file! Voila! I don't know if this
is a "safe" method that is quaranteed to work in all cases, but it is
the method I have currently chosen as my primary one; it's really
short and fairly elegant:
set perlScript to "
$/ = qq(\\r);
while ( <> ) {tr/\\n/\\r/; print (STDERR $_)}"
set curlString to curlString & " 2>&1 | perl -e " &
quoted form of perlScript & " > " & tempfile4progress & " 2>&1 &"
If anyone knows of possible shortcomings with such a method, please email me.
+--
You'll probably still need to open and close the file on the reading
side, though.
+-
Yes, I still do that. Nice to hear that you didn't seem to shudder
too much at that solution...:-) It actually seems to work just very
well! I was first afraid that it would eat just too much cpu having a
tight loop doing such a thing with a file that someone is writing to,
but I have not noticed any problems or glitches - my machine, though,
is pretty fast (I think), 1.25 GHz G4.
+--
I've never heard of unbuffered output being considered dangerous
before. Slow, maybe, but not dangerous.
+-
Good to hear! I might have misunderstood what I was told by the
phone. I might consider such a solution at some later stage.
Best Regards, and REALLY VERY much thanks for your responses in this
(I think) very difficult topic!! That's what's making this list soo
useful!
--heb
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.