我已经下载并编译了jsmin.c，并在终端的javascript文件上运行它，它看起来效果很好。但是当我从一个python脚本（在同一个输入文件中）的os.system（）或os.popen（）调用它时，输出文件（js文件的缩小版本）被截断，好像stdout是在子进程退出之前没有刷新，或者好像jsmin提前终止，或者好像可能是某些东西正在进行磁盘缓冲等等。
但似乎并非如此。退出值是我从main（）返回的任何内容，即使输出被截断，并且添加对fflush（stdout）的调用没有任何区别，并且在调用jsmin之后从同一子shell中调用sync不会使任何差异。
我尝试用对fputc（）的调用来替换对putc（）的调用，起初它似乎解决了问题（出于一些不可思议的原因？），但是，莫名其妙地，问题又开始发生了，现在又发生了可靠。 Bizare？
我想说这是jsmin.c的一些问题，但是当从命令行运行时程序在同一个输入文件上工作正常，所以它与从python子进程运行它有关。
这是我的子进程调用：
result = os.system('jsmin < ' + tpathname + ' > ' + tpathname + '.min')
（我已将jsmin放在路径中，并且它正在运行，我在.min文件中获得了大部分预期结果。）
谁能想象可能导致这个问题的原因？
答案 0 :(得分：0)
Stack Overflow不会让我回答我自己的问题5个小时或类似的东西，所以这个'答案'最初是作为编辑添加的。 （它也不会让我聊天，所以评论有点延伸。）
我发现了问题。问题在于python程序正在为jsmin创建输入文件，然后在其上调用jsmin。它正在创建一个文件，但尚未关闭它（然后），然后在其上调用jsmin。所以jsmin并没有提前终止，也没有将其输出截断;相反，它是在一个（尚未）不完整的输入文件上运行。 （咄。）
我会比我更早地意识到这一点，除了python程序最终关闭jsmin的输入文件（通过退出），所以当我检查它时，它似乎完成了。只是在jsmin处理它时它还没有完成。
这就是'与'成语的动机之一：
with open(targetpath, 'w+') as targetfile:
..code that writes to targetfile