Giter Site home page Giter Site logo

domt4 / homebrew-autoupdate Goto Github PK

View Code? Open in Web Editor NEW
968.0 17.0 54.0 384 KB

:tropical_drink: An easy, convenient way to automatically update Homebrew.

License: BSD 2-Clause "Simplified" License

Ruby 99.24% Rich Text Format 0.76%
homebrew homebrew-autoupdate ruby

homebrew-autoupdate's Introduction

Homebrew Autoupdate

An easy, convenient way to automatically update Homebrew.

This script will run brew update in the background once every 24 hours (by default) until explicitly told to stop, utilising launchd.

brew upgrade and brew cleanup can also be handled automatically, but are optional flags.

Notifications are enabled by default using a new, code-signed, universal AppleScript applet.

A comic highlighting humanity's habit of skipping important updates

Installing this command

Just brew tap domt4/autoupdate.

Now run brew autoupdate start [interval] [options] to enable autoupdate.

Example

brew autoupdate start 43200 --upgrade --cleanup --immediate --sudo

This will upgrade all your casks and formulae every 12 hours and on every system boot.
If a sudo password is required for an upgrade, a GUI to enter your password will be displayed.
Also, it will clean up every old version and left-over files.

Casks that have built-in auto-updates enabled by default will not be upgraded.

Usage

Refer to the link below to find an in-depth description of the commands.

Homebrew Documentation autoupdate subcommand

Logs of the performed operations can be found at: ~/Library/Logs/com.github.domt4.homebrew-autoupdate

This vs brew's built-in autoupdate mechanism

This command mostly exists to ensure Homebrew is updated regardless of whether you invoke brew or not, which is the primary difference from the autoupdate mechanism built into brew, the latter requiring a user to explicitly run any of brew install, brew tap or brew upgrade.

If you run brew commands regularly yourself, you may wish to consider using the built-in autoupdate mechanism, which can be instructed to autoupdate less often, or disabled entirely. If you wish to update every 24 hours using the built-in autoupdate mechanism set this in your environment:

export HOMEBREW_AUTO_UPDATE_SECS="86400"

or if you wish to disable the built-in autoupdate mechanism entirely:

export HOMEBREW_NO_AUTO_UPDATE="1"

Please note that Homebrew slightly frowns upon people disabling the built-in autoupdate mechanism.

TO-DO (PRs Welcome)

History

This tap was created by DomT4 in April 2015 to address a personal desire for a background updater, before being moved to the Homebrew organisation in April 2021 to become an official part of the project after gaining somewhat widespread usage, something I'm both surprised by, but also very appreciative of people finding a small tool I wrote so useful & contributing their own ideas and time towards.

It was in late 2023 moved back to DomT4's ownership to reduce the burden on the wider Homebrew leadership team in terms of maintenance/support requests.

License

Code is under the BSD 2 Clause (NetBSD) license.

homebrew-autoupdate's People

Contributors

agross avatar bo98 avatar branchvincent avatar brewtestbot avatar buschtoens avatar danielcompton avatar dduugg avatar domt4 avatar emroch avatar ericfromcanada avatar erikw avatar ghazel avatar glensc avatar gromgit avatar issyl0 avatar killeroid avatar mikemcquaid avatar nandahkrishna avatar ndbroadbent avatar oguzhanmeteozturk avatar p-linnane avatar rafaelmiquelino avatar rylan12 avatar smitt14ua avatar swissbuechi avatar toobuntu avatar vtta avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

homebrew-autoupdate's Issues

Question on notifications…

Will autoupdate and notifications only work if the current user is admin? I generally only switch to my admin account to update software and then I sign out. Or I su admin in terminal to work on brew from my user account. I am not seeing any notifications from homebrew-autoupdate.

Is there a way to manually set the time this autoupdate happens in the plist?

error when run auto update

I got this error when trying to run brew autoupdate start --upgrade --cleanup

