Hm, do you have any examples handy? It's not that I don't believe you, it's just that in all the years I've been using this, it has always worked. Granted, I'm only using it for reading data, not for saving stuff to /dev/stdin, which would obviously fail.
I want stdin to work. I also want specifying a file name to work. I think supporting both is good UI design, and follows the principle of least surprise.
If you do this, and you should, you should probably set up stdin in the child to be a pipe, not whatever stdin of the parent is, implied by the comment about /dev/null.
which is a common way of doing it (for any command with any inputs and outputs, not just the above ones), i.e.:
command < input_source > output_dest
All three pv command invocation variants, the one here and the two above, work. And it becomes more clear why they are the same, when you know that the redirections are done by the shell + kernel, and the command (such as pv) does not even know about it. So in all three cases, it does not see the redirections, because they are already done by the time the command starts running (with its stdin and stdout redirected to / from those respective sources). And that is precisely why the command works the same whether it is reading from the keyboard or a file or pipe, and whether it is writing to the screen or a file or pipe.
to be particularly useful in the past for pushing generated data into something that doesn't accept - as an alias for STDIN. I'm not sure if it's a different way of expressing one of the listed items though; iirc it creates a temporary fifo
Do keep in mind that /dev/stdin{out,err} aren't completely portable. Bash emulates them if they don't exist, but this usage bypasses Bash. So there are unix like platforms where this trick won't work. They do, though, seem to be supported on the ones that are most popular now (Linux, MacOS, FreeBSD).
Since stderr (aka &2 aka /dev/pts/whatever) is opened read-write, you can dup it onto stdin to recover the terminal. Ideally, every editor should just support reading from stdin, interacting via stderr[0], and writing to stdout as a command line option though.
Oh awesome!! I've just added Trealla to my issues list to add it to Runno.
If you go into settings you can switch stdin echo on/off. I have stdio devices set up to return their file type as "Character Device" (see: https://github.com/taybenlor/runno/blob/main/packages/wasi-m...). It seems like some binaries handle this well and act like they are directly connected to the TTY (e.g. my quickjs example). Not sure how they determine that. I'm very much coming at this from a web-developer interested in WASI direction, and not from any experience with OSes or linux.
reply