Uextract - How to use password? (SOLVED)

[enrique]

I love Uextract. But I need help. I wonder if I can tell Uextract to use a password for extracting. At the moment I want to extract passworded rar. But I guess it may apply to other?

Thanks in advance.

[Semme]

Enrique, it's how you PackIt that determines whether a passwd is requested or not.

Unable to get your pkg to prompt for a passwd? ThistleWeb's comment may well be true:

There's also a difference between varieties or rar file. It's an ever changing format that targets paid archive Winrar on Windows. There is a free and non-free version of unrar in the repos. The non-free one includes more formats that it can read and uncompress. There may be times where the file has been created in the latest version of Winrar and no Linux unrar will recognize it yet. Those could show themselves in silly things like not prompting for a password.

Determine this and you still have one more option: try the latest build.

Bionic repos supply: [RAR v5.50 / 11 Aug 2017].

Code: Select all

RAR 5.90   Copyright (c) 1993-2020 Alexander Roshal   26 Mar 2020
Trial version             Type 'rar -?' for help

Usage:     rar <command> -<switch 1> -<switch N> <archive> <files...>
               <@listfiles...> <path_to_extract\>

[enrique]

Semme

WAOooo I feel s7upid....

See this is same answer as in "Can you make a RAID-1 setup with a HDD and USB stick?" Where talboy and Mike Walsh comment something like "everytime... once a day...once a month... I do not do it anymore."

Yes answer is I got lazy.. I stop testing problems and comparing results in different versions of Puppys. In general I been sick, well really getting old and doing only 1% of I was doing a few month ago.

So I been running on BusterDog. I have UExtract v3.30 by SFR'2013-2017; And for whatever reason Uextract will close on any terminal output/request or will shrink the windows if it opens. As result I never got to see any terminal query. As a matter of fact I do have some other issue that make it failed the very first time.

I have not figure out yet the final solution. But now that I know the problem I have see I can mitigate the problem by going into /usr/share/applications/Uextract.desktop and changing to Terminal=true originals was false. Now I can see the password request most of the time. And I can see I need to find out if it got anything to be with

(gtkdialog4:10133): GLib-GObject-WARNING **: 00:19:06.330: g_object_get_is_valid_property: object class 'VteTerminal' has no property named 'inner-border'

(gtkdialog4:10133): Gdk-WARNING **: 00:19:06.343: Native Windows wider or taller than 32767 pixels are not supported

My very thanks to you Semme .

[SFR]

(gtkdialog4:10133): GLib-GObject-WARNING **: 00:19:06.330: g_object_get_is_valid_property: object class 'VteTerminal' has no property named 'inner-border'

(gtkdialog4:10133): Gdk-WARNING **: 00:19:06.343: Native Windows wider or taller than 32767 pixels are not supported

I just checked it in BusterDog-openbox_jwm-2019-12-29_32-bit.iso and there's something wrong with Gtkdialog itself (which is actually gtkwialog-0.8.7).
For some reason this code crashes X (under Openbox) or returns errors and doesn't work (under JWM):

Code: Select all

echo '<terminal><width>83</width></terminal>' | gtkdialog -s

Gtkdialog binary imported from Slacko-5.7 works as expected.

The workaround, until the real problem is fixed, would be to set this environmental variable:

Code: Select all

export UEXTRACT_TERM=roxterm

so UExtract will be using a "real" terminal instead of Gtkdialog's VTE.
You can set it in, for example, /etc/profile.d/uextract.sh and reboot.

HTH
Greetings!

[Semme]

That was QUICK, SFR mate. You'd make one hell of a gun-slinger! :D

[enrique]

I love this forum and its people.
We have a problem, we post the request, and here we go there is always good people that make us happy. Try that on Microsoft Support sites.

SFR thanks for Uextract. I love its simplistic. It is like point & shoot. Now I am not complaining on any of the product ( Uextract or BusterDog ). I do understand that having the basic Dog OS require extra attention to missing libs. I open this tread because I was fool by the behaviors as I never saw the window requesting the password.

