sindresorhus/get-stdin

Why is this module impeding me to slurp from tty?

trufae opened this issue · 13 comments

trufae commented

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 commented

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

trufae commented

to behave like a cat

meow

  • 😄6
Qix- commented

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.

  • 👍8
trufae commented
Qix- commented

@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 commented

doesn't seems to work

trufae commented
nelsonpecora commented

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

ks07 commented

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.

  • 👍6
nickserv commented

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.

  • 👍4
Berkmann18 commented

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.

prantlf commented

I tried the moos fork supporting TTY, but it does not work with recent Node.js versions. I found that the EOF character coming after EOLN is not passed as a new chunk to the readable event handler. It is just included in the last chunk. Correcting the EOF handling allowed me to get the TTY support working in my fork with recent Node.js versions too.