This is likely caused by the environment export code in at, see writefile() in at.c:

    /* Write out the environment. Anything that may look like a
     * special character to the shell is quoted, except for \n, which is
     * done with a pair of ""'s.  Dont't export the no_export list (such
     * as TERM or DISPLAY) because we don't want these.
     */

at generates invalid shell code when serializing the environment:

BASH_FUNC_module()=\(\)\ {\ \ eval\ \`/usr/bin/modulecmd\ bash\ \$\*\`"
"}; export BASH_FUNC_module()

In retrospect, () was a poor choice as the suffix, but I used it because it was already used by bash before (see previous comments in the file).

FWIW, I have not been able to reproduce with cron.

Limited workaround: Add the following to /etc/profiled/modules.sh.  This will help for use from interactive shells and shell scripts (as long as they use at and not /usr/bin/at), but there are ways to call the at command bypassing the function, so it is not a complete workaround.

if test -n "$BASH_VERSINFO"; then
  at () {
    (
      declare -f +x module at
      /usr/bin/at "$@"
    )
  }
  export -f at
fi

This also seems to work, and its effect is complete at least as far as environment-modules is concerned.  It reverts the “export -f module” in /usr/share/Modules/init/bash.  It may have a functionality impact on environment-modules, so it needs more testing.

if test -n "$BASH_VERSINFO"; then
  declare -f +x module
fi

@Florian Weimer thanks for the "workaround" so we can use "at jobs" while a real fix are being made. Is it possible to add so that the workaround also works when called from the script "/usr/bin/batch" which also comes from the "at" package ? 

[testuser@test001 ~]$ batch
at> echo hi
at> <EOT>
still results in:
 
sh: line 36: syntax error near unexpected token `=\(\)\ {\ \ \(\ declare\ -f\ +x\ module\ at\;"
"\ /usr/bin/at\ \"\$@\"\ \)"
"}'
sh: line 36: `"}; export BASH_FUNC_at()'

Created attachment 942671 [details]
at-skip-names.diff

Upstream fix for at, from at 3.1.16.

http://anonscm.debian.org/cgit/collab-maint/at.git/commit/?id=482f5962d

(In reply to Florian Weimer from comment #8)
> Limited workaround: Add the following to /etc/profiled/modules.sh.  This
> will help for use from interactive shells and shell scripts (as long as they
> use at and not /usr/bin/at), but there are ways to call the at command
> bypassing the function, so it is not a complete workaround.
> 
> if test -n "$BASH_VERSINFO"; then
>   at () {
>     (
>       declare -f +x module at
>       /usr/bin/at "$@"
>     )
>   }
>   export -f at
> fi
> 
> This also seems to work, and its effect is complete at least as far as
> environment-modules is concerned.  It reverts the “export -f module” in
> /usr/share/Modules/init/bash.  It may have a functionality impact on
> environment-modules, so it needs more testing.
> 
> if test -n "$BASH_VERSINFO"; then
>   declare -f +x module
> fi
-------------------------------------
Environment: CentOS6
I've just inserted the test from the top of this comment into /etc/profile.d/modules.sh, and tested the fix using a tiny script that just touches a file.   I get the same error message as I did before I added  this.   Command was "at -f ./touchfile now"
Script is:

#!/bin/bash:
touch x.y

I got hold of the at source rpm for at.
I added the patch mentioned above, <at-skip-names.diff>
to the spec file and the sources, and rebuilt the rpm from the new
source.
   
Command:  rpmbuild -ba "at.spec"

I ran rpm --force to overwrite the old "at."

Fixed the problem.

Environment -- CentOS 6.5 -- 2.6.32-431.23.3.el6.x86_64

(In reply to Matt Temple from comment #20)
> I've just inserted the test from the top of this comment into
> /etc/profile.d/modules.sh, and tested the fix using a tiny script that just
> touches a file.   I get the same error message as I did before I added 
> this.

You need to re-login, so that the changed profile scripts run.

I think we should consider fixing this in the “at” package.

*** Bug 1146958 has been marked as a duplicate of this bug. ***

It seem that at-3.1.10-45.el6 is not yet available; however, installing at-3.1.10-44.el6 solve the issue already. Has the version noted in "Fixed in Version" probably a typo or am I getting something wrong?

No, the -45 version just corrects release date in the changelog of the rpm.

So the issue is fixed within -44? If so, that version should be mentioned.

Sorry that I'm picky with that, but I've trouble to explain why I installed "only" -44 on RHEL 6.5 and got it fixed, while the fix is only as of -45

I have mislead you with the comment. Because the RHEL-6.5 fixed version is completely different. You cannot depend on Fixed in field here, I am sorry. This field is used for our internal process for tracking fixes on various RHEL release branches.

What is delaying this fix? Not allowed to see #1075802, why?
This has been out for CentOS for some time, makes no sense.

Hi Bill,

We have shipped errata for:
6.6.z
https://rhn.redhat.com/errata/RHBA-2014-1637.html
6.5.z
https://rhn.redhat.com/errata/RHBA-2014-1362.html
6.4.z
https://rhn.redhat.com/errata/RHBA-2014-1638.html

This BZ, 1147043, if for an errat that will ship in RHEL 6.7.

BZ 1075802 is an internal tracker for the 6.7 minor release.

HTH,

cww

Chris,

Thanks, evidently my rhn source is not seeing these at this time, will pursue there.

I have also run into this problem but it has nothing to do with "at" command.

The problem I have is the "BASH_FUNC_???" environment exports when you call bash with the verbose option.

For example the command...

echo "echo hi" | bash -v

Outputs....

module () {  eval `/usr/bin/modulecmd bash $*`
}
scl () {  local CMD=$1;
 if [ "$CMD" = "load" -o "$CMD" = "unload" ]; then
 eval "module $@";
 else
 /usr/bin/scl "$@";
 fi
}
echo hi
hi

Which are functions exported by the /etc/profiled/modules.sh  I have NO idea what these functions are ment to provide, and really I don't care.   All I know it they stuff up any program that uses the verbose flas (presumably "at" command does this).

Note using  sh -v  also does this when 'sh' is a link to 'bash'.

Solutions so far (at least for my shell script...

1/ Use a restricted shell, so that it doe not try to execute the exported functions.   However this means you can not use  "sh -v" which is needed if the script may be usable on older Bourne shell systems (a possibility in my case).

   bash --restricted -v

2/ unset the exports beforehand.  This   

      unset -f `env | sed -n 's/^BASH_FUNC_\([a-z]*\)()=.*/\1/p'`



QUESTION: why does BASH manpage no list BASH_FUNC_???  With all the stuff about shellshock I would have thought they would at least improve the bash manpage with some more info about it!

PS: the last was with Fedora 22

Fixed in the released version.

How was it fixed?

It is very bad (both manners and in documenting) to just say 'It is fixed!' without actually given the reporters an idea as to 'How was it fixed!'.

We do not have an 'inside track' to the developers, so at least a minimal bit of feedback would be appreciated.

The fix is described here:
https://access.redhat.com/errata/RHBA-2014:1637