Every time I use the "at" command, I get this message:
warning: commands will be executed using /bin/sh
What is it trying to warn me about? More importantly, how do I turn the warning off?
The at command is a Linux command-line utility used to schedule a job for later execution. The utility reads commands from standard input and groups them into an at job, which executes only once. The alternative for at is a cron job. However, while at jobs execute only once, cron jobs are recurring events.
The sh command invokes the default shell and uses its syntax and flags. The shell linked to the /usr/bin/sh path is the default shell. The standard configuration of the operating system links the /usr/bin/sh path to the Korn shell.
Adding #!/bin/bash as the first line of your script, tells the OS to invoke the specified shell to execute the commands that follow in the script. #! is often referred to as a "hash-bang", "she-bang" or "sha-bang".
It serves as a good warning to those of us that don't use bash as our shell, because we we'll forget that a feature that's in our day-to-day shell isn't going to be available when this code is run at the appointed time.
i.e.
username@hostname$ at 23:00
warning: commands will be executed using /bin/sh
at> rm **/*.pyc
at> <EOT>
job 1 at 2008-10-08 23:00
The use of '**' there is perfectly valid zsh, but not /sbin/sh! It's easy to make these mistakes if you're used to using a different shell, and it's your responsibility to remember to do the right thing.
Does the warning have any harmful effect aside from being annoying? The man page doesn't mention any way of turning it off, so I don't think you can stop it from being emitted without rebuilding your at from source.
Now, if you want to just not see it, you can use at [time] 2>/dev/null
to send it off to oblivion, but, unfortunately, the at>
prompts are printed to STDERR for some reason (a bug, IMO - they really should go to STDOUT), so they're also hidden by this.
It may be possible to work up some shell plumbing which will eliminate the warning without also eating the prompts, but
at [time] 2>&1 | grep -v warning
) doesn't work andat
to handle it.So, unless it causes actual problems, I'd say you're probably best off just ignoring the warning like the rest of us.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With