Puppy Linux Discussion Forum

Just a minor update, since I've accidentally stumbled upon a few new extensions soon after releasing the last one.

Version 4.6:

- new formats/extensions:

• .aab (Android App Bundle) [unzip|7z]

• .apkm (Android App Bundle Mirror) [unzip|7z]

• .apks (APK Set Archive) [unzip|7z]

• .sxz (Slackware Squashfs Module) [unsquashfs]

First post updated.

Greetings!

JakeSFR wrote: ↑Wed Sep 29, 2021 4:58 pm

.apks (APK Set Archive) [unzip|7z]

Gratitude!

Cheers, Jake. Much appreciated, as always.

It must be one of my most commonly-used utilities; frankly, I can't really imagine being without it..!

"Ta very much, lad!"

Mike.

After decompression, exit appears, but the terminal does not exit. It is necessary to close the terminal manually. What is the problem?

linuxunix wrote: ↑Mon Oct 18, 2021 1:18 am

What is the problem?

Why should the terminal exit? It contains important information about the finished decompression process, particularly any errors that occurred. The terminal gives you a chance to read the information, and because it doesn't know how much time you need to read it stays open until you close it.

There is an option:
autoclose output window if no errors

When I run UExtract 4.6 and I have this option selected.
When it completes extracting, the program closes.
I assume it had no errors, because it closed.

bigpup wrote: ↑Mon Oct 18, 2021 2:18 am

There is an option:
autoclose output window if no errors

Maybe in the GUI, but AFAIK there is no such option when running uextract from the command line

@JakeSFR The .tar.lzma format is "Supported, though not extensively tested". Unfortunately doesn't work for me.

I downloaded the package softmaker-freeoffice-982-i386.tgz from Softmaker's website https://www.freeoffice.com/en/download/applications

The .tgz package extracted without problem. Contains 2 files:
freeoffice2018.tar.lzma
installfreeoffice

The file freeoffice2018.tar.lzma can not be extracted with uextract (v4.6):
".lzma: File format not recognized
tar: This does not look like a tar archive"

The install script installfreeoffice extracts it without problems.
The command used:
tar xf "/path/to/filename.tar.lzma" -C "/path/to/target/directory"

Would be great if this could be implemented in uextract

linuxunix wrote: ↑Mon Oct 18, 2021 1:18 am

After decompression, exit appears, but the terminal does not exit. It is necessary to close the terminal manually. What is the problem?

If you are running uextract in a terminal.
If you add

&&exit

to the end of the command.
It will close when it completes the extract operation.
Example:

uextract chklan.gz &&exit

But I too would like to see the results before I close the terminal.

bigpup wrote: ↑Mon Oct 18, 2021 4:08 am

If you are running uextract in a terminal.
If you add

Code: Select all

&&exit

to the end of the command.
It will close when it completes the extract operation.

OK, this would be a possibility.
Would close if it completes the operation successfully , would stay open if there were errors.

linuxunix wrote:

After decompression, exit appears, but the terminal does not exit. It is necessary to close the terminal manually. What is the problem?

There's literally exit displayed in the terminal? I assuming that you run UExtract via GUI, right?
Which OS?
You could also try invoking UExtract GUI from CLI and see if there are some errors in the output, e.g.:

/usr/local/apps/UExtract/AppRun /full/path/to/archive

___________

MochiMoppel wrote:

The file freeoffice2018.tar.lzma can not be extracted with uextract (v4.6):
".lzma: File format not recognized
tar: This does not look like a tar archive"

Ok, I checked that one and it's not LZMA, but XZ with wrong extension.
It probably was, at some point, but they've changed it and left the old extension.

The thing is that UExtract, by design, recognizes file formats mainly by extensions, not MIME types, so if it's .lzma, then (un)lzma is used for decompression.
It's not a perfect approach, but works in most of the cases.

Btw, for that exact reason, UExtract shows the actual MIME type during extraction:

===============================================================================
Extracting: freeoffice2018.tar.lzma
-------------------------------------------------------------------------------
XZ compressed data
application/x-xz; charset=binary
===============================================================================

Greetings!

