关于文件操作失败的有效错误报告方式

[codehz]

描述问题

之前由于在chroot容器中使用xmake忘记重新挂载/dev/shm （同时还映射了UID），导致 xmake 运行时无法正常创建临时文件，但是由于报错没有提供足够的有效信息，导致很长一段时间里都没有排查出具体原因，最后是通过在源代码里寻找才发现的。

期待的结果

任何涉及系统API的调用失败都应该返回具体的错误代码（at least）和关于此代码的简单文本描述
而只不是一个xmake自身的调用堆栈（很可能没有意义）

错误信息

> os.runv("unzip -v")
@programdir/core/sandbox/modules/os.lua:311: runv(unzip -v) failed(-1)!
stack traceback:
  [C]: in function 'error'
  @programdir/core/base/os.lua:762: in function 'raise'
  @programdir/core/sandbox/modules/os.lua:311: in function <@programdir/core/sandbox/modules/os.lua:303>
  [C]: in function 'interactive'
  ...dir/core/sandbox/modules/import/core/sandbox/sandbox.lua:93: in function 'interactive'
  @programdir/plugins/lua/xmake.lua:92: in function <@programdir/plugins/lua/xmake.lua:28>
  [C]: in function 'load'
  @programdir/core/base/task.lua:508: in function 'run'
  @programdir/core/main.lua:233: in function <@programdir/core/main.lua:171>

可见，从这个错误信息中，要得出/dev/shm/.xmake0目录不可写这个结论是十分困难的
（本身这个错误也是在种种巧合下出现，本质上和xmake无关）
而如果在os.runv中能直接发现给出的临时文件不可写并且报告的话，就可以减少类似问题的发生

相关环境

OS: ArchLinux x64
（简易复现方法：设置/dev/shm/.xmake权限使之无法访问。）

其他信息

前面提到的/dev/shm/.xmake0权限错误并非xmake本身的问题，但是它暴露出了xmake的其他问题即错误报告方式不合理，对解决问题的帮助不大
（不过既然用了一个绝对路径表示的文件，理应考虑这种边界情况的发生。。。）

[waruqi]

恩，权限检测的错误提示 我之后会整体做个改进

[waruqi]

我改进过了，dev上，你试试，进程运行，文件系统操作相关错误状态都改进过了。。

[waruqi]

我这里验证没啥问题，先close了，有问题再reopen好了