-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Ignore stdin when STDIN is closed #660
Comments
I agree - the default should be to use explicit args over implicit stdin; the current behavior of throwing an arbitrary error is quite confusing and surprising. The objection raised in #150 is that the tool shouldn't try to guess, but most shell utilities already give priority to local or explicit context over global or implied context, and that's the behavior expected by the vast majority of developers. For example, if I run With httpie, the data args are just as explicit as the author flag above, whereas the stdin could come from anywhere, including outside the script entirely and in non-obvious ways: http get https://google.com x=y There is no local redirect of stdin, stdin is never explicitly used in any way. If I run the script directly, it works as expected. But if I run in a watch loop... fswatch script.sh | xargs -n1 -I{} bash script.sh Now the script breaks for what appears to the user to be no reason - and in my case the fswatch command was part of a larger suite of CLI helpers, making the breakage seem even more arbitrary and confusing. |
The
This leaves us with the "hanging" issue when no data args are specified and httpie is called with redirected $ crontab -l
0 * * * * http httpbin.org/get # this will hang
0 * * * * http --ingore-stdin httpbin.org/get # this won't I think the design choice to automatically read To completely get rid of this issue, it would require changing the handling of One thing that can be done to improve the UX while maintaining backwards compatibility could be to write a warning message to |
This no longer throws an error: $ echo stdin_data | http httpbin.org/post cli=data 0<&- |
I ran into the bug reported in #150 and subsequently worked around in f7b703b but under different circumstances.
In my case,
http
was being invoked as part of a BsdMakefile script.bmake
helpfully buffers IO when performing a parallel make (make -jX
) so that lines from various rule outputs are not intermixed. httpie was detecting this asstdin
and reporting an error about conflicting input streams (command line and STDIN).Before looking up #150 or even Googling the issue, I correctly surmised that was the case, and attempted to work around it by explicitly closing
STDIN
:Is it possible for httpie to distinguish between a closed and redirected stream?
The text was updated successfully, but these errors were encountered: