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 · 12 comments

Comments

Projects
None yet
7 participants
@trufae
Copy link

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

This comment has been minimized.

Copy link
Owner

sindresorhus commented Apr 21, 2017

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

@sindresorhus

This comment has been minimized.

Copy link
Owner

sindresorhus commented Apr 21, 2017

// @Qix-

@trufae

This comment has been minimized.

Copy link
Author

trufae commented Apr 21, 2017

to behave like a cat

meow

@Qix-

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Author

trufae commented Apr 21, 2017

@Qix-

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Author

trufae commented Apr 22, 2017

doesn't seems to work

@trufae

This comment has been minimized.

Copy link
Author

trufae commented Apr 23, 2017

@nelsonpecora

This comment has been minimized.

Copy link

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

Let `prettier --stdin` work with keyboard input
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

Let `prettier --stdin` work with keyboard input (#2147)
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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.