Add internal command to calculate appcast checkpoint.

[reitermarkus]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew tests with your changes locally?

---

@vitorgalvao, I think (finally) implementing this is better than adding yet another workaround (tr "\n").

Closes Homebrew/homebrew-cask#24811, Homebrew/homebrew-cask#28966 and #1876.

[vitorgalvao]

I’d say these can be removed. If this exists to give the same result the non-internal command does, but the non-internal command will ceased to be used in favour of this internal one, then there’s nothing to replicate. This will be the canonical and only recommended way to do it.

[reitermarkus]

I just thought I'd leave this in for now as to not mess up existing values. But I guess this doesn't make any difference since they aren't officially used for anything yet.

[vitorgalvao]

Just noticed it also needs the delete("\n") step before gsub.

There’s no harm in messing with current values, since those will be outdated anyway, for missing the delete step.

[reitermarkus]

Isn't delete("\n") only needed because sed only handles one line at a time? Do we need it then, when we aren't going to use sed anymore?

[vitorgalvao]

The problem is that some casks have <pubDate> and </pubDate> on different lines, so it doesn’t actually get removed. By removing all newlines, we make sure <pubDate>[^<]*</pubDate> always works.

I guess we can just setup the regex to work multi-line, yes.

[reitermarkus]

Ah, right, I forgot gsub still needs the m option to be multi-line.

[vitorgalvao]

Might it be worth adding mandatory flags to this? Something like --calculate and --print (gives the current one)?

[vitorgalvao]

@reitermarkus Instead of adding mandatory flags, it seemed sensible to make it just print the current appcast when no flags given, or calculate it when given --calculate.

Was going to submit it as a PR to your fork, but GitHub was erroring and not cooperating, so it was easier to add the commit directly: 949d3de.

Looks good to me as is, unless you want to change something/disagree.

[vitorgalvao]

While editing the documentation, just recalled something else. We can’t just take casks as arguments, we also need to take URLs (so users can calculate it the first time, when building the cask).

[reitermarkus]

Does cask_tokens_from(args) not work here, or was this overlooked?

[vitorgalvao]

It was overlooked. It does indeed work, but I was basing myself on _stanza and didn’t even notice. Will fix it and add to #1896 as well.

[vitorgalvao]

This will work the same both with or without --calculate. Just pointing it out in case you intended to do it any other way. It’s fine by me as it is since the only sensical thing to do with a URL is calculate, anyway.

[reitermarkus]

the only sensical thing to do with a URL is calculate

Exactly, you can't not calculate it.

[vitorgalvao]

We should add a note about it working on URLs as well.

[reitermarkus]

Let's maybe add this to the man page instead, otherwise the line is getting kinda long.

[reitermarkus]

@vitorgalvao, I added a manpage entry and shortened the help text a bit.

[vitorgalvao]

I’d say it’s ready to merge as soon as all checks pass.

[toonetown]

So - does this use a different method of calculating the hash of the app cast? For example, if I run (after updating)

$ brew cask _appcast_checkpoint marked
caf003f39ca2a87922e2d1f6afe17df55bd6bb6f36dcfd16b52e257cf629f5e0
$ brew cask _appcast_checkpoint --calculate marked
f315ff8dfb5cbd0e1da1ef302c6edbcb738d083237ebc4b977e78a1c6ce97fd3

However - the hash (using cURL) was previously calculated thusly:

$ curl --compressed --location --user-agent 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36' "https://updates.marked2app.com/marked.xml" | /usr/bin/sed 's|<pubDate>[^<]*</pubDate>||g' | shasum --algorithm 256
caf003f39ca2a87922e2d1f6afe17df55bd6bb6f36dcfd16b52e257cf629f5e0

Which is the current (in the cask file) hash. I'm fine if the internal call changes the way that the hash is calculated - but is there a separate task to update all current casks with their new hashes?

[vitorgalvao]

does this use a different method of calculating the hash of the app cast?

Yes. The change was necessary anyway as the old method wasn’t reliable on all cases.

is there a separate task to update all current casks with their new hashes?

No. That is unnecessary. Only now that this is finalised will I start working on remaking the scripts to fix casks based on appcast checkpoints. Those will end up being fixed organically.