JakeSFR wrote: ↑Mon Oct 18, 2021 11:25 am

Ok, I checked that one and it's not LZMA, but XZ with wrong extension.
It probably was, at some point, but they've changed it and left the old extension.

Looks like the other way round. It was something else and they changed it to what they thought was lzma:
"# lh 22.12.2017 changing the compression to lzma".
Problem is that uextract would work if I change the extension to .tar.xz but it would render the installation script unusable.

The thing is that UExtract, by design, recognizes file formats mainly by extensions, not MIME types, so if it's .lzma, then (un)lzma is used for decompression.

In my Puppy /usr/bin/unlzma is symlinked to /bin/xz, so as far as I understand (in other words not at all) even a file with a "wrong" .lzma extension should be decompressed like a file with a .xz extension.

MochiMoppel wrote: ↑Mon Oct 18, 2021 12:26 pm

JakeSFR wrote: ↑Mon Oct 18, 2021 11:25 am

Ok, I checked that one and it's not LZMA, but XZ with wrong extension.
It probably was, at some point, but they've changed it and left the old extension.

Looks like the other way round. It was something else and they changed it to what they thought was lzma:
"# lh 22.12.2017 changing the compression to lzma".
Problem is that uextract would work if I change the extension to .tar.xz but it would render the installation script unusable.

LZMA compression is used by both lzma and xz utilities, so looks like that's what they meant - compression, not the file format itself.
But they really shouldn't use that extension.

MochiMoppel wrote: ↑Mon Oct 18, 2021 12:26 pm

The thing is that UExtract, by design, recognizes file formats mainly by extensions, not MIME types, so if it's .lzma, then (un)lzma is used for decompression.

In my Puppy /usr/bin/unlzma is symlinked to /bin/xz, so as far as I understand (in other words not at all) even a file with a "wrong" .lzma extension should be decompressed like a file with a .xz extension.

I guess when invoked from that symlink, xz expects an actual LZMA compressed file and nothing else.
However, using (un)xz directly works, even if it's an XZ compressed file with .lzma extension.

A simple workaround in UExtract, would be to change this line (2984):

# (un)xz can handle lzma, too
func_exists $UNLZMA || UNLZMA="$UNXZ"

to:

func_exists $UNXZ && UNLZMA="$UNXZ"

It will force the use of (un)xz, even if (un)lzma is installed.

Greetings!

JakeSFR wrote: ↑Mon Oct 18, 2021 11:25 am

linuxunix wrote:

After decompression, exit appears, but the terminal does not exit. It is necessary to close the terminal manually. What is the problem?

There's literally exit displayed in the terminal? I assuming that you run UExtract via GUI, right?
Which OS?
You could also try invoking UExtract GUI from CLI and see if there are some errors in the output, e.g.:

Code: Select all

/usr/local/apps/UExtract/AppRun /full/path/to/archive

___________

MochiMoppel wrote:

The file freeoffice2018.tar.lzma can not be extracted with uextract (v4.6):
".lzma: File format not recognized
tar: This does not look like a tar archive"

Ok, I checked that one and it's not LZMA, but XZ with wrong extension.
It probably was, at some point, but they've changed it and left the old extension.

The thing is that UExtract, by design, recognizes file formats mainly by extensions, not MIME types, so if it's .lzma, then (un)lzma is used for decompression.
It's not a perfect approach, but works in most of the cases.

Btw, for that exact reason, UExtract shows the actual MIME type during extraction:

Code: Select all

===============================================================================
Extracting: freeoffice2018.tar.lzma
-------------------------------------------------------------------------------
XZ compressed data
application/x-xz; charset=binary
===============================================================================

Greetings!

Decompression is fine, but its terminal cannot be exited. How to change the called terminal? Or how to change the terminal in the system?
That is, I used the UExtract of buster pup before it was normal, but now after I use bullseye pup, the terminal window will not automatically close after UExtract is decompressed. How to modify it? Modify the system files?

linuxunix wrote:

Decompression is fine, but its terminal cannot be exited. How to change the called terminal? Or how to change the terminal in the system?

