-
Notifications
You must be signed in to change notification settings - Fork 28
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
Speak stdin/stdout #2
Comments
Could you elaborate what you mean with "speak"? |
Just read from stdin as you'd expect the tool to. The complications there are how this actually gets used by the program, as I can imagine two use cases: The simpler, but less useful, making stdin available in the command context:
The more complicated-but-useful, making it available in the command context:
Or something like that. Does that make sense? |
Yeah, makes sense, although that's very much already available in the On Unix this could also be accomplished with:
Could you explain what you have in mind for stdout? Let Loop reuse the output of the command it executes? |
This could be accomplished like you described, but I find that to be a pretty hideous solution. The goal of the tool is to make it easy and intuitive to write loops for common scenarios, so it should be able to read from stdin directly without the need for any more tools (die, xargs, die!) stdout is probably more complicated and I probably don't know enough to get it right on the first try. I'm imagining something like..
I don't know if the pipeing could happen upon every iteration of the loop, or if it would have to be buffered and then all sent out at once over newlines. I imagine the latter, unfortunately. |
Gah, there are even more problems with that.. ex, does it execute
or
Even more annoying, the whole thing is made easier simply by |
Yeah, I agree about stdin and the one-liner, it's also not very platform agnostic. About the stdout, piping doesn't work like that, you can't spawn multiple processes on a single pipe like that (unless you use something like xargs). There might be a really advanced idea I'm not familiar with out there, but I think that's a dead end. Something like a specific flag for an output using command could work though, like the |
Ah yes, so you noticed the problem, indeed like you said, the command piped to would get all output in one execution. For loops where the command generates output that you want to use, instead of being able to use the $ITEM or $COUNT value directly in the loop command, the Mind you, on a unix platform, I would personally still tell people to use xargs, just because I'm old-skool like that; do one thing and do it well :D |
For the purposes of this ticket, I think that I think I don't think I really see much benefit to |
I'm thinking more about that |
Yeah, true. Although that might get just as ugly as my paste -sd example :) |
I implemented some versions of the stdin stuff. Not sure if I'm happy with it yet. Examples:
and:
It can now also read directly from the keyboard with
|
The problem as it stands is that it can't support the trivial use case:
since "hello" is only once, it'll only execute one time. |
That depends on if you'd like this to happen:
|
I'm not sure. Does that seem like the right behavior to you? Perhaps that should be defined with an additional argument, ex:
Not sure about that. Need a better concept for it maybe. |
Just going to add to this (and #20) as I installed loop because it looked like the perfect solution to testing the HTTP status code of a page while I work on it. Basically the CLI equivalent of mashing reload:
Which returns:
Once and then errors out with the same |
I think stdin will be easy but stdout will be hard.
The text was updated successfully, but these errors were encountered: