But the bad thing is that 'ar' is not in the main .sfs, only in the devx, so I hesitate to give it more scope.
And that's why I use 7z (but only if ar's not there) also for *.a and *.ar.

Quote:

I still want to look at your code -although I think you've gone overboard, by now, with what the thing should do -ripping/decoding video/audio would be more appropriate for other tools -IMO.

TBH, I too feel it's extravagance, but seeking and adding new formats was (I think there's not much left to be added, what could work OOTB in Slacko) like a drug - I couldn't stop myself.
BTW, it only do extract streams from within a container, not (en|de)codes them.

I'll just attach a copy of my AppDir since it is small -just a couple of scripts in there(disrpm is unused but left to rest there...)

You won't be able to use the AppDir, though, unless you have Xdialog, gtk-shell and greq all installed -I was fiddling around with vearious UI builders...

Still, you may be able to glean some ideas from it. I've been threaening to re-write it for years, but I use it more than any other 'utility' application on my system.

Another thing I rather dislike is including binaries in an AppDir without the sources. Mine is simply a wrapper for tools which should be available. One really should check to see if the decompressor is available or warn and quit. And, checking the file-type could be done another way -I check archives using 'file' instead of relying on the file suffix.

Thank you! I like how it looks & works. Very nice.
Xdialog is OOTB in most (all?) of Puppies these days and it seems that only greq is necessary - couldn't find any reference to 'get_dest_dir()', where gtk-shell is used.
I attached .pet of greq if anyone would also like to play with it.

Here is the .deb I tested. Of course I should have tested several of them.
Pure Ubuntu Raring repositories .debs seems to extract both control files and the package installable content. Which is great. I do like that I can check the control files included postinst script commands and the control file dependencies list.

The "+tr" will override any transparency which may have been set in .urxvtrc,
the "-bg black" will accentuate the contrast and finally the "-rv" will produce a very readable listing on whitish background. (Please see picture.)

It's just a suggestion of course.

As to the "_extracted" ending added the extracted folder, I find it quite ugly,
but it is obviously safer! The user can always remove the ending if necessary.

"_extracted" I meant to comment about this, as I don't like the idea either. Archives should usually extract to their natural name -that is, the name of the archive minus the suffix(es). However, this is not always the case -even with archives like tar which can tell you if there is a toplevel dir.

In my src2pkg program, I go to great lengths to avoid 'tar bombs' being unpacked without a toplevel dir. Surely you've all had the experience of opening a (usually) *.zip archive and having ti spread lots of files into the current directory. Really messy if you happen to do that where there are already lots of files.
The solution is to create the directory arbitrariy and cd in there to unpack the archive. But, then you have to figure out if there already was a 'topdir' in the archive, and if so, then cd in there and move everything up one level, back out and remove that dir. It really is messy. The alternative is to list the archive beforehand and try to figure out if it has a topdir -again messy because of the difficulty of listing and variance in the output for various archive types. This is one of the reasons I have never re-written ZipZap because a *really* sane needs better intermediate functionality -which is easier to implement before adding support for a bunch of archive types.

I also like seeing the control files in *.deb archives, so my tools usually unpack them.

My AppDir does illustrate a more featureful use of AppDirs. The RISC environement was drag-n-drop oriented and with a view from the users HOME dir. The idea was, the user knows where his files are (in HOME) and usually is running things from there. So, instead of having the user start an application and then use it's file-selector to browse to his HOME dir, find the file and open it -instead, the user simply grabs the file in question and drops into the app that he wants to open it with.

On my system, I only have left-click actions set for a couple of different file types. Since one doesn't always want to do the same thing with a file: for instance, an *.html file, I drop it onto an html editor icon or a browser icon according to what I want to do. Of course, there are options like SendTo, etc., which achieve a similar variety of options or using a GUI tool which provides the options when left-clicking. Still, if you really want to understand why rox does things differently, you need to look at it from this other perspective.

As far as I know, most of the AppDirs used in Puppy do not take advantage of the extra features of them -like the menu entries which can be created in the AppInfo.xml file.

Well, I don't particularly like it either, but I've chosen it as a necessary evil.
Better than fun with deleting hundreds or thousands junk files out of $HOME.
I, too, was thinking about the way of resolving it in some nicer manner, but it's a pure mess indeed.
Actually, something like this could be quite decent solution:

IF
- destination dir (which is "archive_name" without suffix(es)) contains only one and only a subdir
AND
- destination dir's name is exactly the same as its subdir's name
THEN
- rename subdir to sth rare (in case if inside is also a dir named like that)
- move all stuff from subdir one level up
- delete empty subdir

But what if the destination dir already exists or we're extracting identically named archive.tar, archive.zip, archive.rar and so on, at the same time (remember? - "mass extraction" )?
We'll end up with archive, archive(1), archive(2), which is IMHO even worse than archive.tar_extracted, archive.zip_extracted.
Ahh, I'll leave it alone for now...
_____________

The "+tr" will override any transparency which may have been set in .urxvtrc,
the "-bg black" will accentuate the contrast and finally the "-rv" will produce a very readable listing on whitish background. (Please see picture.)

Unfortunately this would break compatibility with other terminal emulators than urxvt, e.g. rxvt (won't accept e.g. '+/-tr' parameter) and others, depending which one gets called by xterm.
I tried to:

Code:

echo -e '\e[30;107m'; clear

but this in turn breaks the output in "real" terminal/console.
_____________

Hmm one thing that occured to me is that on windows 7zip will list content directory by directory.....

On linux the list output includes every file and its path and I see no direct way of achiving the windows like result directly with 7z(a). Searching suggests that a bit of scripting is needed either to produce a tree or folder by folder output. Producing a tree output is covered but not found anything for folder traversal.

One to consider when dealing with an archive with 20,000 files and something I would like to throw at xarchive and it may be beneficial here.

If I am not being clear, opening my 20,000 file archive shows 10 files and 10 top level folders on windows 7zip...I can then browse down the folders or extract as required.

"But what if the destination dir already exists or we're extracting identically named archive.tar" Most extractors will overwrite existing files by default. Some, at least, are configurable from cli options.

"contains only one and only a subdir" & "move all stuff from subdir one level up" This is basically what I do in src2pkg, although most compressors will show us a listing -but it can still be hard to tell if a toplevel is really the top -and top of where? An archive which is an installable package may have no toplevel, but include several subdirs.
Heuristics would suggest that *.zip, *.rar and any formats commonly found on windows machines would be more likely to be a tar 'bomb. It also suggests that archives named like this: *.tar.gz are less likely to be 'tar bomb' than those with names like: *.tgz

@SFR, I had a pretty long look yesterday at your code and I've gotta say it looks pretty good! Very readable -nicely indented, etc.
I did see a couple of rough spots though -I'll post a diff a little later with a fix or two.

I can see the logic in supporting filesytem images, like *.iso and *.sfs files, but I really think you ought to pull the video/audio/pdf stuff out of the tool. An archiver is usually meant to work with groups of archived/compressed files. The audi/video features would go nicely in their own little utility and pdf/other document tools could go elsewhere.

Then you might look at incorporating ideas from ZipZap for handling dropping files/dirs onto the AppDir.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum