Sometimes a fix could be parameterized based on the text found in an error message.
Consider the following (contrived) example.
❯ ./foo.sh
zsh: permission denied: ./foo.sh
We could create a known error for this such as this
apiVersion: scope.github.com/v1alpha
kind: ScopeKnownError
metadata:
name: not-executable
description: "The shell script is not executable"
spec:
pattern: ".*sh: permission denied: \\./foo\\.sh"
help: |+
This error occurs because the file is not executable.
Run `sudo chmod +x foo.sh` and try again.
fix:
prompt:
text: Remove the old symlink?
commands:
- sudo chmod +x foo.sh
This works for this one particular example, but if there are multiple possible files, we would need to adjust the regex pattern to the following
apiVersion: scope.github.com/v1alpha
kind: ScopeKnownError
metadata:
name: not-executable
description: "The shell script is not executable"
spec:
pattern: ".*sh: permission denied: \\./.*"
help: |+
This error occurs because the file is not executable.
Run `sudo chmod +x {filename}` and try again.
Which covers many more possible errors, but we lose the ability to to automatically fix it for the user.
Ideally, we would allow capturing a group in the regex pattern that could then be substituted into the help text and/or the fix command.
This is an off the cuff, proposed syntax for substitution.
apiVersion: scope.github.com/v1alpha
kind: ScopeKnownError
metadata:
name: not-executable
description: "The shell script is not executable"
spec:
pattern: ".*sh: permission denied: \\./(.*)"
help: |+
This error occurs because the file is not executable.
Run `sudo chmod +x {{$1}}` and try again.
fix:
prompt:
text: Remove the old symlink?
commands:
- sudo chmod +x {{$1}}
This would allow much greater flexibility in the known error system and reduce the amount of duplication in a known error knowledge base.
Sometimes a fix could be parameterized based on the text found in an error message.
Consider the following (contrived) example.
We could create a known error for this such as this
This works for this one particular example, but if there are multiple possible files, we would need to adjust the regex pattern to the following
Which covers many more possible errors, but we lose the ability to to automatically fix it for the user.
Ideally, we would allow capturing a group in the regex pattern that could then be substituted into the help text and/or the fix command.
This is an off the cuff, proposed syntax for substitution.
This would allow much greater flexibility in the known error system and reduce the amount of duplication in a known error knowledge base.