uip-tool

[sqward]

I don't know what you mean by "URL list" - it is a thing? I don't know HTML very well...

BTW. you can do much more with commandline. Readme on bitbucket lists the "API". It allows you to upload and run files remotely. I use it for demo coding. This is in fact the primary reason I created this tool. HTML interface was just an add-on for people.

[simonsunnyboy]

A simple textfile would do, no HTML required.
Just a list of all files in the directory with complete URLs.
Imagine browsing the directory as shown in my screenshot here:

uiptool-example.png

The textfile would contain line by line URLs like these:

Code: Select all

http://192.168.0.200/d/BACKUP/F030GAME.ZIP
http://192.168.0.200/d/BACKUP/DEMOS.ZIP


So there would only be a button or another link providing this list for download.

[sqward]

And then what would you do with that list? Can browsers interpret that and batch download a directory?

[simonsunnyboy]

Not browsers but a small shell script or Python script would do for me.
But I can also imagine that there are browser extensions out there that can scan lists for bulk downloading.
(I am normally not a leecher so I don't have much experience with such tools)

Jdownlaoder seems to have options to import selected lists of URLs.

[simonsunnyboy]

As I ran into network problems and had to manually restart uIPTool from time to time, I wrote a small utility that allows to tweak the AUTO boot sequence to run uiptool either once or in a repeating fashion.

In the latter mode, the tool is restarted after crashing or undesired termination (e.q. I accidentally hit SPACE on the Falcon keyboard and the tool stopped amidst in a 50MB download)

At GitHub: https://github.com/simonsunnyboy/startuip

[sqward]

Going back to your URL list problem, why don't you use the existing directory listings in JSON format?

[simonsunnyboy]

It is not a format of choice

Outside of the web world, it is a PITA to parse from what I have tasted. My company implemented a JSON parser in C for an embedded project and the guys invovled were not very happy.

But I can try if I can isolate the interesting information with some grep action in the case of uip-tool as the power on the shell is larger.

[sqward]

you've mentioned Python script first so JSON shouldn't be a problem there

[Moulinaie]

Hi Sqward !
Very useful tool.
I used it on my MegaSTE to upload many files. No problem at all.
Just hoping that "drag and drop" could be in both directions, from the ST to the PC to make backups.

Great job,
Guillaume.

[sqward]

It's not possible (to my knowledge) to implement universally comaptibile (across all browsers) download of multiple files with one user action.

[Moulinaie]

It's not possible (to my knowledge) to implement universally comaptibile (across all browsers) download of multiple files with one user action.

I just compress a whole partition on the MSTE into a single LZH file that I can download easely then.
Fortunately, I have a spare partition on the Atari side that can store the LZH.

Guillaume.

[simonsunnyboy]

I tried packing my stuffs with ST-Zip and it took a loong time even with compression deactivated.
Not to mention STZip crashed for me with weird Mint kernel messages, I think directory recursion didn't do it any good.

But basically that is the way to go, bundle stuff in container files and transfer only the containers with uip-tool.

[jonord]

I tried packing my stuffs with ST-Zip and it took a loong time even with compression deactivated.
Not to mention STZip crashed for me with weird Mint kernel messages, I think directory recursion didn't do it any good.

But basically that is the way to go, bundle stuff in container files and transfer only the containers with uip-tool.

But if you run mint, why not use tar to make an archive? Or some variant of gzip?

[sqward]

Just to be sure: uiptool is not meant to run under MiNT.

[simonsunnyboy]

Just to be sure: uiptool is not meant to run under MiNT.

Yes but packing the stuffs for transfer was done under it.

Regarding tar, the antique versions of tar available for MinT refused to pack directories for me.
As I am not using any unixoid file systems, just plain old FAT, it might matter, it is a VanillaMint look-alike.

The versions of tar I tried all crashed when trying to simply tar an directory like I'D do under Linux (no packing with gzip or anything)

tar cvf backup.tar some_dir

Under Linux this will recurse and process fine, with FreeMint and FAT filesystem I got error messages that it wouldn't access the directory given.

I got tired of looking for suitable tar versions so i simply used something that worked.

[Moulinaie]

I tried packing my stuffs with ST-Zip and it took a loong time even with compression deactivated.
Not to mention STZip crashed for me with weird Mint kernel messages, I think directory recursion didn't do it any good.

But basically that is the way to go, bundle stuff in container files and transfer only the containers with uip-tool.

If I remember well, ST ZIP crashes when managing empty directories...

Is it the reason?

Guillaume.

[simonsunnyboy]

I tried packing my stuffs with ST-Zip and it took a loong time even with compression deactivated.
Not to mention STZip crashed for me with weird Mint kernel messages, I think directory recursion didn't do it any good.

But basically that is the way to go, bundle stuff in container files and transfer only the containers with uip-tool.

If I remember well, ST ZIP crashes when managing empty directories...

Is it the reason?

Guillaume.

IIRC I have no completely empty directories. It was more than resource allocation overload for recursion. It was GEMDOS related someway.