Zip/unzip command about duckscript

[sagiegurari]

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?

[Red-Teapot]

• 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.

[sagiegurari]

• 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)

[sagiegurari]

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

[Red-Teapot]

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

[sagiegurari]

thanks. no rush.