UExtract-4.12 - A Universal/Utter/Ultimate/Uhatever Extractor

[don570]

I tested uextract 4.10 in Easy OS and it works somewhat.
I could make a launch icon on the desktop and it appears to work.
I could extract a pet file.

It appears that the pinstall.sh script doesn't create the right click links for ROX.
The script is run. I ran it in the terminal to see what would happen.
But nothing occurred (see image....)

screenshot-script-pinstall.png (71 KiB) Viewed 1861 times

__________________________________________________

usr/locl/apps/UExtract folder is created (see image)
I was able to manually create links to AppRun.
__________________________________________________

[JakeSFR]

It appears that the pinstall.sh script doesn't create the right click links for ROX.
The script is run. I ran it in the terminal to see what would happen.
But nothing occurred (see image....)

If you want to run UExtract's pinstall.sh script manually, you need to invoke it from / directory for it to work, so:

Code: Select all

cd /
/path/to/pinstall.sh

then it should create the symlinks, BUT:

Like I said before, there is something in Easy that prevents creating intended associations when installing a PET.
I checked and I think it's the build-rox-sendto script (invoked via petget) that abitrarily rebuilds all Open With symlinks, so basically everything done by UExtract's pinstall.sh will be reversed next time you install something.

Oh, and I just found this: https://forum.puppylinux.com/viewtopic. ... 679#p36679

There's not much I can do about it, that's how this system works.

Greetings!

[don570]

It's still useful with the desktop icon.
___________________________________

[don570]

I did some testing on Easy OS and found that a script to make the right click links is feasible.
First install the UExtract pet, then run the script to make the links (equivalent to a pinstall.sh script).
The script checks for the distro name.
Here's an example to make links to deb and pet packages and zip files.

Code: Select all

#!/bin/sh
cd  /etc; grep -q "Easy D" DISTRO_SPECS
if [ "$?" -eq 0 ]; then
mkdir -p /root/.config/rox.sourceforge.net/OpenWith/.application_zip
ln -fs /usr/local/apps/UExtract /root/.config/rox.sourceforge.net/OpenWith/.application_zip
mkdir -p /root/.config/rox.sourceforge.net/OpenWith/.application_vnd.debian.binary-package
ln -fs /usr/local/apps/UExtract  /root/.config/rox.sourceforge.net/OpenWith/.application_vnd.debian.binary-package
mkdir -p /root/.config/rox.sourceforge.net/OpenWith/.application_pet
ln -fs /usr/local/apps/UExtract  /root/.config/rox.sourceforge.net/OpenWith/.application_pet

fi

[don570]

I used the above method to make a pet of uextract for easy OS
http://forum.puppylinux.com/viewtopic.p ... a96abde280

However strange behaviour during right click of SFS files.

________________________________________________________

[JakeSFR]

Yeah, this is really weird. I think you should carefully examine the symlinks as they are now.
Perhaps something's changed/broken them (a suspect: build-rox-sendto script).

Speaking of which - what if you install UExtract, the original PET as well as yours, with /usr/sbin/build-rox-sendto set to be non-executable?

Btw, I still can't boot Easy in QEmu in Fatdog - it just hangs at "Working-patition: sda2" with one CPU core maxed out and the used memory slooowly growing.
Gave it like 15 minutes and nothing else happened.

Greetings!

[don570]

Maybe it's not compatible with a windows partition.

I do a simple frugal install. It's a lot like fatdog linux .

To install EasyOS to the ext4 partition on the computer internal drive, copy those three files 'vmlinuz', 'initrd' and 'easy.sfs' across.

https://easyos.org/install/easy-frugal- ... ation.html

menu.lst file...

Code: Select all

title EasyOS Dunfell (partition sda3 folder easyos)
  find --set-root-uuid () 054a04b8-0f00-11ed-aeb9-287fcfeb4376
  kernel /easyos/vmlinuz rw wkg_uuid=054a04b8-0f00-11ed-aeb9-287fcfeb4376 wkg_dir=easyos
  initrd /easyos/initrd

[JakeSFR]

Version 4.11:

- fix extracting mp2 audio from .mpg vids
- fix extracting adpcm_ima_qt audio from .mov vids
- minor fixes and improvements
- new formats/extensions:

• .3gpp (3GPP Media File) [avconv|ffmpeg]

• .qt (Apple QuickTime Movie) [avconv|ffmpeg]

• .rlib (Static Rust Library) [ar|7z]

• .ucimg (FirstRib Savefile) [{cryptsetup|{gdisk|fdisk}}+mount]

