in reply to File::Temp randomness when forking

As a general rule, modules should not be automatically employed just because they are there. (Update: In this case systems are usually just too individual - they have different process behaviour, disk space issues, support requirements etc.) If a task is simple enough, it is usually less work to do it yourself. In every system I ever worked on, unique temporary filenames were always generated using site-written rather than CPAN modules. In the current case we are satisfied to construct unique temporary filenames from a functional identifier plus the date and time plus the pid ($$ in perl) plus a file type with a dot separator between these elements, e.g.

NamedProcess.20051129.110401.1234.ext

Millions of systems the world over have used this type of method (first mainly in C and now also in Perl) for decades and it can safely be called a de facto standard to do so. By comparison, using a CPAN module makes your system less supportable and maintainable. Note also that most systems will need their own date and time formatting to match the above formats anyway and this reduces the unique tmpfile subroutine to a trivial one-liner:

    return join( '.', shift(), ProjectDate(), ProjectTime(), $$, shift
+() );

[download]

-M

Free your mind

Replies are listed 'Best First'.
Re^2: File::Temp randomness when forking
by tirwhan (Abbot) on Nov 29, 2005 at 10:23 UTC

    Your method will fail to generate a unique name if you are creating more than one file per process per second (which can happen easy enough), or even if you're on a system that does not handle PIDs sanely. File::Temp exists exactly because it is very easy to fall into this kind of trap and surprisingly hard to avoid all traps that come with temporary file generation. "Millions of systems the world over" do this badly and sometimes fail because their author did not consider all corner cases (especially since such errors tend to show up only on loaded production systems and not during testing). Using File::Temp for temporary files is definitely a best practice in my book and there would have to be very specific reasons for recommending against it.


    Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan
[reply]
      File::Temp exists exactly because it is ... surprisingly hard to avoid all traps that come with temporary file generation.

      Thanks, this was my thinking precisely. I have some code I use to generate unique IDs using $$ and various other vars, which would have worked fine, but I figured it was about time I learn File::Temp. Also, I'm lazy ;->

[reply]
    A reply falls below the community's threshold of quality. You may see it by logging in.
Re^2: File::Temp randomness when forking
by thor (Priest) on Nov 29, 2005 at 12:56 UTC
    You're probably right. Re-rolling a solution is probably a good idea. Especially since the module is a core module...that probably means it doesn't work that well. By your reasoning, we should eschew any module that we didn't write ourselves. Best of luck in that endeavor.

    thor

    The only easy day was yesterday </tt>

[reply]
    A reply falls below the community's threshold of quality. You may see it by logging in.
Re^2: File::Temp randomness when forking
by ryantate (Friar) on Nov 29, 2005 at 17:59 UTC
    If a task is simple enough, it is usually less work to do it yourself.

    Sincere thanks for the perspective, but my milage varies here. I likely have less experience than you, so my default is almost always to reach for the nearest CPAN solution. It saves me huge amounts of time, and when it doesn't, I am sometimes able to send a bugfix or documentation patch upstream to improve the module.

    In the vast majority of cases, using CPAN is a win, at least for me.

[reply]
    A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Seekers of Perl Wisdom