DBI and PP not behaving...

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

Hi there fellow monks, I've been experiencing a problem for some time now and have decided to seek some external help. I'm writing a perl tool here at my job, using among other modules, DBD-sqlite. I intended to turn it into an EXE as soon as development was stable enough to enter production phase, so my collegues wouldn't need to install Perl on their PCs. Unfortunatly, I'm hitting a wall with my EXEs not returning to DOS prompt once finished, as the PP/PAR duo doesn't seem able to clean the temporary files it created. This behavior is only happening if I 'use DBI'. It also doesn't happen when I don't use pp.exe's -C (autoclean) option. But if I don't use that option, then the generated exe will not clean files in %TEMP% directory. Here's an example that you probably can reproduce if, like me, you're using : - activestate perl 5-8-6 multi-thread - pp 0.12 / PAR 0.87 - DBI 1.48

use DBI ;

print "quitting\n" ;
[download]

'compiling' it with the following command :

pp -C -o tstpp.exe tstpp.pl
[download]

It generates a .EXE that only terminates with Ctrl-C. (once again, not using '-C' option gives a good EXE but pollutes windows temporary directory, and I can't clean it from inside the script). Has anyone encountered and managed to solve that problem ? Or will I have to forget about autoclean option, run my .EXE from a .BAT which will clean the directory after perl returns ? Thanks a lot in advance for your answers, and sorry if my english's not that good, it's not my mother tongue.

Comment on DBI and PP not behaving... Select or Download Code

Replies are listed 'Best First'.
Re: DBI and PP not behaving... by wazoox (Prior) on May 04, 2005 at 12:12 UTC
IIRC, you can't unlink a file that isn't closed first when running on windows. Can it be the problem?	[reply]
Re: DBI and PP not behaving... by ysth (Canon) on May 04, 2005 at 18:35 UTC
That node is now up to 4 replies, and I see (with the option on) 4 replies on Seekers of Perl Wisdom but 6 replies on The Monestary Gates. Curious. Update: the Gates use the cached repliesinfo information, while SoPW (to my surprise) actually counts the notes that exist. repliesinfo is set in note maintenance create and note maintenance delete, in code that is subject to race conditions, but I don't see how it would leave the counts too high offhand. I meant to post this under Discrepancies in the number of replies, but don't want it moved now because (cough, cough) moving nodes doesn't update the repliesinfo record.	[reply]
Re: DBI and PP not behaving... by Anonymous Monk on May 04, 2005 at 11:17 UTC
Might this be an issue with windows security? Does your NT security context grant you sufficient rights to remove files from c:\windows\temp?	[reply]
Re^2: DBI and PP not behaving... by Baramin (Acolyte) on May 04, 2005 at 11:56 UTC
It definitly isn't a security issue as I'm running as workstation admin, and can delete files myself, either manually or from a .BAT if I run the .EXE from a .BAT that takes care of cleaning the directory. I've already done several .EXEs from perl scripts on that computer using various modules like Win32::GUI, Encode::* etc and the problem is really only with DBI.	[reply]
Re: DBI and PP not behaving... by halley (Prior) on May 04, 2005 at 15:03 UTC
Due to some systems like VMS, the "sanctioned" idiom for deleting files is like: `1 while unlink($filename);` [download] Or variantly, `unlink($filename) while -f $filename;` [download] However, that kind of loop appears a bit dangerous if you're not sure that unlink() will always eventually return FALSE or remove all versions of that file. It SOUNDS like that's the kind of bug the -C cleanup code is introducing here. If the file is still open, then going into one of those loops would have the behavior you're experiencing. I haven't dug into pp's code, though, to be sure of it. -- `[ e d @ h a l l e y . c c ]`	[reply] [d/l] [select]