从 crontab 运行时 linux comm 会产生不同的结果
我正在从 bash 脚本运行以下命令：（
comm -23 file1 file2 > file3
file1 和 file2 首先进行重复数据删除和排序）
这会生成一个 file3仅包含 file1 特有的行（我想要的）。
从命令行运行脚本时，没有问题。但是，当它从 crontab 运行时，它会生成一个更大（不正确）的 file3。 crontab 用户与手动运行时登录的用户相同。
关于什么会导致这种差异有任何线索吗？
提前致谢
I am running the following command from a bash script:
comm -23 file1 file2 > file3
(file1 & file2 are de-duped and sorted first)
This produces a file3 that contains rows unique to file1 only (what I want).
When the script is run from the command line, there are no issues. However, when it is run from the crontab, it produces a much larger (incorrect) file3. The crontab user is the same as the logged-in user when run manually.
Any clues as to what would cause such a discrepancy?
Thanks in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从 shell 运行的程序与从
cron内运行的程序之间的几乎所有差异都与环境有关。首先要做的就是在两个地方运行类似
env的东西并捕获输出。它可能就像运行不同的可执行文件一样简单，因为路径不同。另一种可能性是两个环境之间的 LC_COLLATE 设置不同。从
信息页面：--check-order选项可能是检查此问题的一种方法，这会导致未排序的输入出现致命错误（包括基于与您认为使用的排序规则不同的排序规则进行未排序）。Almost all disparities between programs running from your shell and from within
cronhave to do with the environment.The first thing to do is to run something like
envin both places and capture the output. It may be something as simple as running a different executable because the paths are different.Another possibility is that the
LC_COLLATEsetting is different between the two environments. From theinfopage:The
--check-orderoption may be a way to check this, causing a fatal error on unsorted input (including unsorted based on a different collation than you think you're using).