First post updated.

Greetings!

[MochiMoppel]

@JakeSFR

Only a minor point: BLUECOL="\e[0;34m" leads to unreadable text in dark terminals.

uextract_bluecolor.png (50.43 KiB) Viewed 1389 times

[JakeSFR]

@JakeSFR

Only a minor point: BLUECOL="\e[0;34m" leads to unreadable text in dark terminals.

Come on, it's not _that_ bad, I can read it fine (and I'm overdue for new glasses), it's just slightly unpleasant.
Besides, it's only info stuff, as opposed to more important warnings (yellow) and errors (red).

However, if it comes for the latter two, the format is like ${REDCOL}ERROR: ${OFFCOL}Error Message, so I might want to do it the same way also for the info messages: ${BLUECOL}INFO: ${OFFCOL}Info Message, for consistency.
I'll add it to my TO-DO list.

Thanks &
Greetings!

[Jasper]

@JakeSFR

Thanks for your utility, I most probably use it several times a day without a thought

I have an error message and am unsure as if it is due to me or that it is a missing function in the application ie xz being unsupported

Can you let me know?

*EDIT* ......Ooops checked your 1st post and see that it is a format not supported.

Can be added in a future update if possible?

Thanks

[JakeSFR]

Hey @Jasper!

Well, actually the problem seems to be your unsquashfs binary, which only supports gzip compression.
Here's 32bit, statically linked unsquashfs, which you can put in /usr/local/apps/UExtract/resources and UExtract should pick it up next time.
It supports gzip, lzma, lzo, lz4, xz and zstd.

https://we.tl/t-ItCOWeV2Vc

MD5: d4ee115183bd9de9d0ab98be132ab06e unsquashfs

Btw, make sure to make it executable.

Greetings!

[Jasper]

@JakeSFR

Thanks for the reply and the binary.

I saw the message in the directory and have some other binaries that can be utilised too

[mikeslr]

Pre-Second-Cup-of-Coffee.

It took me awhile to realize that the issue reported by jasper in the third post before this one and SFR's gracious publication of a file to solve that issue only relates to running UExtract under a 32-bit system.

To make sure I got that right, I just UExtracted an xz-compressed file under Fossapup64-9.6. Extraction went smoothly without any warnings.

[Jasper]

@mikeslr

I am using a 64bit OS and yes the 32bit binary works perfectly fine for me.

this is a bit strange when I checked the two versions of the binary in both locations

It works regardless, so that's important to me and solved my problem

[JakeSFR]

@MochiMoppel: I was going to add some MIME types to the main desktop file, but noticed strange things happening.

For example, despite this line in /usr/share/applications/mimeinfo.cache:
application/x-7z-compressed=defaultarchiver.desktop;engrampa.desktop;uextract.desktop;
UExtract still doesn't show up in Firefox, although both defaultarchiver and engrampa are still available.
Same with application/zstd=engrampa.desktop;uextract.desktop; - only engrampa shows up.

And conversely, having uextract.desktop in these lines:

Code: Select all

application/x-gzip=defaultarchiver.desktop;engrampa.desktop;uextract.desktop;
application/gzip=uextract.desktop;

causes defaultarchiver to disappear from available handlers (engrampa is still there) and uextract becomes the default one.

At the end of the day it's too messy and unpredictable, so I'll just leave it as is for now.

Greetings!

[JakeSFR]

Version 4.12:

• changed all blue info messages to the default color, but with blue 'INFO:' prefix (thanks to MochiMoppel)
• minor fixes and improvements
• new formats/extensions:

  • .bz3 (Bzip3 Compressed File) [b(un)zip3]

  • .bzip3 (Bzip3 Compressed File) [b(un)zip3]

  • .cpio.bz3 (Bzip3 Compressed CPIO Archive) [b(un)zip3+cpio]

  • .cpio.bzip3 (Bzip3 Compressed CPIO Archive) [b(un)zip3+cpio]

  • .lrv (Low-resolution Video File) [avconv|ffmpeg]

  • .pcv (Picocrypt Encrypted File) [picocrypt]

  • .rxdbak (RxDroid Backup File) [unzip|7z]

  • .tar.bz3 (Bzip3 Compressed Tar Archive) [b(un)zip3+tar]

  • .tar.bzip3 (Bzip3 Compressed Tar Archive) [b(un)zip3+tar]

  • .tbz3 (Bzip3 Compressed Tar Archive) [b(un)zip3+tar]

  • .xpak (Gentoo Binary Package) [{b(un)zip2|g(un)zip|(un)lz4|l(un)zip|(un)lzma|(un)lzop|(un)xz|(un)zstd}+tar]

  First post updated.