Permission denied @ rb_sysopen - /Users/dat/Library/LaunchAgents/com.github.domt4.homebrew-autoupdate.plist

Detects notifier as "false"

I have the terminal-notifier gem installed, but not the macOS executable.

$ brew info terminal-notifier
terminal-notifier: stable 2.0.0 (bottled), HEAD
Send macOS User Notifications from the command-line
https://github.com/julienXX/terminal-notifier
Not installed
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/terminal-notifier.rb
==> Requirements
Build: xcode ✘
Required: macOS >= 10.8 ✔
$ gem which terminal-notifier
/Users/agross/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/terminal-notifier-2.0.0/lib/terminal-notifier.rb

Invoking terminal-notifier manually works and shows a notification:

$ terminal-notifier -title '🍺 brew-autoupdate' -message 'Homebrew has been automatically updated.' -group 'com.github.domt4.homebrew-autoupdate''
$ echo $?
0

Starting homebrew autoupdate detects the notifier as false:

$ brew autoupdate --delete
Homebrew will no longer autoupdate and the plist has been deleted.
$ brew autoupdate --start --upgrade --cleanup --enable-notification
Homebrew will now automatically update every 24 hours, or on system boot.
$ cat "$HOME/Library/Application Support/com.github.domt4.homebrew-autoupdate/updater"
#!/bin/sh
/bin/date && /usr/local/bin/brew update && /usr/local/bin/brew upgrade -v && /usr/local/bin/brew cleanup && false -title '🍺 brew-autoupdate' -message 'Homebrew has been automatically updated.' -group 'com.github.domt4.homebrew-autoupdate'

Change StartInterval to StartCalendarInterval

I suggest changing StartInterval to StartCalendarInterval.

According to documentation StartInterval skips execution if computer is in sleep mode:

StartInterval <integer>
     This optional key causes the job to be started every N seconds. If the system is asleep during the time of the next scheduled interval firing, that interval will be missed due to shortcomings in queue(3).  If
     the job is running during an interval firing, that interval firing will likewise be missed.

StartCalendarInterval will be done right after its awakening and in my opinion this behavior is more desirable.

StartCalendarInterval <dictionary of integers or array of dictionaries of integers>
     This optional key causes the job to be started every calendar interval as specified. Missing arguments are considered to be wildcard. The semantics are similar to crontab(5) in how firing dates are specified.
     Multiple dictionaries may be specified in an array to schedule multiple calendar intervals.

Unlike cron which skips job invocations when the computer is asleep, launchd will start the job the next time the computer wakes up.  If multiple intervals transpire before the computer is woken, those events
     will be coalesced into one event upon wake from sleep.

Permission denied when trying to create startup plist file

Just installed on a new machine, and received the following error:

Error: Permission denied @ rb_sysopen - /Users/kevinmckernan/Library/LaunchAgents/com.github.domt4.homebrew-autoupdate.plist

Command used:
brew autoupdate --start --upgrade --cleanup --enable-notification

I had to create the file with sudo, and then chown it to my user.

Mac OS 10.13.3
Homebrew 1.5.10
Homebrew/homebrew-core (git revision c7c1; last commit 2018-03-13)

Apps from casks won't automatically restart after updating

I used homebrew to install most of my Macs apps as casks, e.g. apps like Google Chrome. A few months ago I installed homebrew on a brand-new Macbook Air M1 with Monterey with apps.

The problem I have is that, having set apps to autoupdate every 24h, every time an app actually does autoupdate, it won't automatically restart. The old version of the app quits, but the updated version won't start automatically.

This happens with lots of always-running apps that live in my menubar like Stats, but it also happens whenever I (infrequently) restart Chrome. Today, for example, I put "chrome://restart" in its menubar, and while it quit, it didn't restart. And then when I went to launch Chrome from its icon, I got this warning:

Homebrew Cask downloaded this file today at 15:20 from www.google.com. Apple checked it for malicious software and none was detected.

