Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why is this module impeding me to slurp from tty? #21

Open
trufae opened this issue Apr 21, 2017 · 13 comments
Open

Why is this module impeding me to slurp from tty? #21

trufae opened this issue Apr 21, 2017 · 13 comments

Comments

@trufae
Copy link

@trufae trufae commented Apr 21, 2017

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
Copy link
Owner

@sindresorhus sindresorhus commented Apr 21, 2017

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

@sindresorhus
Copy link
Owner

@sindresorhus sindresorhus commented Apr 21, 2017

// @Qix-

@trufae
Copy link
Author

@trufae trufae commented Apr 21, 2017

to behave like a cat

meow

@Qix-
Copy link

@Qix- Qix- commented Apr 21, 2017

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
Copy link
Author

@trufae trufae commented Apr 21, 2017

@Qix-
Copy link

@Qix- Qix- commented Apr 21, 2017

@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
Copy link
Author

@trufae trufae commented Apr 22, 2017

doesn't seems to work

@trufae
Copy link
Author

@trufae trufae commented Apr 23, 2017

@nelsonpecora
Copy link

@nelsonpecora nelsonpecora commented May 18, 2017

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

josephfrazier added a commit to josephfrazier/prettier that referenced this issue Jun 14, 2017
This uses [get-stream] instead of [get-stdin], since the latter just
gives an empty string if process.stdin is a TTY
(see sindresorhus/get-stdin#21)

[get-stream]: https://github.com/sindresorhus/get-stream
[get-stdin]: https://github.com/sindresorhus/get-stdin
azz added a commit to prettier/prettier that referenced this issue Jun 14, 2017
This uses [get-stream] instead of [get-stdin], since the latter just
gives an empty string if process.stdin is a TTY
(see sindresorhus/get-stdin#21)

[get-stream]: https://github.com/sindresorhus/get-stream
[get-stdin]: https://github.com/sindresorhus/get-stdin
@ks07
Copy link

@ks07 ks07 commented Jul 28, 2017

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.

@nickmccurdy
Copy link

@nickmccurdy nickmccurdy commented Nov 3, 2017

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
Copy link

@Berkmann18 Berkmann18 commented Jan 10, 2019

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
Copy link

@prantlf prantlf commented Mar 21, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants