Why is this module impeding me to slurp from tty?

[trufae]

What's the point of behaving differently depending if stdin is a terminal or not? I think this is not the intended default behaviour and it should be left optional to the user. But if I run getStdin() i expect to slurp until EOF happens, even if thats typed by the user or coming from a pipe.

https://github.com/sindresorhus/get-stdin/blob/master/index.js#L34

[sindresorhus]

What's your specific use-case? The check was added for convenience: #1

[sindresorhus]

// @Qix-

[trufae]

to behave like a cat

meow

[Qix-]

Yeah to be honest this is why I don't use many stdin wrappers - @trufae has a valid usecase: most UNIX utilities that read from standard input and do some sort of on-the-fly manipulation will hang if they're not given anything.

Just a few off the top of my head:

• cat
• grep
• sed
• rev
• head / tail
• uniq
• sort

etc. Type any of them by themselves and they'll wait for an EOF.

Some users are definitely going to want to be given a filename (or I'm sure some users will want to accept - as a 'filename' to explicitly indicate stdin), or if they're not given a filename they'll default to reading stdin and wait until EOF is sent (Ctrl+D on UNIX or Ctrl+Z on Windows).

I think it's the correct thing to do for this module to at least have an option for it (I know how much you like more options, though). It's a huge convention for transformative/filter-type programs.

[trufae]

Also, it be ideal to have an option to reopen the stdin after getting closed, this is handy for use cases like: - slurp file from stdin, and then open a curses UI which requires stdin to work

…

On 21 Apr 2017, at 14:14, Josh Junon ***@***.***> wrote: Yeah to be honest this is why I don't use many stdin wrappers - trufae has a valid use-case: most UNIX utilities that read from standard input and do some sort of on-the-fly manipulation will hang if they're not given anything. Just a few off the top of my head: cat grep sed rev head / tail uniq sort etc. Some users are definitely going to want to either be given a filename, or if they're not given a filename (or I'm sure some users will want to accept - as a 'filename' to explicitly indicate stdin) they'll default to reading stdin and wait until EOF is sent (Ctrl+D on UNIX or Ctrl+Z on Windows). I think it's the correct thing to do for this module to at least have an option for it (I know how much you like more options, though). It's a huge convention for transformative/filter-type programs. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Qix-]

@trufae Not sure about that being an option in this module, personally. I think you can probably just do process.stdin.resume() or something like that and then use whatever curses application you want following that.

[trufae]

doesn't seems to work

[trufae]

You cant resume a closed descriptor

…

On 21 Apr 2017, at 16:20, Josh Junon ***@***.***> wrote: @trufae Not sure about that being an option in this module, personally. I think you can probably just do process.stdin.resume() or something like that and then use whatever curses application you want following that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[nelsonpecora]

I think this is messing with inquirer prompts because they're relying on stdin.

[ks07]

Agreed with @Qix- This check prevents the module from being useful for replicating standard unix command-line utilities, and there is no option to change this behaviour. I can't think of many cases where if I was writing a utility that takes input on stdin I'd want that utility to receive an empty string if ran in a TTY context - the developer is then forced to implement a different input handling method for that case (which could well be problematic if you took the immediately obvious route of checking for an empty string), or abandon this module entirely.

To preserve backwards compatibility, this should be added as an argument to the functions provided.

[nickserv]

This should be implemented, I thought this was a bug. I understand the check was added for convenience but the library should behave like other Unix tools and behave more explicitly by default. I'm not against having an option for bringing back the old behavior, but the default could be changed in a major version.

[Berkmann18]

I agree with most people here, not being able to read from the STDIN and just being restricted to the piped one is quite inconvenient and take away the big advantage that this package has over packages like readline.