2-strange side effect with FH

Discipulus has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: 2-strange side effect with FH by jmcnamara (Monsignor) on Oct 22, 2002 at 12:38 UTC
In order to write to a file and then read from it you generally have to rewind the file using seek: `#!/usr/local/bin/perl -w use strict; open TEMP, "+>file.txt" or die "Error message here: $!\n"; # Write to the file print TEMP "aba uba\niba seba\njak yuk\n"; # Rewind the file for reading seek(TEMP, 0, 0); while (<TEMP>) { print; } close TEMP;` [download] The fact that some of your code is printed out must be related to not using `seek()` on Windows. I don't see this behaviour on Linux. -- John.	[reply] [d/l]
Re: (nrd) 2-strange side effect with FH by newrisedesigns (Curate) on Oct 22, 2002 at 12:51 UTC
You should really see this node, because it answers a question quite similiar to the one you just asked. Put a close in, and you'll have better results. `open (TEMPO, "+>c:\\winnt\\temp\\hash.tmp"); print (TEMPO "aba uba\niba seba\njak yuk\n"); close (TEMPO); open (TEMPO, "<c:\\winnt\\temp\\hash.tmp"); while (<TEMPO>) { print; } close (TEMPO);` [download] Use strict; Always. Never deviate from the path of righteousness that is strict. John J Reiser newrisedesigns.com	[reply] [d/l]
Re: 2-strange side effect with FH by BrowserUk (Patriarch) on Oct 22, 2002 at 13:06 UTC
As others have pointed out, there are any number of cures for the problem, but if it's any consolation, I can reproduce your findings under NT/AS 5.6.1, so it looks very much like a bug in AS as jmcnamara couldn't under Linux. It might be worth reporting. Likely or not they would say that if you fix your code, you won't have the problem, but it might get investigated and fixed for the next release. Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!	[reply] [d/l]
Re: 2-strange side effect with FH by nothingmuch (Priest) on Oct 22, 2002 at 11:40 UTC
Could you give us examples of what is happenning? I think that somehow STDIO is confused with eof states, since your are reading after you've written at EOF. Why the code? Beat me with a broom and I still won't know. Try `seek TEMPO, 0, 0;` instead of the open, read it to it's end and then immediately reading again - if it still prints out your code then maybe it is something with EOFs. If it messes up on the first read then i dunno... You should also try this: `use Fcntl qw(O_RDWR O_CREAT); sysopen TEMPO,"c:\\winnt\\temp\\hash.tmp",O_RDWR\|O_CREAT or die "$!"; syswrite TEMPO,"aba uba\nniba seba\njak yuk\n"; while (sysread TEMPO, $_, 4096){ print; }` [download] And see if it gives you similar results, and then add `sysseek(TEMPO,0,0);` between syswrite and while, and see what it does. These will not solve the problem, but may help identify it. Perhaps you should ask the people at activestate if no one here can find a solution. Good luck! -nuffin zz zZ Z Z #!perl	[reply] [d/l] [select]
Re: Re: 2-strange side effect with FH by blm (Hermit) on Oct 22, 2002 at 11:52 UTC
Here is what happens for me when I run that script without editing `C:\>"C:\Documents and Settings\blm\Desktop\test.pl" ##open (TEMPO, "<c:\\winnt\\temp\\hash.tmp"); while (<TEMPO>) { print; } <then a lot of blank lines with some "funny ascii characters" interspe +rsed>` [download] For more information about what the above post indicates might be happening read perldoc seek. It says: On some systems you have to do a seek whenever you switch between reading and writing. Amongst other things, this may have the effect of calling stdio's clearerr(3). A WHENCE of 1 (SEEK_CUR) is useful for not moving the file position: `seek(TEST,0,1);` [download] Updated: Include the output of the posted sample so everyone can see. --blm--	[reply] [d/l] [select]
Re: 2-strange side effect with FH by thor (Priest) on Oct 22, 2002 at 13:00 UTC
I have to wonder if you aren't running in to a buffering problem in that perl may not have written EOF yet, so the OS doesn't know where the file ends. You end up reading garbage until you happen upon an EOF that is residing on the hard drive. I think that you should try explicitly `close` your file. At worst, you will see the exact same behaviour. Also of note: if it is a buffering problem, you could have larger issues in that actual data may not get to the file. thor	[reply] [d/l]