This is currently behaving incorrectly when calling `trash.swift` fails
due to lack of permissions. In this instance, `trash.swift` prints
error: permissionDenied
to stdout, and this is incorrectly parsed as having successfully trashed
a file named `error` and another named ` permissionDenied`.
Let's fix this by ensuring that:
- any paths in `trashed` are in the `paths` that we wanted to trash in
the first place
- define `untrashable` by removing the `trashed` paths from `paths`
I inadvertently duplicated the `@token` instance variable definition
in `Cask::DSL#initiailize`, so this removes the duplicate. This
didn't have any noticeable effect because it was redefined afterward,
so this is just a bit of tidying up.
I recently modified `Cask::DSL` to define instance variables in the
`#initialize` method and this involved some changes to the `language`,
`language_eval`, and `languages` methods. One of those was to
initialize `@language_blocks` to an empty hash instead of using a
`nil` default. I updated the related condition in the `language_eval`
method but I missed that `language_blocks` is used in `Cask::Auditor`
and it specifically relies on a false-y value to check if the variable
is set. An empty hash isn't false-y, so this is causing issues for
`brew audit`.
This updates the condition in `Cask::Auditor` to check for a non-empty
hash instead, which resolves the issue.
I recently updated `Cask::DSL` to define instance variables in
`#initialize` to get us closer to resolving a "shape variation"
warning from Ruby. The reason why we continued to receive this warning
after the previous changes is because I overlooked the variables that
are set using `set_unique_stanza`.
The tricky part about those instance variables is that we need to be
able to identify if they've been set. I've handled this by using a
`nil` initial value and updating the `instance_variable_defined?`
condition to check for a non-`nil` value instead. This works for these
variables but it would be a problem if we ever have a DSL method that
accepts a `nil` argument.
We're now seeing warnings related to the cask DSL surfaced by Ruby
3.4:
```
/opt/homebrew/Library/Homebrew/cask/dsl.rb:456: warning: The class
Cask::DSL reached 8 shape variations, instance variables accesses
will be slower and memory usage increased.
It is recommended to define instance variables in a consistent order,
for instance by eagerly defining them all in the #initialize method.
```
I've been working on upgrading `Cask::DSL` to `typed: strict` and
part of that involves defining all of the instance variables in the
`initialize` method, so I've extracted this part of that work as a
way of helping to resolve the aforementioned warning. This doesn't
fully resolve the warning but it addresses what it was originally
referencing, at least.
For what it's worth, this includes some type fixes but I've only
included what's necessary to pass `brew typecheck`.
`#present?` is called on a `DependsOn` object in `Cask::DSL` and this
is seemingly deferred to the underlying hash object but Sorbet doesn't
understand this kind of `SimpleDelegator` magic. This adds `empty?`
and `present?` methods that explicitly interact with the hash in a
way that Sorbet can understand.
These are always output in CI for e.g. `brew fetch google-chrome` and
are completely unactionable by the user.
Ultimately this is not disabling any security checks, it's just changing
when a warning is output and unifying the logic with the other similar
warning.
We recently added `POST` request support to livecheck but related cask
checks are failing the `livecheck_https_availability` audit because it
calls `validate_url_for_https_availability` which calls
`Utils::Curl.curl_check_http_content` and that checks the URL using a
`GET` request. Adding `POST` request support to all of those methods
will take some work, so this adds a guard to skip the audit if the
`livecheck` block uses `post_form` or `post_json`. This isn't ideal
but it will allow us to add these `livecheck` blocks in the interim
time.
Co-authored-by: Douglas Eichelberger <d@eic.email>
The existing code for handling a `HEAD`-only formula involves two
return values that can be `nil` but this isn't apparent because the
related methods aren't typed. This adds type signatures to the
methods and updates the livecheck code to account for `nil` return
values (making it clear which methods can return `nil`).
Co-authored-by: Mike McQuaid <mike@mikemcquaid.com>
This fixes handling `sudo` and EUID when using certain `script` commands
on casks e.g. adobe-creative-cloud.
Co-Authored-By: Bo Anderson <mail@boanderson.me>
