Non-existent filename after redirection as error?

[danielshahaf]

Consider the command line % <foo cat <CURSOR>. When foo exists, we highlight it as a file. When foo does not exist, why don't we highlight it as unknown-token?

---

Cases that should raise errors, but currently don't:

The NO_CLOBBER cases:

• > foo echo <CURSOR> when foo exists and setopt NO_CLOBBER is in effect

  Note: setopt noclobber; echo > /dev/tty works even though /dev/tty exists: https://github.com/zsh-users/zsh/blob/b13e8d16cf3239bd8b4b0434055d25fe4b3d7e7c/Src/exec.c#L2138-L2168

• >> foo echo <CURSOR> when foo doesn't exist and setopt NO_CLOBBER NO_APPEND_CREATE is in effect

The EPERM cases:

• < foo cat <CURSOR> when foo is not readable

  ("Doesn't exist" is a special case of "is not readable".)

• <>foo cat <CURSOR> when foo is either not readable or not writable

• >! foo echo <CURSOR> when foo is not writable

• >! foo echo <CURSOR> when foo doesn't exist and foo(:h) is not writable

All these cases (the NO_CLOBBER ones and the EPERM ones) should be unknown-token.

---

Cases that create a new file:

• > foo echo <CURSOR> when foo doesn't exist and setopt CLOBBER is in effect.
• >! foo echo <CURSOR> when foo doesn't exist
• >> foo echo <CURSOR> when foo doesn't exist and setopt CLOBBER or setopt APPEND_CREATE is in effect.
• >>! foo echo <CURSOR> when foo doesn't exist

Question: In these four cases — all of them create foo when it didn't exist before — should foo be highlighted as default, or in a new "not a filename yet but will be after this command-line is run" style?

---

Cases that I don't propose to change:

• < foo cat <CURSOR> when foo is readable
• >> foo echo <CURSOR> when foo is writable

For these cases, we might add unit tests, but no behaviour change is needed.

---

Cases that are ineligible for highlighting as a filename:

• <&4, >&4 — file descriptor target is highlighted as a path #694

• <&-, >&- — fdf23e0

• <&p, >&p — fdf23e0

  All of these are special-cased in the syntax and are never considered as filenames.

  I think they shouldn't be highlighted as filenames, ever, so if someone does >&foo to truncate ./foo and then tries to do the same to their file ./4 or ./- or ./p, the syntax highlighting will indicate their mistake.

• << foo, <<- foo, and <<< foo

Question: Should foo in the heredoc/herestring syntax eligible to be highlighted as a filename?

On the one hand, these redirections are part of the shell syntax and are never taken as filenames. On the other hand, filenames are highlighted basically whenever they appear as a separate, unquoted shell word, even in contexts like [[ /etc != /usr ]] where they're just strings. I think I'm leaning towards letting foo be highlighted as a filename here, but I could be convinced otherwise.

---

• Review all other output redirection operators: e.g., >&foo, &>foo, >|, >&!, &>!, >>&, &>>, >>&, >>&!, &>>!, etc., and handle them appropriately. (For example, >&foo should be handled like >foo, when foo isn't one of the aforementioned special cases.)
• Review the >&$myfd syntax.

---