Regards my Dog. I have BusterDog-openbox_jwm-2019-12-29_64-bit.iso. But instead I am a proud user of fredx181's mklive-buster. See God invented colors for us to decide what we like. I am the type of user that love to start from an empty template and build form there. Some time I think I am like Autistic. All those so many programs on the Menu drive me nuts. Then I see my CPU going UP and Down, then the Net use and at that point I have to explode. That is why I use mklive-buster. And My Laptop is never over 2-4% of CPU use, Always cool, network use close to 0%.

With mklive-buster I end up with Openbox and no roxterm. I guess is lxterminal instead. I have also uxterm and xterm. Thanks in advance.

[enrique]

YESSSSS!

export UEXTRACT_TERM=xterm

or

export UEXTRACT_TERM=lxterminal

set it in /etc/profile.d/uextract.sh and reboot.

It does the trick nicely for Uextract. THANK YOU.

Now I guess I have to search this gtkdialog terminal thing as I expect this issue could affect other script that uses gtkdialog.

[Semme]

Enrique mate, don't waste your time searching any gtk-dialog terminal thingy. Leave this stuff to the maintainers.

[enrique]

I know.
But I do not consider it a waist of time as I do learn with it. And this is not good as any script that uses gtkdialog can in fact fail and close half way. This can even leave data corrupted. gtkdialog is used on many default system script!

If I have to guess, is like default terminal dimensions from lxterminal are not correctly read.

It seems that when windows just fail the error is then

echo '<terminal><width>83</width></terminal>' | gtkdialog -s

(gtkdialog:30967): GLib-GObject-WARNING **: 19:25:29.284: g_object_get_is_valid_property: object class 'VteTerminal' has no property named 'inner-border'

(gtkdialog:30967): Gdk-WARNING **: 19:25:29.294: Native Windows wider or taller than 32767 pixels are not supported
The program 'gtkdialog' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
(Details: serial 255 error_code 11 request_code 53 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)

[fredx181]

I just checked it in BusterDog-openbox_jwm-2019-12-29_32-bit.iso and there's something wrong with Gtkdialog itself (which is actually gtkwialog-0.8.7).
For some reason this code crashes X (under Openbox) or returns errors and doesn't work (under JWM):

