<? operator (and >? consistency)

[drwilly]

As you might know some modern programming languages support a ?. operator.
The ?. operator works just like the well-known . but has a built-in null-check, so myobj?.someMethod() is equivalent to if(myobj != null) myobj.someMethod()
In fish I've recently come across the pattern test -r file; and cmd < file which is very similar to the above example with the null-check replaced by a file-readability-test. My idea was to express this pattern simply as cmd <? file: If file is not readable, the command is skipped.

Interestingly the <? operator is already implemented in fish, however it's current behaviour is to fail if the file exists. As for as I can see for the stdin redirect this doesn't make any sense whatsoever.

Now that brings me to the consistency topic:
Currently, >? file fails noisily if file exists, while <? would skip quietly if file does not exist.
Would you consider changing the bahaviour of >? or rather suggest a different operator for <??
RFC

[faho]

Interestingly the <? operator is already implemented in fish, however it's current behaviour is to fail if the file exists. As for as I can see for the stdin redirect this doesn't make any sense whatsoever.

As far as I can tell, there is no specific <? redirection. This seems to be essentially a bug in the implementation.

I'd be okay with <? not failing if the file does not exist. It would be rather useful - we currently have a bunch of test -e "$file"; and string <$file that could be replaced with this.

However, I'm not convinced that changing >? by essentially swapping it with > would be worth it, and without that the entire thing is a bit inconsistent.

[drwilly]

I don't quite understand what you mean with "swapping it with >".

Also could you explain what the original goal behind >? is? As far as I can see it is basically O_EXCL integrated into the shell, however I'm not sure what the actual use-case for that is.

[faho]

Also could you explain what the original goal behind >? is?

It's the "noclobber" operator. With it, you redirect output to a file only if it does not exist yet.

The default ">" operator will overwrite a file if it already exists, which is often not what you want.

E.g.

echo foo >/etc/fstab # will overwrite your fstab, if run as root

while

echo foo >? /etc/fstab # will error out, without changing /etc/fstab, even if run as root

---

What you propose with <? is that it skip the operation if a file does not exist, without an error. Currently < would print an error. So the one with the ? does not print an error, the one with does.

Compare it with > and >?. Here the one with the ? would error, while the one without it would not.

That's the inconcistency that I was talking about, which is why I thought about swapping them.

[drwilly]

Ok, I think I got what you meant. My idea was not to change the functionality of >?, just to remove the error message. Basically not test -e file; and cmd > file … if that is desired at all, see below.

Yes I understand the idea behind noclobber, I just question fish's implementation: In bash et al. you set that as a global option, which makes sense for interactive use: It makes the default behavior safe as it protects you from typos or careless commands that end up overwriting a file by mistake, while you can use >| to overrule that safe behavior.
In fish on the oher hand, you have to be extra careful to always use >? to get the safe behavior, while the standard mode of operation is unsafe. If it is intended for interactive use, I don't think it does a good job at what it is supposed to do. If it is intended for scripting, again, I have no idea what the use-case is supposed to be.

[ridiculousfish]

Removing the error message from >? makes sense to me. What's a use case for <? to add some context?

[drwilly]

The <? operator would be most beneficial in non-interactive use. In scripts such as the ones found in completion/, fish is looking to replace calls to grep, sed and thelike with it's string builtin.
In order to operate on a file, string requires the use of the < redirect-operator. This however makes some extra precaution (usually in the form of test -r file; and string match foo < file) necessary, as a redirect on a missing or unreadable file produces an error message that shouldn't end up in completion output. For an example of this, see mount.fish) At the same time a solution such as grep foo missing_file 2> /dev/null is not available.
A <? operator would clearly communicate the intention aswell as offering some technical advantages such as fewer syscalls and the elimination of a possible race-condition.