To change the terminal used by UExtract's GUI, you can set:

export UEXTRACT_TERM='terminal_of_your_choice'

evnironmental variable.

Put it in, e.g. /etc/profile.d/uextract.sh script and reboot.

linuxunix wrote:

That is, I used the UExtract of buster pup before it was normal, but now after I use bullseye pup, the terminal window will not automatically close after UExtract is decompressed. How to modify it? Modify the system files?

Which Bullseye Pup? Where can I find it?
I found an actual ISO only for this one: https://www.forum.puppylinux.com/viewtopic.php?t=644.

At least, what terminal is it about?

Greetings!

viewtopic.php?t=4093

That is, the window will not be closed after decompression. That window is not a terminal? Don't know how to modify
Did not find the /etc/profile.d/uextract.sh file,
export UEXTRACT_TERM='terminal_of_your_choice'
The modification has no effect

linuxunix wrote:

viewtopic.php?t=4093
That is, the window will not be closed after decompression. That window is not a terminal? Don't know how to modify

Ok, reproduced.
Gtkdialog there is built with GTK3 and libvte support, so UExtract is using gtkdialog's <terminal> widget, instead of an actual terminal.

However, <terminal> widget in Vanilla is unable to set fg/bg colors of the terminal and then does nothing on exit.

Here's a test script:

#!/bin/bash

export MAIN='
<window>
	<vbox>
		<terminal argv0="/bin/sh"
			has-focus="true"
			text-background-color="#ffffff"
			text-foreground-color="#000000">
			<variable>vte0</variable>
	    	<input>echo "echo wait for it...; sleep 3 && exit"</input>
			<action signal="child-exited">exit:EXIT</action>
		</terminal>
	</vbox>
</window>'

gtkdialog -cp MAIN

and its output:

(gtkdialog:13127): VTE-CRITICAL **: 09:57:10.289: void vte_terminal_set_color_background(VteTerminal*, const GdkRGBA*): assertion 'valid_color(background)' failed

(gtkdialog:13127): VTE-CRITICAL **: 09:57:10.290: void vte_terminal_set_color_foreground(VteTerminal*, const GdkRGBA*): assertion 'valid_color(foreground)' failed

And this happens when 'exit' kicks in:

attributeset_get_first(): set is NULL.

There's not much I can do about it.
I think you should make Dimkr aware of these issues.

[EDIT] I just built the latest Gtkdialog from https://github.com/puppylinux-woof-CE/gtkdialog against vte-0.30.1 and with '--enable-gtk3', and the terminal widget works just fine for me in Fatdog.

linuxunix wrote:

Did not find the /etc/profile.d/uextract.sh file,

You need to create one. And make it executable.

linuxunix wrote:

export UEXTRACT_TERM='terminal_of_your_choice'
The modification has no effect

