There is one way, although there are some dependencies attached to the at or batch commands:
 

• This information was found in the Solaris (Unix) man pages. There may be Linux equivalents.
• There are conditions attached to the existence and contents two files, /usr/lib/cron/at.allow and /usr/lib/cron/at.deny.
  Users are permitted to use at and batch (see below) if their name appears in the file /usr/lib/cron/at.allow. If that file does not exist, the file /usr/lib/cron/at.deny is checked to determine if the user should be denied access to at. If neither file exists, only a user with the solaris.jobs.user authorization is allowed to submit a job. If only at.deny exists and is empty, global usage is permit- ted. The at.allow and at.deny files consist of one user name per line.

  One example they give is:
 

Example 3: Self-rescheduling a job
To have a job reschedule itself, at can be invoked from within the at-job. For example, this "daily-processing" script named my.daily will run every day (although crontab is a more appropriate vehicle for such work):

# my.daily runs every day
at now tomorrow < my.daily
daily-processing

Of course, you could talk to the sys admin and request the priviledge of using crontab, at or batch.

If the code and the comments disagree, then both are probably wrong. -- Norm Schryer