Support reading to stdout via builtin read -

[mqudsi]

Added an option to read to stdout via read -. While it may seem
useless at first blush, it lets you do things like include

mysql -p(read --silent) ...

Without needing to save to a local variable and then echo it back.
Kicks in when - is provided as the variable name to read to. This is
in keeping with the de facto syntax for reading/writing from/to
stdin/stdout instead of a file in, e.g., tar, cat, and other standard
unix utilities.

It doesn't make anything possible that wasn't previously doable with (read temp_var; echo $temp_var) but it doesn't interfere with anything either and makes fish that much easier to use. Willing to reconsider if there is friction against including this in 3.0.

[mqudsi]

Is it ok to use std::wcout directly or should I be using some internal API to write to the shell?

[ridiculousfish]

Is there a convention that - means to output to stdout? I've seen it for stdin but can't remember seeing it for stdout.

Don't use wcout - who knows what that does, and also the wide character output functions are buggy.

Elsewhere in the shell we use wcs2string followed by write_loop with STDOUT_FILENO.

[krader1961]

Is there a convention that - means to output to stdout?

Yes, but it is very rare. The tar command is the only example that comes to mind. You would typically do tar -cf - ... to write the archive to stdout. The cat command does not use - to mean write to stdout so not sure what @mqudsi was thinking when he listed that as an example.

I have to say I'm ambivalent about this change. In part because read - is ambiguous. Does it mean read from stdin, what most people expect when they see - used that way, or write to stdout? But also because it doesn't make an uncommon pattern all that much easier. At least not enough to justify the feature in my opinion. How often have you seen scripts that read some input and immediately echo it into a pipeline? In my experience that pattern is quite rare.

A bigger objection is that the current implementation allows mixing var names and the magic - token (e.g., read x - y) which looks like a source of confusion and bugs.

If this feature is added I would request that - not be allowed if other var names are present. Obviously this also means changing the var name validation code to also only allow a single instance of -. Also, that appropriate unit tests be added.

[krader1961]

P.S., We really shouldn't be having this discussion in a change review. It belongs in an enhancement issue.

[zanchey]

Would it be better to allow read to take no arguments, and echo to standard output in that case?

[krader1961]

Would it be better to allow read to take no arguments, and echo to standard output in that case?

Yes, that would be much better from a UI perspective and simpler to implement correctly. I'm still unconvinced it's useful enough to implement but if done that way I'd shrug my shoulders and give a weak thumbs up since it is marginally useful and doesn't overly complicate the code or introduce hard to document behavior.

[mqudsi]

Would it be better to allow read to take no arguments, and echo to standard output in that case?

Fwiw, that's what I originally presumed read did.

[krader1961]

Fwiw, that's what I originally presumed read did.

That would have been the reasonable thing to do but instead it simply discarded the input. See issue #4220.

[krader1961]

Also think about how this feature interacts with read --array regardless of the previous comments.

[mqudsi]

The branch has been updated per the discussion above. read, when called without any parameters, now reads directly to stdout. This resolves

• mixing of reading to variables and stdout
• multiple reads to stdout
• stdout in array mode
• what to insert as a delimeter if a custom delimiter is used
• etc

Additionally, the documentation has been updated to reflect the changes to read. Feedback appreciated.

[mqudsi]

Fixed unit tests for read invoked without parameters and will merge into master. Thanks, everyone.