Then I clicked OK and Chrome started. So the issue is clearly Gatekeeper -- when apps are supposed to auto-restart they don't (and doesn't even show a prompt), while with manually started apps it does show a prompt.

Is there a way to bypass the prompt and have apps start without one? I don't want to turn off Gatekeeper entirely, and the funny thing is that Gatekeeper explicitly reports it doesn't find malicious software, so I don't even understand why there's a prompt in the first place.

This has sadly been getting tiresome (there are menubar apps I expect to be always-on, and not die on every update), and what I don't understand is that back when I use apps own auto-update feature, this is never a problem. I never was asked to approve each Chrome upgrade by Gatekeeper until I started using the cask autoupdate instead of Chrome's own.

So my questions are:

  1. Is this a problem other people are having?

  2. Is there a way for me to fix it on my Mac I don't know about? (Without entirely disabling Gatekeeper)

  3. Is there a way for brew (auto)update to not suffer from this problem?

I'm actually most mystified because this doesn't appear to be a common problem -- Googing the text of the Gatekeeper message together with homebrew doesn't seem to yield much.

Thank you!

upgrade formula only

Is there an option to --upgrade only formula and keep casks untouched?
Something akin: brew upgrade --formula

Logging in addition to notifications

Wouldn't it be useful to add some logging? I've been using autoupdate for a couple of weeks now, but it leaves me wondering what was updated...

I've activated the notifications, but I never see them since the updates usually run when I'm not at my computer.

Auto re-link packages

I had an issue when starting node.js, when starting the library was not loaded. I had to: brew unlink node && brew link node.

Would it be possible to automate re-linking?

Backup and restore Launchpad apps position after upgrade

I installed some apps with homebrew and when I update them their position in launchpad changes (I have them in folders and after an upgrade they appear like new apps in the first page of launchpad).
I would like, if possible, to backup the apps position in launchpad before upgrading and restore it after upgrading.

add --StartOnMount

the autoupdate is not working, if the Mac is not running > 24h. In my case if I reboot, the script does not run.
So please add the possibility to run the autoupdate everytime the filesystem is mounted.

Use StartCalendarInterval in addition to StartInterval

StartCalendarInterval

The man page for launchd.plist says:

     StartInterval 
     This optional key causes the job to be started every N seconds. If the system is
     asleep during the time of the next scheduled interval firing, that interval will be
     missed due to shortcomings in kqueue(3).  If the job is running during an interval
     firing, that interval firing will likewise be missed.

     StartCalendarInterval 
     This optional key causes the job to be started every calendar interval as specified.
     Missing arguments are considered to be wildcard. The semantics are similar to
     crontab(5) in how firing dates are specified. Multiple dictionaries may be specified
     in an array to schedule multiple calendar intervals.

     Unlike cron which skips job invocations when the computer is asleep, launchd will
     start the job the next time the computer wakes up.  If multiple intervals transpire
     before the computer is woken, those events will be coalesced into one event upon
     wake from sleep.

     Note that StartInterval and StartCalendarInterval are not aware of each other. They
     are evaluated completely independently by the system.

This currently uses StartInterval:

<key>StartInterval</key>
<integer>#{interval}</integer>
.

This means that Homebrew autoupdate may not be run if it happens to be asleep when the timer would normally fire. I've noticed this myself a few times and was surprised by it.

I think it could be good to use StartCalendarInterval, either as an option, or a replacement for StartInterval. StartCalendarInterval is basically a cron expression.

An easier alternative would be to document this limitation, and encourage people to check often enough that they won't miss too many updates from their computer being asleep.

RunAtLoad

The man page also says:

     RunAtLoad 
     This optional key is used to control whether your job is launched once at the time
     the job is loaded. The default is false. This key should be avoided, as speculative
     job launches have an adverse effect on system-boot and user-login scenarios.

We should probably remove this key to avoid doing a bunch of work in the background on boot.

ProcessType

