You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be awesome if bucket owners / collaborators could have new bin for checking / recalculating hashes for manifest.
It's really pain to download each binary manually and run something like: Get-hash ... .ToLower() | clip for each file.
There are bins which are really handy (checkver, ...) and are easily transferable into other buckets.
Could you add new lib inside scoop for hashes check?. Basically it would download all urls for each architecture, calculate hashes and edit file (like checkver do with: checkver <App> -u)
If there is already option please let me know.
PS: Why to use resolve-path (split-path (split-path (scoop which scoop))) in:
You can run .\bin\checkver.ps1 * -u (or -f) from your local clone. This will download all files and updates hash values (if URLs and checkver are still correct).
scoop prefix wasn't available when I wrote that script. 😁 Good catch!
checkver -f is working when manifest have autoupdate, but its not suitable for manifest without autoupdate property (some vendors use file server structure base on year and month, not version named files).
Sure you can just copy all files into autoupdate property, run checkver -f, and remove autoupdate, but custom bin would save some time.
It would be awesome if bucket owners / collaborators could have new bin for checking / recalculating hashes for manifest.
It's really pain to download each binary manually and run something like:
Get-hash ... .ToLower() | clip
for each file.There are bins which are really handy (checkver, ...) and are easily transferable into other buckets.
Could you add new lib inside scoop for hashes check?. Basically it would download all urls for each architecture, calculate hashes and edit file (like checkver do with:
checkver <App> -u
)If there is already option please let me know.
PS: Why to use
resolve-path (split-path (split-path (scoop which scoop)))
in:https://github.com/lukesampson/scoop-extras/blob/7112051787c42b27de906803acfbc2cf3bba86c0/bin/checkver.ps1#L1
(and other bins) when you can use
resolve-path (scoop prefix scoop)
?The text was updated successfully, but these errors were encountered: