New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bug] EIDE 无法正确处理 .tar.xz 工具链包 #262
Comments
对于 linux,仅支持普通的 tar 包解压,不会根据后缀 tar.gz tar.xz 等调用特定命令解压 请提供较通用的格式,比如 zip, 7z 这样更便于完全统一解压命令 |
了解,我修改一下 |
GNU tar 和 BSD tar 均可在解压(x mode)和列出(t mode)时自动检测文件格式。
https://www.gnu.org/software/tar/manual/tar.html#gzip
https://man.freebsd.org/cgi/man.cgi?tar(1) 因此,只需 |
Switch Linux toolchain package format to 7z to workaround decompression issue. See github0null/eide#262.
目前在非 win32 环境中,对于后缀带有 tar 字样的, 默认就是用的 tar -xvf 但实际对于 tar.xz,可能要使用 -xvJf Lines 66 to 69 in b8699d3
|
流行的 tar 实现中,只有 Busybox tar 需要在解包时指定格式。 GNU tar 为每种受支持的压缩格式硬编码了 magic 并被优先用于格式识别,不能识别时回落到扩展名识别。因此只有 magic 和扩展名均不正确的 tar.xz 才可能需要使用 GNU tar 不会出现前面所述的「外层 xz 被解压而内层 tar 未被解包」的情况,GNU tar 调用外部程序后是直接通过管道传回,不会在磁盘上创建临时文件。如果 GNU tar 不能识别格式,只会报错退出,不会执行任何进一步操作。这个问题应该另有原因。 BSD tar 的情况类似。 实际上,对于 Line 163 in f8ad4c5
https://github.com/github0null/node-utility/blob/cb1e5e59e138f7fe997eb2118d9c2f65f0109d7a/File.ts#L22 zipFile.suffix 实际上就是 Path.extname ,返回文件狭义的(即最外层的)扩展名。因此,*.tar.xz 的 suffix 就是 xz ,看似取巧的 startsWith() 在这里起不到任何预期作用。eide_default_external_tools_index 中的 zip_type 在这里并没有被使用。
获取广义扩展名的现有实现可供参考: https://github.com/ruyadorno/path-complete-extname |
OK,软件逻辑错误后面会修复的 |
What are you doing?
Linux 环境下,在 EIDE 中下载 MTI GCC 对应的工具链包(.tar.xz 格式)。
Describe the bug
下载和解压工具链包后,EIDE 报错显示工具链不可用,检查默认安装位置 (
~/.eide/tools/mti_gcc
) 后,发现里面只有一个解压了 .xz 的 .tar 文件。To Reproduce
见上
Expected behavior
EIDE 应该解压 .xz 后同时解压 .tar。
Screenshots
N/A
Desktop (please complete the following information):
Additional context
N/A
The text was updated successfully, but these errors were encountered: