Closed linyongfu2013 closed 2 years ago
why use such rare file type ? why not zip tgz ....?
@aristocratos sorry for digging this up again, but what about the other question?
why use such rare file type ? why not zip tgz ....?
I.e., is there any major benefit in choosing bzip over gzip here? IMO, although bzip may be faster or result in smaller archives, gzip is much more widely known and supported (as can be seen by this issue), which is a key factor for OSS to me.
@Gerrit-K I'm not sure where you got the idea that bzip2 is a rare compression format? It should be included in the base packages and come preinstalled in most (if not all) linux distributions.
Also, unless you're using a non GNU (ord BSD) version of tar
or a very outdated one, the command to unpack is the same for both gzip and bzip2 -> tar -xf archive.t*z
Well, "rare" wouldn't have been my choice of words, I just quoted the original issue author ;)
I know that bzip2 is also very common and installed on most systems, but still it seems to me that the de facto standard for GitHub binaries is *.tgz
. So I'm simply asking if diverging from that was a deliberate choice and (if so) want to know the intention behind that :)
Edit:
To give a bit of background here: I stumbled upon this when I tried to migrate from bpytop
to btop
in my zinit
configuration and it appears that zinit
doesn't support *.tbz
archives, yet. Obviously, this is not an issue with btop
but rather with zinit
(hence, I created an issue there). But it was the very first time I've stumbled over a tbz archive and I was curious about the intentions behind this choice.
So I'm simply asking if diverging from that was a deliberate choice and (if so) want to know the intention behind that :)
It's just for the better compression. The decompress time (for the release package) will be under 1 second for probably any machine made in the last 15 years for both gzip and bzip2. So didn't really see any reason to not go for better compression.
The reason bzip2 not working with zinit could maybe be an oversight of the author specifying the So if you find the part of the sources for handling compressed files you could possibly submit a PR with a fix yourself.-z
flag for tar
and not letting tar
autodetect the compression.
Edit: Found it. In zinit-install.zsh
((#i)*.tar.bz2|(#i)*.tbz2)
→zinit-extract() { →zinit-check bzip2 "$file" || return 1; command bzip2 -dc "$file" | command tar -xf -; }
;;
((#i)*.tar.gz|(#i)*.tgz)
→zinit-extract() { →zinit-check gzip "$file" || return 1; command gzip -dc "$file" | command tar -xf -; }
It assumes the short for .tar.bz2
should be .tbz2
and doesn't detect just .tbz
Awesome! Thanks for the explanation and especially thanks for going the extra mile to take a look at my specific issue with zinit
👏 much appreciated!
I'll take a look and see if I can provide a fix there. Shouldn't be too difficult based on your findings.
@Gerrit-K No problem :)
Just a note if you submit a patch, you would also need to add tbz
to the accepted file list on line 1575 in zinit-install.zsh
Describe the bug
how to open tbz in centos? google not found solution.
To Reproduce
[Steps to reproduce the behavior:]
Expected behavior
[A clear and concise description of what you expected to happen.]
Screenshots
[If applicable, add screenshots to help explain your problem.]
Info (please complete the following information):
btop -v
uname -m
uname -r
Additional context
contents of
~/.config/btop/btop.log
(try running btop with
--debug
flag if btop.log is empty)GDB Backtrace
If btop++ is crashing at start the following steps could be helpful:
(Extra helpful if compiled with
make OPTFLAGS="-O0 -g"
)run (linux):
gdb btop
(macos):lldb btop
r
to run, wait for crash and press enter if prompted, CTRL+L to clear screen if needed.(gdb):
thread apply all bt
(lldb):bt all
to get backtrace for all threadsCopy and paste the backtrace here: