这实际上不是一个编程问题。Server Fault 或 Unix & Linux 社区可能是提出这个问题的更好地方。

脚本将删除子树中 /home/admin/web/diegeschichte.in/public_html/wp-content/tv 以 结尾的任何文件（或目录）， .ts 这些文件至少在 7 天前被修改过。只有您知道这是否正确。将日志文件写入 /home 目录而不是 /var/log 目录很奇怪。您可以记录到 syslog 而不是创建所有这些文件吗？该 logrotate 工具是为此而构建的，因此您可能希望检查它而不是查找。

您可能需要考虑：

• 更改 -ctime 为 -mtime 。否则，至少每 7 天写入一次的文件可能会永远存在。
• 如果只想删除文件， -type f 请添加
• 如果您不希望存在文件则 -f 删除
• 添加 -maxdepth ... ，以便它不会意外遍历子目录（如果有）。
• find ... -print0 | xargs -0 rm 可能比一次删除一个文件更快。

我会将该脚本存储在 /usr/local/bin 中。要从 cron 运行脚本，您需要为 your_user 创建一个对相关文件具有写入权限的 crontab。 crontab -e （如果您想以 root 身份执行此操作，则为 `crontab -e -u your_user）然后确定要为脚本使用的时间表，例如，每午夜 13 分钟：

13 0 * * * /usr/local/bin/your_script

或者，您也可以将一个文件放在 /etc/cron.d 中来运行您的脚本。这需要 root 权限，但它允许您指定执行脚本的用户。例如：

13 0 * * * * your_user /usr/local/bin/your_script

（systemd 还具有运行定时命令的功能）。

如果您计划更频繁地运行脚本，请考虑当下一个脚本启动时脚本仍在运行（以及下一个和下一个）的可能性，但服务器仍然无响应。为防止这种情况，请考虑使用文件锁 flock 和/或使用命令运行它 timeout 。

如果您拥有大量文件，请考虑使用 来限制您一次处理的文件数上限，例如 1000 个 find ... | head -z -n 1000 | xargs ... 。如果该上限比 快，则 timeout 脚本每次运行时都会取得进展。然后您可以更频繁地运行此脚本，因为它会分散 I/O 负载。