Greetings!

[MochiMoppel]

@MochiMoppel: I was going to add some MIME types to the main desktop file, but noticed strange things happening.

Those strange things you describe happen in Firefox, but you wrote earlier

Well, both UExtract and PackIt are meant primarily as ROX right-click apps, so there's no postponing anything, everything's as intended. And they definitely weren't designed as Firefox's or anything else's handlers.

So I now wonder why you are concerned about the behavior in Firefox. I assume that you tested in Fatdog. Strange that you see an effect at all. Here in BW64 I use LibreWolf. The browser seems to disregard /usr/share/applications/mimeinfo.cache. E.g. a typical line in mimeinfo.cache would read

Code: Select all

application/x-tar=pextract.desktop;UExtract.desktop;xarchiver.desktop

When trying to open a tar archive in LibreWolf I'm given a choice like in a Russian election: Though with pextract, UExtract and xarchiver there are 3 candidates, LibreWolf offers "Default archiver (default)" and also Xarchiver under "Recommended Applications". Default archiver is the name for defaultarchiver file, which in turn is a wrapper script for Xarchiver. So I have the choice between Xarchiver and Xarchiver
I can change the default in /usr/share/applications/mimeapps.list, but that's about the only file that has any effect on the handler choices presented by the browser. There are also defaults defined in /etc/pmime.conf , probably created by the /usr/sbin/pmime script, but these settings are ignored by the browser.
So yes, in the browser MIME handlers are a mess. Only relevant if the user wants the browser to open an archive, irrelevant if the user instructs the browser to download the archive - which is the default behavior.

As for applications other than browsers everything works as expected in BW64. Here by default MIME declarations are included in the (main) UExtract.desktop file. No related files are created in ~/.config/rox.sourceforge.net/SendTo. I know that you don't like this. I still don't know why. It works

[Grey]

When trying to open a tar archive in LibreWolf I'm given a choice like in a Russian election: Though with pextract, UExtract and xarchiver there are 3 candidates, LibreWolf offers "Default archiver (default)"

Nothing in common There were 4 candidates. But three archivers were unknown to anyone (who is the author, which version?!), so users chose the default time-tested archiver with high compression and speed

[JakeSFR]

So I now wonder why you are concerned about the behavior in Firefox.

Because I don't want to introduce, or rather add, more chaos to it.

As for applications other than browsers everything works as expected in BW64. Here by default MIME declarations are included in the (main) UExtract.desktop file. No related files are created in ~/.config/rox.sourceforge.net/SendTo. I know that you don't like this. I still don't know why. It works

I guess if it wasn't for Firefox (and other browsers, IIRC), I'd probably go for it, but it's so untidy; puts me off. :/

Greetings!

[Jasper]

@JakeSFR

Thanks for the update, as always my "go to" application

I am using a different build of PuppyOS ie JammyPup64.

I have only realised that this only supports Gzip.

I did have this problem when I was using FossaPup64-95 and you kindly shared a SFS binary that resolved the issue:

viewtopic.php?p=88701#p88701

The link has expired and I was hoping that it is a "universal" binary that I could use with my current build?

If so, and if it is not too much trouble, could you share it once again?

[JakeSFR]

Sure, no problem, attached.

Greetings!

[Jasper]

@JakeSFR

Thank you so much

I have been flitting between two devices to use the application.

I will 'put it away' in a safe place

Have a great weekend!!

[Jasper]

@JakeSFR

I still am experiencing some difficulties with this application.

I am using Jammypup64 and this is the contents of my resources directory

I have checked my Fossapup64-95 OS and the contents are the same as above and this presents no problems with extracting zstd archives.

Any suggestions?

** EDIT ** maybe I need to compile a static zstd binary?

[JakeSFR]

** EDIT ** maybe I need to compile a static zstd binary?

No, the unsquashfs binary has all needed things already compiled-in.

But I think I know what's happening here.
UExtract probes for unsquashfs binary using these names, in this order:

unsquashfs4 -> unsquashfs -> unsquashfs3

given that, at least at some point, the first one was the latest version.

So, I think JammyPup has unsquashfs4 binary/link somewhere in PATH and that's why the one from the resources directory is not being picked up.

Try to change its (the one in resources dir) name to unsquashfs4 and see what happens.

Greetings!

[Jasper]

@JakeSFR

Changing the name to unsquashfs4 did the trick

Thank you ......... you've saved me having to go back and forth between two devices