How come there's no way to logically invert "require:" ?

[poige]

A simple stuff let's do regex-replace only if there's no some specific string already in a file needs to use workarounds like SHELL-spawned "grep -v" — because even grep has logical inversion.

Saltstack is weird.

[lkubb]

The answer depends on the specific problem you're having.

For the question in the title:
There's onfail, which is effectively the inversion of require, but does not "un-fail" a failed state otherwise.

Salt often has multiple ways to arrive at a destination, which can be confusing, but allows for a lot of flexibility. In regards to your example, there's unless/onlyif, which determine if a state should run at all. In addition to shell commands, you can use execution modules there, which is more portable. This is likely what one would use to implement your example functionality, but would work with any other state module. You only have to learn it once and can use it as a building block in the future.

The file.replace state could receive a new parameter that does exactly what you ask of course, but there are many variations users might need, which can be provided more generally.

[poige]

It's not about "ways to reach", it's about being needlessly cumbersome and not-terse in these very ways (or vice versa). If same result can be reached by use of the logical inversion, why is there another "keyword" which is "effectively the inversion"? And even so, okay, let's have 10 additional "keywords" for different combos of logicals — still what problem is to support logical operations then anyways?

There's onfail, which is effectively the inversion of require

Thank you for this information! I've gone a few times through the https://docs.saltproject.io/en/latest/ref/states/requisites.html before posting and now can only say that if onfail was even listed closer to require (logically grouped) then may be it'd be less vague. And/or at least mentioned in require itself.

but does not "un-fail" a failed state otherwise.

Not really got this one, but I'm even unsure if it's critical for that simple task I've described in the original message.

[lkubb]

Sorry about your frustration, please mind I'm just another user trying to help out. Salt has a bit of a learning curve in the beginning and the docs can make it worse at points.

It's not about "ways to reach", it's about being needlessly cumbersome and not-terse

Maybe giving an example of how you imagine an optimal solution would help in the discussion of your issue because I feel like I'm missing the point. Is it a notation like the following?

state_a:
  stuff.done:
    - name: foo

state_b:
  other_stuff.checked:
    - name: bar

state_c:
  more_stuff.managed:
    - name: baz

state_d:
  file.replace:
    - name: /foo/bar
    - require: (state_a and state_b) or not state_c

I'm unsure how this would help with the "regex replace unless file contains" example, which can be implemented like this:

Replace stuff:
  file.replace:
    - name: /foo/bar
    - pattern: ...
    - repl: <replacement>
    - unless:
      - fun: file.search
        path: /foo/bar
        pattern: dont_regex_replace_this_file

it'd be less vague

Agreed about the doc deficiencies.

Not really got this one

It means the state run summary still shows a failed state and its exit code will be >0.