Yes, just noticed this thread (and enrique PM'd me about this issue), it's indeed a bug in gtkwialog, should be fixed or, if it cannot, I'll revert back to original gtkdialog for Busterdog, thanks.

Fred

[wiak]

(gtkdialog4:10133): Gdk-WARNING **: 00:19:06.343: Native Windows wider or taller than 32767 pixels are not supported

I just checked it in BusterDog-openbox_jwm-2019-12-29_32-bit.iso and there's something wrong with Gtkdialog itself (which is actually gtkwialog-0.8.7).
For some reason this code crashes X (under Openbox) or returns errors and doesn't work (under JWM):

Code: Select all

echo '<terminal><width>83</width></terminal>' | gtkdialog -s

Gtkdialog binary imported from Slacko-5.7 works as expected.

I've taken a quick look. Same widget_terminal.c source code in gtkwialog and in 01micko's github gtkdialog.

I cloned 01micko's github gtkdialog onto my XenialDog64 (openbox WM) system. Installed libvte-dev and libglade2-dev and compiled gtkdialog (which is 0.8.4) and obtained same error result using that gtkdialog as shown below:

Code: Select all

root@xenial64:/mnt/live/mnt/sda1# gtkdialog --version
gtkdialog version 0.8.4 release (C) 2003-2007 Laszlo Pere, 2011-2012 Thunor
Built with support for: GTK+ 2, Glade, VTE.
root@xenial64:/mnt/live/mnt/sda1# echo '<terminal><width>83</width></terminal>' | gtkdialog -s

(gtkdialog:28186): GLib-GObject-WARNING **: g_object_get_valist: object class 'VteTerminal' has no property named 'inner-border'

(gtkdialog:28186): Gdk-WARNING **: Native Windows wider or taller than 32767 pixels are not supported
The program 'gtkdialog' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 286 error_code 11 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
root@xenial64:/mnt/live/mnt/sda1#

Perhaps Slacko's gtkdialog was compiled with a particular (working version of libvte); that's all I can think of, assuming the github resource of 01micko is up-to-date, which I imagine it is. I didn't see any special compile instructions for VTE support, but perhaps I have missed them? If someone can enlighten me how to compile Puppy's gtkdialog to work with VTE then I can probably do exactly the same with gtkwialog. I know nothing about VTE so could only guess that having libvte-dev installed should be enough, but clearly something else is required in the procedure.

Many thanks in advance for clear instructions to compile Puppy's 01micko's gtkdialog to work - then I'll try same compile for gtkwialog. I don't think it is a src code error in gtkwialog since my Puppy gtkdialog compile clearly not working for me either, and I'm too rusty on this to determine what might be wrong via debugging. It's probably just some compile time option that indicates wish to link to libvte and I have simply missed it. All I noticed, from README, was:

VTE
---
Gtkdialog's configure script will compile-in support for the Virtual
Terminal Emulator if it finds libvte and its development headers.
libvte source package -> http://ftp.gnome.org/pub/GNOME/sources/vte/

So I'm wondering if I need to use a very old version of libvte sources (0.9x maybe?) or perhaps my dev environment needs some extra vte dev dependencies? In the meantime I'll try compiling it in latest Slacko with its devx since that presumable has all deps for vte support required.

EDIT: I've since installed old Slacko 5.4 and downloaded the devx and used the git clone I made of Puppy's github gtkdialog and compiled from there. The gtkdialog in Slacko 5.4 works fine. The one I compile crashes X. No idea how to compile in vte so it works without crashing I'm afraid - I guess somebody does. Any help appreciated (step by step). That's standard Puppy gtkdialog source code I'm; gtkwialog forked from that so if I can't compile vte to work correctly with standard gtkdialog, my compile will obviously not work with gtkwialog either for anyone who needs that.

Posting this from Slacko 5.4. Nice old Puppy distro.

wiak

[SFR]

Yes, turns out that the actual culprit is in Mick's fork (which, I assume, was used a base for Gtkwialog?), in this PR:
https://github.com/01micko/gtkdialog/pull/82

Reverting this particular change fixes VTE terminal in GTK2 build:

Code: Select all

- #if 0 //#if VTE_CHECK_VERSION(0,26,0)
+ #if VTE_CHECK_VERSION(0,26,0)

but I think it might be better to revert the whole commit, just in case.

Greetings!

[wiak]

Yes, turns out that the actual culprit is in Mick's fork (which, I assume, was used a base for Gtkwialog?), in this PR:
https://github.com/01micko/gtkdialog/pull/82

Reverting this particular change fixes VTE terminal in GTK2 build:

Code: Select all

- #if 0 //#if VTE_CHECK_VERSION(0,26,0)
+ #if VTE_CHECK_VERSION(0,26,0)

but I think it might be better to revert the whole commit, just in case.

Greetings!

Thanks, SFR, mystery solved.

wiak

[enrique]

I did not know how I did not notice you where posting. Sorry.

Again I do really LOVE Puppy and all its master builders. See you can not find this kind of support in MS-websites.

My very BIG THANKS to ALL of you guys. Great job. I have not tested but I know it should work. So will be downloading the updates.

[woodenshoe-wi]

@SFR and @wiak

I changed automaton.c to stop using the 'inner-border' property, and 01micko merged it, so if you could try again and see if it is fixed or not please.

I didn’t think the 'inner-border' property was removed until the version of vte used for gtk+3, so I am puzzled that it would be causing problems in a gtk+2 build. Maybe the code for using the 'inner-border' property was buggy? I reused some of it for gtk+3 VTE support...

You shouldn’t have to do anything special to enable VTE support for a gtk+2 build. If you want to enable VTE support in a gtk+3 build, you will need to install the gtk+3 version of libvte, which is known to pkg-config as vte-2.91, and set some environment variables to make it use the gtk+3 version instead of the gtk+2 version.

Code: Select all

export VTE_CFLAGS=`pkg-config --cflags "vte-2.91"`
export VTE_LIBS=`pkg-config --libs "vte-2.91"`

Then you should have VTE support when you configure gtkdialog with --enable-gtk3

[SFR]

@SFR and @wiak

I changed automaton.c to stop using the 'inner-border' property, and 01micko merged it, so if you could try again and see if it is fixed or not please.

I didn’t think the 'inner-border' property was removed until the version of vte used for gtk+3, so I am puzzled that it would be causing problems in a gtk+2 build. Maybe the code for using the 'inner-border' property was buggy? I reused some of it for gtk+3 VTE support...

You shouldn’t have to do anything special to enable VTE support for a gtk+2 build. If you want to enable VTE support in a gtk+3 build, you will need to install the gtk+3 version of libvte, which is known to pkg-config as vte-2.91, and set some environment variables to make it use the gtk+3 version instead of the gtk+2 version.

Code: Select all

export VTE_CFLAGS=`pkg-config --cflags "vte-2.91"`
export VTE_LIBS=`pkg-config --libs "vte-2.91"`

Then you should have VTE support when you configure gtkdialog with --enable-gtk3

Ok, I just tried both GTK+2 & 3 (vte-0.29.1) builds and the terminal widget doesn't crash anymore.
Thanks for the fix!

Greetings!

[woodenshoe-wi]

That’s good to know.

Thanks for testing!

[wiak]

Thanks.

I haven't tried compiling for Gtk+ 3 at all yet, so I'm fine for now having simply using the deprecated vte_terminal_get_padding() i.e. reverting earlier patch for Gtk +2 use.

However, I will endeavour to get round to trying your patch of using gtk_style_context_get_padding() for the Gtk +3 vte-2.91 case.

Interesting was the comment in original code:

/* VTE is telling me that vte_terminal_get_padding() has been
* deprecated since 0.26 and that I should get 'inner-border'
* but GLib is telling me that 'VteTerminal' has no property
* named 'inner-border' so I have to go with the deprecated
* vte_terminal_get_padding() */

I haven't tried the following either, but I felt that the following might be wrong (in previous: if VTE_CHECK_VERSION(0,26,0)):

Code: Select all

GtkBorder inner_border
...
g_object_get(G_OBJECT(widget), "inner-border", &inner_border, NULL);

and planned to try instead something like (note especially use instead: inner_border as a 'pointer' to GtkBorder):

Code: Select all

GtkBorder *inner_border
...
gtk_widget_style_get (widget, "inner-border", &inner_border, NULL);
...
gtk_border_free (inner_border);

I'll maybe look into it all further myself later.

wiak

[enrique]

Just for reference, the original fix you did on may 30 work for me for the last 7 days. I did update thru fredx181's gtkdialog_0.8.9-wiak-B-1. As always Thanks.

[woodenshoe-wi]

...
and planned to try instead something like (note especially use instead: inner_border as a 'pointer' to GtkBorder):

Code: Select all

GtkBorder *inner_border
...
gtk_widget_style_get (widget, "inner-border", &inner_border, NULL);
...
gtk_border_free (inner_border);

I'll maybe look into it all further myself later.

wiak

I don’t know if it is worth trying to get "inner-border" working, because right after the deprecated vte_terminal_get_padding() was removed, "inner-border" was removed too.

See https://gitlab.gnome.org/GNOME/vte/-/co ... cf9c40cddf