aria2-remote.sh fails on macOS as its base64 needs argument --break instead of --wrap

[porg]

Bug

Calling aria2-remote.sh (as in commit 9558f62 from 2016-01-26) on macOS 11 Big Sur fails with:

base64: invalid option -- w

• Fails both with
  • base64 as shipped with macOS 11 Big Sur (no --version info, manpage says: 2011-02-08 Mac OS X 10.7)
  • and the newest base64 (v1.5 from 2007-06-10) via brew package manager.

Found a fix

This row:

params_base64enc=$(echo "${params}" | base64 -w 0 -)

Should be replaced like this:

# Please adapt the next code line depending on your OS:
# The name for the needed argument differs between the Mac and the Linux variant of base64:
  # Linux uses: --wrap (short form: -w)
  # macOS (both built-in and brew variant) uses: --break (short form: -b)
params_base64enc=$(echo "${params}" | base64 --wrap 0 -)

• I prefer to put the long argument name there for better instant comprehension also for people not familiar with the tool.
• Also the - as stdin for the base64 infile is not necessary, as it's the default.
  • But nevertheless I think it is good that it's there:
    • Explicitly communicates the intent.
    • And is sort of forward compatible should the default change one day.

[porg]

I emailed Fourmilab Base64 about the different argument wording --break vs. --wrap which causes incompatibilities.

• If the Fourmilab base64 tool which is in use on Unix, FreeBSD, macOS gets the same options like the one used on Linux,
• interoperability would be guaranteed, and bugs like this would disappear.

[derreisende77]

Okay, I do not really get which parameter you want to have included: --wrap or --break? If break and wrap are similar this contradicts your suggested fix. Could you please clarify your preferred solution which will work both on linux and macOS?

[porg]

I reported this half a year ago. Now re-read my report. It's clear. Again in short words:

• base64 's argument names are inconsistent between operating systems.
  • --wrap on Linux and --break on macOS does the same thing
• The ideal fix would be to solve this upstream, and make the base64 utility use consistent arguments on all platforms
  • But its author did not react (or I did not send the email, did not find it now)
• Hence I propose to you to ship your aria-remote.sh with OS specific modifications:
  • --wrap on Linux and --break on macOS

[porg]

Or at least a comment (as mine depicted in the OP) so that users can manually adapt the OS specific parts.

[derreisende77]

Well, at least I responded ;)
aria2-remote.sh is not part of the macOS app bundle but only installed on Linux (as can be seen e.g. from the PSet templates import feature in MV). Therefore there is no need to "fix" something which works for the provided platform.
Where did you get the shell script for the macOS version?

[porg]

Yes 😉 glad we follow up on this now. Back then I made a tutorial complete with annotated screenshots how to:

• Hand downloading over to NAS (completely external download)

I progressed with intermediate solutions until having my intended solution:

1. MediaThekView hands over to NAS which uses parallel curl downloads.

2. Then vitusson gave me the idea to use aria2 in Deamon-Mode on my NAS.

3. I reported success: MediaThekView hands over download request to aria2 download queue running on the NAS.

• I had needed some adaptions on the NAS (OpenMediaVault) and on the client (macOS)
  • For the Mac I downloaded aria2-remote.sh from commit 9558f62 from 2016-01-26:
  • So yes, please feel free to use my well documented learnings for offering this an official import-able macOS script addition. All details are documented there. When I do my scripting/modding I try to document it well, b/c now half a year later I don't recall anything of this tinkering, am just glad that it works in daily use 😉
  • Hope this can help to make this available for some other Mac & NAS/OpenMediaVault users.