We should also look at setting the ProcessType to Background

     ProcessType 
     This optional key describes, at a high level, the intended purpose of the job.  The
     system will apply resource limits based on what kind of job it is. If left unspeci-
     fied, the system will apply light resource limits to the job, throttling its CPU
     usage and I/O bandwidth. This classification is preferable to using the
     HardResourceLimits, SoftResourceLimits and Nice keys. The following are valid val-
     ues:

           Background
           Background jobs are generally processes that do work that was not directly
           requested by the user. The resource limits applied to Background jobs are
           intended to prevent them from disrupting the user experience.

Add terminal-notifier as a recommended/optional depency

It would be nice if terminal-notifier would be listed as a (required/optional/recommended) dependency for brew to install along with autoupdate.

Will the above be impossible due to this only being a tap and not a full fledged formula?

If it is impossible, it would be nice to have a simple brew install terminal-notifier in the README.md

Log files are not writable by user

The plist file specified that log files should be written to /usr/local/var/log/homebrew.mxcl.autoupdate.{out,err}. On my macOS Sierra these files are not writable by my user, hence the job always fails and LaunchControl shows error 87.

$ sudo ls /usr/local/var/log/
total 0
drwxr--r-- 2 root   wheel  68 Dec 27 03:20 .
drwxrwxr-x 7 agross admin 238 Jan  5 19:07 ..

Include optional flag for mas

Hi there,

First of all, love this repo!

There's a project (mas-cli) that allows Mac App Store apps to be installed and updated from the command line. I think homebrew-autoupdate should add an optional flag (say, --mas) that would run 'mas upgrade' as well.

That way, homebrew-autoupdate can be the one place to auto update and upgrade homebrew, casks, and Mac App Store apps.

Thanks!

"brew cask cleanup" is deprecated, breaking notifications if it's last.

==> No Casks to upgrade
Error: Calling "brew cask cleanup" is disabled! Use "brew cleanup" instead.

/usr/local/bin/brew cask cleanup in the "updater" script errors out and never executes the terminal-notifier command that comes afterwards.

I'm using brew autoupdate --start 43200 --upgrade --cleanup --enable-notification

