At 2:51 pm +0200 20.10.97, Matthias Ulrich Neeracher wrote: [ ... first case snipped ... ] >I did some tests with this, and it seems to me that the fact that this >construct worked for you was purely coincidental. I will run this code by >a few >Perl deities tonight and will let them decide whether it was reasonable to >expect a value being returned in the first place. I think it probably wasn't. Reading the Book, there's nothing to suggest that it should have worked (but nothing to suggest that it shouldn't). Having found a simple workaround, I'm less concerned about that one (and feeling slightly guilty at having been found out using a questionable practice; I shall do penance at the altar of the Perl Gods, or carry a bucket of oats to the Camel or something). >> 2. Something has happened to I/O redirection. I use constructs of the >> form: > >This is an interesting and serious bug. Between 513 and 514, I switched I/O >libraries, and perl always had a tricky balancing act between I/O streams, >file >descriptors, and Perl streams; I wouldn't be surprised if that went wrong in >some places ... Can you distill this bug into a short test case? I can't. When I try to run test cases, it stubbornly refuses to disobey. My test cases are growing more and more complex, but it still works fine. The actual script that tripped me up, however, continues to fail. All I can say is that my code *looks* legal, and I never had this particular problem before 5.1.4r4. I can add another data point, though. The problem seems to affect the first and only the first file I try to write in each iteration. The script that's giving me problems is a macro-processor I use to generate HTML document files from source files containing pseudo-markup. I invoke it in one of two ways - either I drop a bunch of files on a droplet that calls the script, or I run an AppleScript that passes a single file to the script for processing. When I process a batch of files, all the files except the first one get written correctly, which is created but left empty. If I drop a single file on the droplet, the output file is empty. When I invoke the script via an AppleScript, the output file is always empty. Here's a simplified form of the function that does the redirection. It's simplified a *lot*, but I'm pretty sure it's functionally equivalent to the real one. sub process_file { my($self,$pathname) = @_; my($target) = $self->some_mystic_function($pathname); open(SAVEOUT,">&STDOUT"); open(STDOUT,">$target") || die("can't open '$target' for output: $!"); $self->expand_file($pathname); close(STDOUT); open(STDOUT,">&SAVEOUT"); } As you can tell, it's defined within a package (hmm, is STDOUT global?) as part of an object definition. The 'print' functions that should write on the file are called in the same package. Some more points: 1. The bug isn't dependent on the input file in any way, but only on the order of processing. i.e. first file in a batch, you lose, any other file, OK. Some of the input files are near-identical copies of each other, so it seems not to be the content of the input file that makes a difference (which would point to a bug in my code). 2. In the problem cases, the output file is created, but nothing is written to it. 3. The method 'expand_file' uses 'print' to write to STDOUT. 4. The missing output is not written anywhere else that I can see. 5. Adding a 'print "Foo\n";' before the redirection doesn't change anything; "Foo" appears on the console, but the file is still empty. 6. All the parts of the code that *should* produce output are executing normally. >>And in the meantime, is MacPerl 5.1.3r2 still available anywhere? > ... if necessary, I'll send you a non-installer version of 513. Don't worry; I've just remembered that I have a copy at home which I can use. Thanks, as ever, A -- angus@pobox.com http://pobox.com/~angus/ "My loathings are simple: stupidity, [Vladimir Nabokov] oppression, crime, cruelty, soft music." ***** Want to unsubscribe from this list? ***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch