Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am using the following to redirect output from my script to both terminal and log file while appending date to every line that goes to the log file:

NPIPE=/tmp/$$_$RANDOM.tmp  
mknod $NPIPE p  
tee <$NPIPE /dev/tty | ( while read line; do echo "$(date): ${line}"; done ) >> $LOG_FILE &
exec 1>&-  
exec 1>$NPIPE  
exec 2>&-  
exec 2>$NPIPE  

Now in this same script i upload the log file to a server. The log file on the local device (embedded) looks complete, but the log file at the server is always partial.

I get the feeling that the pipe still is emptied in blocks and still holds content when i send the log, maybe i am missing some kind of a flush command but i can't find anything like that.

Any advice?

share|improve this question
    
Don't know if this is sensible or good practice, but have you tried to use sync before uploading to your server? –  mpy May 9 '13 at 15:38
    
How are you sending the file to the server? –  psusi May 9 '13 at 23:45
    
First, thank you for the replays. mpy, Altough definitly not a good practice (as you mentioned yourself) but that was one of the first things i tried. It did no good. –  user223217 May 12 '13 at 7:45
    
psusi - I am using TFTP or FTP (depends on configuration file), do you think the transport method has any relevance in this case? –  user223217 May 12 '13 at 7:47

1 Answer 1

up vote 2 down vote accepted

I believe that you’ll need to close the pipe:

exec 1>&-
exec 2>&-

Then, after you upload the log file, you’ll need to start a new tee process:

tee <$NPIPE /dev/tty | ( while read line; do echo "$(date): ${line}"; done ) >> $LOG_FILE &
exec 1>$NPIPE
exec 2>$NPIPE
share|improve this answer
    
Thank you @Scott. I was about to tell you that i already gave that i try - as i seem to remember i did, after reading that closing all the writes to the pipe will result in the readers getting EOF or something of that sort. Anyhow gave it a try again and it does the job. Maybe i mixed it up with too many changes last time i did it. Thank you! –  user223217 May 12 '13 at 8:32
    
Seems that i don't even have enough reputation to Vote up your answer :( –  user223217 May 12 '13 at 8:40
    
Follow up - Although i am keeping this as the accepted answer i got to a different conclusion. Seems that the reason this worked for me when i tried this now is that i placed a sleep command in the script after i closed the writers to the pipe just to have a chance to see that the tee process is killed. But it seems that leaving the sleep there (sleep 1) and removing the redirection solves this just the same, while doing the opposite (closing the pipe, no sleep after) does not! I am somewhat confused but consider this a workaround. Keeping both in my script for now. –  user223217 May 12 '13 at 9:55
    
It makes sense that a sleep would help; since the pipeline that’s writing to the log file is asynchronous (running in the background), you want to give it a chance to detect the EOF and react to it (flush buffers and exit). I’m a little surprised that the sleep alone is enough, but I’m glad you found something simple that works for you. –  Scott May 12 '13 at 19:31
    
Thank you for the explanation @Scott. I agree that the fact that sleep alone also got the job done is surprising, but as former FW developer i find relying on sleep, or any other means of empirical wait, a recipe for a bug. So as long as i don't have any better option i am doing both, i.e. close the writers, sleep, then starting a new tee process (to catch any new input to log, knowing well that these wont be sent to the server) and only then send the log. –  user223217 May 13 '13 at 8:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.