in reply to executing "at" from perl

the first 2 are only passing the output of rm to at, what you really want to do is pass the command string so the 3rd should work if the missing quote is just a typo in the post.

Replies are listed 'Best First'.
Re^2: executing "at" from perl
by rastoboy (Monk) on Nov 17, 2009 at 05:53 UTC
    Thanks, all.

    My option number 3 does not work:

    system "echo rm $session_file | at now + 1 minute";
    The session file is created, the job shows up in atq, but it fails silently. It's the 'silently' part that is most maddening. Hm maybe I should direct errors somewhere..but the apache user isn't in /etc/at.deny, and indeed I forced a shell on the user and it worked okay--I thought cdarke might be on to something :-)

    gmargo: I hear you loud and clear. I think I'm going to check out moritz suggestion and check out CGI::Session. However, in this case I'm putting in the 'at' right after creating the session file, so at least it isn't from user input. So I *presume* it's okay, but yeah, I'll check out CGI::Session :-). I hear ya loud and clear, and appreciate the input.

    Really now it just bugs me that I don't know why it fails.

      Hm actually it doesn't look like CGI::Session automatically cleans up old session files? I was wondering how that would work.

      This script is going to run on a server I don't admin, so I'm concerned about leaving these things lying around on his hard drive.

        All right just for the record I've isolated it to an OS level issue. I even became the apache user and executed the spool file from /var/spool/at and it worked! But in root's mail I'm getting (consistently when the job is run):
        This account is currently not available.
        Now I may not understand exactly what that means, but it seems reasonable to believe that that's the barrier I'm running up against. I do appreciate y'alls input, and I learned a few things so your time was not wasted :-)