它运行得很好，只是用at运行的命令没有将它们的输出写到你调用它的终端。
请尝试：

at now +2 minutes
echo TTTEEEST > new_file_test

您将在两分钟后看到该文件。

看一下/var/at/jobs，看看你的at作业是否列在那里。（根据操作系统的不同，它可能是一个不同的目录）。
默认情况下，at在大多数系统上是不启用的。为了使at作业真正得到执行，必须执行atrun命令。
此命令通过launchd或cron执行，具体取决于系统。
具体的机制因系统而异，因此您必须阅读有关at、atrun等的所有联机帮助页，以验证您的系统上是否真的启用了at，以及您是否具有运行at作业的权限。因此您需要同时选中这两个选项。您必须同时在 * allow * 文件中，并且不在 deny 文件中。
最重要的是，您必须确保at甚至在您的系统上被启用（出于安全考虑，它通常被禁用）。

检查您的邮件：

An at - or batch - command invoked from a su(1) shell will
   retain the current userid.  The user will be mailed standard
   error and standard output from his commands, if any.  Mail
   will be sent using the command /usr/sbin/sendmail.  If at is
   executed from a su(1) shell, the owner of the login shell
   will receive the mail.

我找到了这个here
首先，使用如下命令确保at守护进程正在运行：

# ps -ef | grep atd

root 8231 1 0 18:10 ? 00:00:00 /usr/sbin/atd

如果没有看到atd正在运行，请使用以下命令启动它：

# /etc/init.d/atd start

为了分析（d）处的执行问题，以下做法可能会有所帮助：
1.检查/etc/at.allow和/etc/at.deny是否存在和内容（请参阅man at.allow）
1.检查atd假脱机目录（/var/spool/cron/atjobs，daemon：daemon，Ubuntu上为770）的所有者和访问权限
1.检查atd守护程序是否正在运行（Ubuntu上的systemctrl -a | grep atd）

1. tail -f /var/log/syslog（在执行时）
2. journalctl -b | grep atd（发现here，包含进一步的提示）
   “Permission denied”错误也可能是由于/etc/security/limits. conf中定义的登录次数有限（对于at运行用户）造成的。

当使用at命令时，我也遇到了同样的echo问题。但是如果你尝试使用>或>>来重定向输出，那么它会很好地工作。也可以尝试一些其他的系统命令，如reboot，ls > some_text_file等，以确保at命令是工作的。或者尝试sudo systemctl enable --now atd来启用at守护进程

第一个结论：atrun或atd守护程序未运行，从而导致此问题。
解决案例的指导原则：
1.首先通过man at检查at mannul。在我的例子中，我（macos 10.13.6）找到了以下信息：

Note that at is implemented through the launchd(8) daemon periodically invoking atrun(8), which is disabled by default.  See atrun(8) for information about enabling atrun.

1.通过man atrun检查atrun手册，发现：
atrun实用程序运行由at（1）排队的命令。它由launchd（8）定期调用，如com.apple.atrun.plist属性列表中所指定的。默认情况下，属性列表包含设置为true的Disabled键，因此不会调用atrun。
1.以root身份执行以下命令以启用atrun：launchctl load -w /System/Library/LaunchDaemons/com.apple.atrun.plist