The "at" command failing every time


#1

Something seems to be broken in the /bin/sh, but I can only notice it from inside the “at” command. The at itself works as expected:

s0099:~/workspace $ at now + 1 minute
warning: commands will be executed using /bin/sh
at> echo "123"
at> <EOT>
job 5 at Wed Apr 12 17:34:00 2017

The job is successfully added to the atq list. But after 1 minute…

s0099:~/workspace $ mail
Heirloom mailx version 12.5 6/20/10.  Type ? for help.
"/var/mail/ubuntu": 1 message 1 new
>N  1 ubuntu@dfc2eabdf23 Wed Apr 12 17:34   22/708   Output from your job        5
? 1
Message  1:
From ubuntu@dfc2eabdf236 Wed Apr 12 17:34:01 2017
Return-path: <ubuntu@dfc2eabdf236>
Envelope-to: ubuntu@dfc2eabdf236
Delivery-date: Wed, 12 Apr 2017 17:34:01 +0000
Subject: Output from your job        5
To: ubuntu@dfc2eabdf236
From: ubuntu@dfc2eabdf236
Date: Wed, 12 Apr 2017 17:34:01 +0000
Status: R

sh: 74: BASH_FUNC__gnomeopen%%=() {  if [ -e "$@" ]; then
 c9 "$@";
 return;
 fi;
 command xdg-open "$@"
}: not found
sh: 74: export: BASH_FUNC__gnomeopen%%: bad variable name

I don’t know what line 74 it is referring to, where if is written or why is it an error. The at command does not allow executing things in any other shell, and command like "bash <<< “echo 123"” produce the exact same error. The /bin/sh by itself works perfectly fine.

EDIT: Though it doesn’t help with what I am specifically doing, I have tried scheduling a file, with the -f option. And I still get the exact same error, even if the file is explicitly marked with #!/bin/bash.


#2

how does that normally work? Seems like there is an error related to xdg-open, which is not installed on cloud9 workspaces, and it can’t work on servers where DISPLAY is not defined


#3

As I understand it, please correct me if I’m wrong, the cloud9 alternative to xdg-open is the “c9” command, which sends a signal to the active client telling it to open a file in the editor. But what does this have to do with command scheduling? Why should a simple “do this in 30 minutes” command ever need to consult the UI?

What’s worse, I can’t seem to find any real alternatives to “at”. This command would be really handy for stateful web applications, and that’s what cloud9 is supposed to be all about, right?

Also, I don’t know if this is relevant, but that exact snippet of code called BASH_FUNC__gnomeopen has already confused the hell out of a user by the name of Chris Parker when he was trying to do the so-called “unixoid-challenge”. See the github question here. Sadly, no one has answered him in over a year. I clearly don’t know enough to understand his question, but it seems to be generally about BASH_FUNC__gnomeopen being a multiline variable, which is supposedly a problem for a program which is handling variables.


#4

interesting, sh seems to be unable to handle exported bash functions
could you try running at with env -i to get clean environment

env -i at now + 1 minute <<< 'echo "123"'

This command would be really handy for stateful web applications, and that’s what cloud9 is supposed to be all about, right?

i am not sure i fully understand what you mean, but webserver using at to schedule stuff doesn’t sound right


#5

Thank you, that works perfectly! Specifically excluding the two multiline variables with “env -u” works as well. It seems that at’s environment is completely inherited by the job, even though it’s not technically a child process.

How so? If a webserver is providing some sort of a timed service which requires creating a new file structure on the server hard drive, it makes sense to schedule automatic deletion of that file structure when the service expires. Hence, either “cron” or “at”, depending on the circumstances.