Parsing error on &!

[AndrewKvalheim]

zsh has a &! syntax for starting a disowned job, e.g.:

sleep 3s &!

Using this in a script causes resholve to fail with a parsing error:

$ resholve --interpreter "$SHELL" --path '' <<< 'sleep 3s &!'
  sleep 3s &!
             ^
[ stdinNone ]:2: error: Invalid word while parsing command

[abathur]

This is expected (for now, at least). It's documented in the manpage (here's an excerpt from the plaintext copy):

resholve/docs/resholve.1.txt

Lines 202 to 213 in 80e9363

	LIMITATIONS
	• resholve is built on the bash-compatible OSH parser (from the Oil
	shell project). It can't handle any script OSH can't parse.
	• Support for non-bash shells is a happy side-effect of how similar
	POSIX-ish shell languages are. If you run into a parse error with any
	non-bash syntax, your only real option is changing the script.
	• If you run into a parse error with valid bash syntax, check Oil's is‐
	sue tracker (https://github.com/oilshell/oil/issues) to see if the
	issue is known and whether it is likely to be fixed. If it won't be
	fixed, your only recourse is changing the script.

In the near-ish term, we can probably:

• Use the documentation-generation capabilities added earlier this year to finally start generating the main README.md, which should make it easier to keep it (and other doc outputs) in sync on some questions like this.
• Look into decorating parse errors that from the Oil/OSH parser with a little more context on this point.

In the long run I would like for resholve to be a little more parser-agnostic, but my gut says that'll be pretty difficult. I made some strides over the last year to build a more domain-specific abstraction layer between resholve and the OSH parser, but it is still tightly coupled to some of Oil's abstractions and APIs.

[AndrewKvalheim]

Thanks, makes sense. Indeed, I’d only been looking at the main and nixpkgs readmes. For now I’ll just use a wrapper around resholve to temporarily replace &! with @AMPERSAND_EXCLAMATION@.

[abathur]

Good point--if pluggable parsers don't seem to be tractable, I guess pluggable in/out filters might be...