Hello everyone, As per the template for filling issues on Github (implies one should not open an issue there), I'm sending this email with a few feature requests that I've collected for the past months.
1) Cross-buildable zsh and fish completions Right now, the only issue we have with cross-building curl on Debian is that we are not shipping the zsh and fish completions. https://github.com/curl/curl/blob/7d934267ab185123e7eaa5e974b61527dbbf14e1/scripts/Makefile.am#L44-L80 This is something that can be addressed on the packaging side with a few workarounds, but we end up just not building/shipping them instead. Note that we never cross-build for our official packages, but we do test support for that and do as much as we can to provide that possibility to our users. 2) curl CLI: allow multiple URLs for "-C/--continue-at - <URL>" (in a single command) When a user wants to download multiple URLs using the "-C,--continue-at -" approach (automatically find out where/how to resume the transfer), it doesn't seems possible to provide more than a single URL. It would be nice to be able to provide multiple URLs in the same command as the user would also be able to ask for the downloads to happen in parallel with "-Z, --parallel". Assuming this combination of parameters would work, otherwise supporting parallel on this usecase would be another feature request. Going even further, allowing the user to also set "-#, --progress-bar" on top of it all would be nice. I do not know how much sense there is in implementing this on the curl CLI, it depends on how you view its goals. I'm requesting this from the POV of the usability for the end user. 3) curl CLI: allow both -C/--continue-at and -J/--remote-header-name to be set It would be nice to have both features enabled at the same time, right now the user gets this: curl: --continue-at and --remote-header-name cannot be combined The end goal would be to allow for the user to also add -O,--remote-name on top of that, making curl try to guess a name using Content-Disposition first, then falling back to the logic of --remote-name (this might be another feature request). Just as FR#2, the importance of this one depends on the goals of the curl CLI, since a user can always create a wrapper that does some back-and-forth and accomplishes this behavior (if they don't want to deal directly with the library, at least). Cheers, -- Samuel Henrique <samueloph> -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