And where did you put it?
As a last resort you could just add it to /usr/local/apps/UExtract/AppRun, right after the first line (#!bin/bash).

Greetings!

thanks

https://7-zip.org/a/7z2101-linux-x64.tar.xz
I downloaded 7z, named 7zz, can I set it to decompress the zip by default? It feels more compatible.

linuxunix wrote: ↑Wed Nov 03, 2021 3:03 am

https://7-zip.org/a/7z2101-linux-x64.tar.xz
I downloaded 7z, named 7zz, can I set it to decompress the zip by default? It feels more compatible.

More compatibile with what? ZIPs can be created/extracted by 7zip, WinRAR, WinZip, PeaZip, Info-ZIP, etc.

But if you really want, then add this at line 2514:

7zz $SEVENZ_OPTS "$FILEPATH" && return 0 || return 1

above this block:

<put it here>
if [ "$MODE" = "list" ]; then
	func_precheck unzip && {
		unzip $UNZIP_OPTS "$FILEPATH" && return 0
	}
else

Greetings!

JakeSFR wrote: ↑Wed Nov 03, 2021 4:21 pm

linuxunix wrote: ↑Wed Nov 03, 2021 3:03 am

https://7-zip.org/a/7z2101-linux-x64.tar.xz
I downloaded 7z, named 7zz, can I set it to decompress the zip by default? It feels more compatible.

More compatibile with what? ZIPs can be created/extracted by 7zip, WinRAR, WinZip, PeaZip, Info-ZIP, etc.

But if you really want, then add this at line 2514:

Code: Select all

7zz $SEVENZ_OPTS "$FILEPATH" && return 0 || return 1

above this block:

Code: Select all

<put it here>
if [ "$MODE" = "list" ]; then
	func_precheck unzip && {
		unzip $UNZIP_OPTS "$FILEPATH" && return 0
	}
else

Greetings!

Thanks for the answer! However, the problem has not been solved. At present, the zip archive and tar package of UExtract decompressing Japanese characters will be garbled. According to you, using 7zz will also garbled. How should I solve it? No other formats, but there are problems with zip and tar.

linuxunix wrote:

Thanks for the answer! However, the problem has not been solved. At present, the zip archive and tar package of UExtract decompressing Japanese characters will be garbled. According to you, using 7zz will also garbled. How should I solve it? No other formats, but there are problems with zip and tar.

Well, you didn't mention what the problem was.
Don't know what's with TAR, but if it comes for ZIP, it's a known issue: https://bugs.launchpad.net/ubuntu/+sour ... bug/203609.

Apparently there's a newer unzip source (beta), with which you can choose encoding.
I built it with that option enabled and it seems to work:

# UNZIP='-O shift-jis' ./unzip aaa解凍すると文字化けするかも.zip 
Archive:  aaa解凍すると文字化けするかも.zip
 extracting: 解凍すると文字化けするかも.txt  
#

as opposed to:

# unzip aaa解凍すると文字化けするかも.zip 
Archive:  aaa解凍すると文字化けするかも.zip
 extracting: ???????????????+??????????.txt
#

The attached is 32bit, static unzip-610b.
Unpack it and try if it works for you, too, and if so, put it in /usr/local/apps/UExtract/resources/.
And revert the change you made previously (unzip -> 7zz).

Then you need to invoke UExtract with this env variable set:

export UNZIP='-O shift-jis'

You can add it in /etc/profile.d/ or directly in /usr/local/apps/UExtract/uextract, just like UEXTRACT_TERM.

Greetings!

JakeSFR wrote: ↑Thu Nov 04, 2021 11:54 am

linuxunix wrote:

Thanks for the answer! However, the problem has not been solved. At present, the zip archive and tar package of UExtract decompressing Japanese characters will be garbled. According to you, using 7zz will also garbled. How should I solve it? No other formats, but there are problems with zip and tar.

Well, you didn't mention what the problem was.
Don't know what's with TAR, but if it comes for ZIP, it's a known issue: https://bugs.launchpad.net/ubuntu/+sour ... bug/203609.

Apparently there's a newer unzip source (beta), with which you can choose encoding.
I built it with that option enabled and it seems to work:

Code: Select all

# UNZIP='-O shift-jis' ./unzip aaa解凍すると文字化けするかも.zip 
Archive:  aaa解凍すると文字化けするかも.zip
 extracting: 解凍すると文字化けするかも.txt  
#

as opposed to:

Code: Select all

# unzip aaa解凍すると文字化けするかも.zip 
Archive:  aaa解凍すると文字化けするかも.zip
 extracting: ???????????????+??????????.txt
#

The attached is 32bit, static unzip-610b.
Unpack it and try if it works for you, too, and if so, put it in /usr/local/apps/UExtract/resources/.
And revert the change you made previously (unzip -> 7zz).

Then you need to invoke UExtract with this env variable set:

Code: Select all

export UNZIP='-O shift-jis'

You can add it in /etc/profile.d/ or directly in /usr/local/apps/UExtract/uextract, just like UEXTRACT_TERM.

Greetings!

Thanks! But after downloading yours, directly use unzip aaa解凍すると文字化けするかも.zip, there will still be garbled characters when unzipping, which refers to the zip file sent by others, and the zip file compressed by yourself will not have garbled characters when unzipped.

Can't UExtract decompress encrypted files? Can't enter the password when it appears? Is it normal for you?

linuxunix wrote: ↑Wed Nov 10, 2021 2:55 am

Can't UExtract decompress encrypted files?

It can. At least it's supposed to (for the supported formats).

Can't enter the password when it appears?

I can. Sometimes it's echoed and sometimes it's not, depends on the backend utility.

Is it normal for you?

It is.

Greetings!

JakeSFR wrote: ↑Wed Nov 10, 2021 2:44 pm

linuxunix wrote: ↑Wed Nov 10, 2021 2:55 am

Can't UExtract decompress encrypted files?

It can. At least it's supposed to (for the supported formats).

Can't enter the password when it appears?

I can. Sometimes it's echoed and sometimes it's not, depends on the backend utility.

Is it normal for you?

It is.

Greetings!

The encrypted file of 7z is used to open it and it is stuck directly, and can no longer be used. It can only be used after restarting the system. How to open 7z encrypted files with it? It is the 7zz of the official website where I installed 7z. How can I directly call 7zz to open 7z files? It would be better if there is an interface to choose which suffix compressed file to open with which corresponding program.

linuxunix wrote: ↑Thu Dec 09, 2021 12:23 am

The encrypted file of 7z is used to open it and it is stuck directly, and can no longer be used. It can only be used after restarting the system.

What do you mean by that? How it's stuck and how it cannot be used until after reboot?

Can you post a sample 7z archive that causes the problem (whatever the problem is)?

How to open 7z encrypted files with it? It is the 7zz of the official website where I installed 7z. How can I directly call 7zz to open 7z files?

7zz x archive.7z

(7zz must be in $PATH, e.g. /usr/bin/)

It would be better if there is an interface to choose which suffix compressed file to open with which corresponding program.

In the vast majority of cases there's only one (or two, e.g. xz is used when unxz is not available; but unxz is usually a symlink to xz) corresponding program for a given extension.

In case of 7z, UExtract chooses the best available one in this order 7z->7za->7zr->7zz.
In case of DEB/RPM archives, it tries all available backends that are capable of extracting them, until it succeeds or runs out of backends.

But it's more complicated than that, because you can have two (or more) files having the same extension, but being created by completely different programs - .egg, for example, can be either Python's Package (which can be extracted by unzip or 7z) or ALZip Archive (which can be extracted by unegg utility).

The bottom line is, I don't see any real gain in exposing that choice to the end-user.
The whole point of UExtract is to make the extraction process as quick and automated as possible.

Greetings!

.

.
.
In Rox file manager.
If you right click on a compressed file and choose UExtract.
One thing I would like to see in this UExtract window that pops up.

A info statement:
If you choose nothing and click the OK button.
A directory(folder) will be made in the same location of the compressed package file.
This directory will contain the uncompressed files that are in it.
The directory will have same name as the original compressed package file, with ".extracted" added to end of name.
Example:
gparted-1.3.1.tar.gz ->compressed package file
gparted-1.3.1.tar.gz.extracted ->directory(folder) made containing the uncompressed files.

bigpup wrote: ↑Thu Dec 09, 2021 3:50 pm

A info statement:
If you choose nothing and click the OK button.
A directory(folder) will be made in the same location of the compressed package file.
This directory will contain the uncompressed files that are in it.
The directory will have same name as the original compressed package file, with ".extracted" added to end of name.

Hmm, I think it becomes pretty obvious after the first use.
I've never seen an archive manager or extractor that would explain such basic things in such a great detail.
I mean, that's how they all work (with some nuances) and UExtract is not much different.

Greetings!

Hmm, I think it becomes pretty obvious after the first use.

I agree, if you ever just click on OK, when you get to this window.
What on that window, tells someone to just click on OK, and a directory to contain extracted files, will automatically be made?

That auto-making of a directory(folder), is one feature I like about UExtract.

You would be surprised how many people do not know this.

XArchive does not automatically make a directory to put extracted stuff in.
You have to manually make it and select to use what you made.
If the compressed file is in /root/downloads/
I tell it to extract contents.
What pops up for location is /root/downloads/
If I do not manually make a directory and choose to use it.
Clicking OK will put all the files in /root/downloads/