For me, removing the deprecated/disabled (as of 9/30/2018) && /usr/local/bin/brew cask cleanup by (removing line #21 from start.rb) solved the issue.

@DomT4

more info: Homebrew/brew#4660 & Homebrew/brew#4645

[Question] Source Code for the notifier

I would love to understand how you got the notifier working with your own Icon, since terminal-notifier and several other projects are no longer working.

Did you write the notifier yourself? And would you mind sharing it source code?

Add start/end notification?

Hi,

Just an idea that came to my mind after I got a env: node: No such file or directory error caused by homebrew selfupdating in the background. At first I was like "the heck node doesn't work anymore?". It's only after thinking about it that I remembered that I just started my mac and then the autoupdate should be running, upgrading the version of node, hence node not being available during upgrade.

So here's the idea: why not having a system notification (that can be switched on/off) for distracted people like me that would say something like "hey homebrew autoupdate started!" and "Yay homebrew update done!". If you're OK with the idea I could try to implement it and submit it as a PR.

"Logs not found; cannot show summary!"

Getting this error in the macOS notification when rebooting and autoupdate is running.

Anything I can do to fix this? Or some trace/logs I can look at to look into it?

New notifier steals focus

'brew-autoupdate' icon in dock

The new brew-autoupdate.app notifier (#43) "steals the focus" when displaying a notification.

For as long as the 🍻 icon is being displayed in the macOS dock (about 3 seconds for me), the focus is removed from the prior window and instead moved to brew-autoupdate. Once the brew-autoupdate app closes (i.e. the dock icon disappears), the focus is returned to the prior window.

(Notably, the notification banner itself outlives the brew-autoupdate app instance by a few seconds, but I doubt that this is of any relevancy here and just due to how macOS handle notifications.)

You can manually return the focus while brew-autoupdate is still running by clicking or Cmd+Tab-ing to where you want to go. However, since the whole stunner just takes about 3 seconds, you usually don't realize what's going on, before everything is back to normal again.

This is quite an annoying bug though, especially if you have a high update frequency. I spend most of my time in VS Code furiously bashing my keyboard, when all of a sudden I get spammed with the system alert sound effect, while all my keystrokes vanish into /dev/null. Instant flow killer. 😄

New flag --upgrade-cask

I suggest to introduce new flag --upgrade-cask and --upgrade-cask-greedy according to #58. I think separation formulas from casks upgrades would be more convenient.

Notifications not working macOS Monterey

I'm trying to enable homebrew update notifications on my new mac but I get "Unknown error: 153" in the log and no notification.

Here's the start command I'm using

brew autoupdate start --enable-notification --immediate

Here are the contents of log file ~/Library/Logs/com.github.domt4.homebrew-autoupdate/com.github.domt4.homebrew-autoupdate.out

Thu Dec  2 09:28:53 CST 2021
Already up-to-date.
The application cannot be opened for an unexpected reason, error=Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x6000030a2070 {Error Domain=NSPOSIXErrorDomain Code=153 "Unknown error: 153" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}

Any ideas why this error is happening?

Thanks!

Notification Rollout & Implementation [Tracking]

TO-DO:

  • Do a tighter match on the notification output so it only updates the intended part of the log, rather than getting a little overly enthusiastic and sharing the wrong lines.

  • Consider utilising brew cleanup or tweak this tool itself to periodically remove the log file so it doesn't become too large in size and/or increasingly slow to machine-read.

  • Consider adding a notification for the start of the update process, i.e. Homebrew Autoupdate Starting or such.

  • Consider adding a notification for background failures, even if we don't get too elaborate about it. This command logs the entire output to a file anyway, so it'd be easy enough to alert the user to the fact the command failed and to look at the log file to work out why if we wanted to keep it barebones. Ref: #42.

  • Investigate whether the above can be achieved using the one AppleScript applet or whether because of the somewhat limited & finicky nature of applets I'd need to add unique applets for each case (which wouldn't really be a big burden, but isn't ideal).

  • Fully deprecate terminal-notifier, as it seems to be dead upstream at this point and provides a pretty suboptimal experience compared to native macOS notifications. This might involve waiting until macOS 12 (assuming whatever comes after Big Sur is called macOS 12) so that there's at least two recent versions of macOS supported by the new notifier.

This issue supersedes #25, #15 & #42.

--upgrade option stopping outrun

Saw this issue in the closed tab.

When adding the --upgrade flag to brew autocomplete. It seems to stop autoupdate from running.

brew autoupdate --start 43200 --upgrade --cleanup --enable-notification does not work.

brew autoupdate --start 43200 --cleanup --enable-notification does work.

I am running both 10.15.6 and 10.14.6.

I've tried re-installing "xcode-select --install" to no avail.

--no-quarantine not respected

I have set HOMEBREW_CASK_OPTS="--no-quarantine"

After homebrew-autoupdate updates a cask, I get this:

Pasted image 20221215112641

I normally do not.

--upgrade flag stops autoupdate from running

Hi,

When adding the --upgrade flag to brew autocomplete. It seems to stop autoupdate from running.

brew autoupdate --start 43200 --upgrade --cleanup --enable-notification does not work.

brew autoupdate --start 43200 --cleanup --enable-notification does work.

I am on OXS 10.14.1.

Cheers!

Only run if plugged in

This shouldn't be that hard to implement, just checking if the command pmset -g batt | head -n 1 | cut -d \' -f2 returns AC Power and only if it doesn't, cancel the update and potentially send the user a notification. This is useful for running upgrades on all packages due to compilation taking up cpu etc.

Notify on failure

First and foremost, thanks for releasing this. It's super duper handy for staying up-to-date by default :)
This is a feature request for what I think might be a common snag, based on my friends experience with it

Every so often, there's some random issue preventing brew from upgrading installed packages. Maybe xcode-select --install needs rerunning, or something needs a sudo password as in #40, or what have you. I usually don't catch those for a little while. It'd be great to have the notification feature tell you about failures, too. Or maybe just about new failures since the last run. Then I'd know about them and fix them immediately, letting your great auto-updater get back to work.

TL;DR: Notify about new failures upgrading so the user know when to fix them.

Thanks for your consideration!
Chris

(And apologies if it already does this somehow and I've misconfigured things.)

Limit for auto-upgrades?

I really like how this works, but I wish I could have it only do brew update without brew upgrade.

Personally, I'm a little leery about automatically upgrading everything I've installed because I know that something will eventually break and it will take forever to hunt down which thing upgraded...

Thoughts?

[BUG] HOMEBREW_CLEANUP_MAX_AGE_DAYS do not work for --cleanup

Bug

brew autoupdate start 86400 --cleanup do not cleanup files even set HOMEBREW_CLEANUP_MAX_AGE_DAYS to 0.

How to reproduce

  • run export HOMEBREW_CLEANUP_MAX_AGE_DAYS=0 to set HOMEBREW_CLEANUP_MAX_AGE_DAYS to 0 in terminal
  • Install something to ensure that there are something to cleanup, and use brew cleanup -n to check it
  • run brew autoupdate start 86400 --cleanup --immediate to start autoupdate
  • wait for the notification of finishing from autoupdate
  • run brew cleanup -n again and find that autoupdate do not cleanup files

request: cleanup

I don't believe the --cleanup flag will automatically run the 'cask cleanup' command, so I'm left to do this manually. OH THE HUMANITY!

Perhaps it can be included with the existing cleanup script– or if that triggers an error for those without any installed casks, perhaps add a separate flag.

Not working - Not updating outdated packages

I installed a few days ago and I get the notifications that "Homebrew has been updated", however when I run brew outdated, I still have some packages with available updates.

[email protected] (3.10.2) < 3.10.4
rclone (1.58.0) < 1.58.1
powershell (7.2.2) != 7.2.3

log shows:

Sun May  1 14:38:37 CDT 2022
Already up-to-date.
Sun May  1 14:39:31 CDT 2022
Already up-to-date.
Sun May  1 14:41:05 CDT 2022
Already up-to-date.

I tried deleting the plist with brew autoupdate delete and reinstalled with brew autoupdate start. Manually adjusted the launchd schedule to run in a few mins, receive the macOS notification that it is again been updated, but the packages do not update.

homebrew-autoupdate is not working with `sudo -uH` or `su -`

homebrew-autoupdate is not working with sudo -uH admin or su - admin

Homebrew is installed within an administrator account (not root).
For daily use I granted a normal user to manage homebrew via sudoers-entry.

So things like sudo -Hu admin brew install/update/etc or su - admin and afterwards brew install/update/etc are working flawlessly.

The only thing which is not working is homebrew-autoupdate.

If I were logged in as admin - everything is fine.
But if I was logged in as a normal user, sudo -Hu admin brew autoupdate --start 7200 --upgrade --cleanup --enable-notification --debug or first su - admin and afterwards the previous brew autoupdate command, results in:

Warning: Please note if you use Casks that require `sudo` to upgrade there
are known issues with that use case and this command unless using
`SUDO_ASKPASS`.

  https://github.com/Homebrew/homebrew-autoupdate/issues/40

/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/terminal-notifier.rb
Homebrew will now automatically update every 2 hours, or on system boot.
/usr/local/Homebrew/Library/Homebrew/brew.rb:125:in `exit'
/usr/local/Homebrew/Library/Homebrew/brew.rb:125:in `<main>'

sudo -Hu admin brew autoupdate --status reports:

Autoupdate is installed but stopped.

Autoupdate was initialised on 04/18/21.

Also if I log in first as admin, run brew autoupdate --start 7200 --upgrade --cleanup --enable-notification --debug, log out and log in afterwards as a normal user sudo -Hu admin brew autoupdate --status reports the same:

Autoupdate is installed but stopped.

Autoupdate was initialised on 04/18/21.

What is more, even if the setup works with a local admin account logon - as soon as the admin user is logged out, the launch daemon application.com.github.domt4.homebrew-autoupdate.autoupdater.42866421.42866425 is no longer running.

undefined method `[]' for Formula:Clas

Hello,
I am using MacOS 11 and get the following error message when executing the script:

brew autoupdate --start 86400 --enable-notification
Error: undefined method `[]' for Formula:Class
/usr/local/Homebrew/Library/Taps/domt4/homebrew-autoupdate/lib/autoupdate/notify.rb:6:in `notifier'
/usr/local/Homebrew/Library/Taps/domt4/homebrew-autoupdate/lib/autoupdate/start.rb:25:in `start'
/usr/local/Homebrew/Library/Taps/domt4/homebrew-autoupdate/cmd/brew-autoupdate.rb:35:in `<top (required)>'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
/usr/local/Homebrew/Library/Homebrew/utils.rb:85:in `require?'
/usr/local/Homebrew/Library/Homebrew/brew.rb:115:in `<main>'

mkdir LaunchAgents

A fresh install of macOS does not have a ~/Library/LaunchAgents directory. So running autoupdate fails:

$ brew autoupdate --start --upgrade --cleanup
Error: No such file or directory @ rb_sysopen - /Users/ghazel/Library/LaunchAgents/com.github.domt4.homebrew-autoupdate.plist

Seems like just mkdir ~/Library/LaunchAgents fixed it, but it should probably do that automatically.

Cannot convert plist to json

FYI, Clean My Mac 3 flags the plist as being broken:

$ plutil -convert json $HOME/Library/LaunchAgents/homebrew.mxcl.autoupdate.plist
/Users/you/Library/LaunchAgents/homebrew.mxcl.autoupdate.plist: Property List error: Encountered unknown ampersand-escape sequence at line 11 / JSON error: JSON text did not start with array or object and option to allow fragments not set.

I'm not sure whether the plist itself is broken or if Clean My Mac/plutil is. Even without trying to convert things it seems plutil considers the plist invalid:

$ plutil $HOME/Library/LaunchAgents/homebrew.mxcl.autoupdate.plist
/Users/you/Library/LaunchAgents/homebrew.mxcl.autoupdate.plist: Encountered unknown ampersand-escape sequence at line 11

Handling Casks

Issue:

  • Currently Casks that use sudo to upgrade can block this command from executing successfully when people use autoupdate to execute upgrade on their behalf, because of the hang on silently waiting for sudo authorisation.
  • Homebrew explicitly does not support launching brew upgrade with sudo, immediately bailing on the command, meaning we can't execute the Cask upgrade command as root to work around the issue.

Potential Fix:

  • Using Homebrew's API to work out which Casks are outdated, and which of those Casks need sudo usage to upgrade, only passing those non-sudo Casks to the upgrade command.

Problems with Fix:

  • Likely to be computationally expensive, making the command very slow to execute.
  • Leaves sudo Casks behind intentionally; would need to find a way to gracefully notify the user to their presence & reason for not upgrading.
  • Leaning on Homebrew's API so heavily to work out what casks are outdated and which of those need sudo has a very real potential to be fragile and prone to breaking.
  • Quite a lot of work for something I'm not sure how widely is a use-case yet.

Hacky Temporary Workaround

  • Use SUDO_ASKPASS as Homebrew seems to intentionally support that for non-interactive installs, and works when tested locally.
  • I don't really want to settle on that as a long-term solution because I'm a tad uncomfortable asking people to simply leave their sudo passwords sat on the filesystem unguarded in plaintext.

Related Issues:

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.