duckscript

duckscript copied to clipboard

Feature Description

I'd like to have commands to pack/unpack ZIP archives.

I believe the ZIP format is supported nearly by everything and it would be a nice utility.

Describe The Solution You'd Like

The exact design of these commands and the default mode of operation might need discussion. The implementation probably can be based on the zip crate.

Some things to consider:

• Compression modes (perhaps deflate would be a decent default).
• File paths (especially when making an archive: the file path inside an archive doesn't have to match the real path of the file being added). I think we have two options: either packing the files in a directory, making that directory the base for all in-archive file paths, or allowing the user to provide a map of real paths to the in-archive ones.

Not sure whether it should cover all possible cases as that would complicate the usage by a fair bit. Based on that, my proposal is following:

zip <archive name> <base dir path>

This command would add all the files and folders in the provided base directory, and their paths in the archive would be basically relative to the base directory.

As for unpacking, it's far easier:

unzip <archive name> <dir>

That would unpack the archive in the given directory, creating it if necessary. If some files already exist in there, the command should probably fail with an error.

makes sense. I would love to be as close (not a must) as possible to the linux zip command. that means for example supporting

• multiple paths zip target source1 source2 ....
• providing compression level in cli (optional) with -number param + alternate more readable flag (like --level 3) + default if not provided
• recursive flag? or should we have this by default? since... why not?
• what about glob support?
• for unzip, if target is not provided, its current dir (but i don't think we need the -d, lets use your solution of just second arg)
• file path/basedir - i think the base dir by default is based on input, so if someone put zip target ./dir1/dir2/dir3 the output would have dir1/dir2/dir3. and to change that, user can define base dir (--base <whatever>) and that will take for all source paths provided (otherwise its just really long and messy) So to support difference base paths to different source paths, lets also support amend? (original -u flag and lets add more readable --append flag as alternate)

wdyt?

• Multiple paths: yes, why not
• Compression level: from what I can see, the zip crate I mentioned does not support compression levels. Just two algorithms: bzip2 and deflate.
• Recursive: I think it should be recursive by default. Honesly I don't what use case for a non-recursive invocation would be. If there is actually a use case for that, we can make it opt-out.
• Globbing: On one hand, there is GlobArray. On the other, some commands (CPGlob, SetModeGlob) have globbing. I'd go for zip without globbing (if there are no limitations on the number/length of arguments) but that is not very consistent with the commands I mentioned.
• Unzip target: Ok
• Basedir: Ok
• Amend/append: Ok

Although I'm not sure whether the logic for CLI-like argument parsing is implemented for Duckscript commands (I mean, the arguments can be reordered so that requires a bit of handling).

Also, given that Duckscript has maps, these could help with that file path thing (for example, we could accept a map from the real paths to the paths in the archive). It deviates from the Linux command though.

• compression - ok, so lets expose those as options (--type default/bzip2)
• recursive - ya exactly. thats why i'm for recursive by default and i was wondering if i'm missing out something
• glob - lets start without glob (starting small) and later we will rethink this
• parsing cli args - look at this example - https://github.com/sagiegurari/duckscript/blob/master/duckscript_sdk/src/sdk/std/net/http_client/mod.rs#L40
• maps - cool idea. i'm not a fanatic to follow linux guidelines. i try when i can to make it easier for people to use these commands, but its not a must at all. i think map is a nice idea and can be added as well (--path-map ${handle} i guess)

@Red-Teapot would you like to PR this one or prefer me to do it?

I think I can make the PR. However, that might take a while since I don't have much free time.

thanks. no rush.