Linux:is there a way to paste and go?
Hi guys,
I've written a python script to work with data, the script prompts users for some input , said user then copy and pastes the input into the program.
Time is of the essence with this program, obviously we as humans are bound to how fast we can smash the enter/return key, but ideally I need the terminal to run the input as soon as I paste it inside of my python script.
Question is; if I open up a terminal specifically for the script, is there any flags I can set to allow for this?
Or would this come down to me programmatically doing this in Python, maybe the program could detect when input has been supplied and automatically simulate a return?
I've written a python script to work with data, the script prompts users for some input , said user then copy and pastes the input into the program.
Time is of the essence with this program, obviously we as humans are bound to how fast we can smash the enter/return key, but ideally I need the terminal to run the input as soon as I paste it inside of my python script.
Question is; if I open up a terminal specifically for the script, is there any flags I can set to allow for this?
Or would this come down to me programmatically doing this in Python, maybe the program could detect when input has been supplied and automatically simulate a return?
Last edited on
How does it know when you are done typing?
couple of off the cuff ideas with little info on what python has but assuming it can...
- can you detect a copy into the copy/paste buffer and just see if its valid, if so, grab & go? Your program would become a reactive listener to the copy/paste system.
- can you use something like sshkeyboard similar to getch to pull characters as they come in rather than wait on the enter key? You need a 'gaming' solution ... the ability to react to the keyboard without enter keys, like you would if using wasd to move in a game... surely py has something LIKE this out there, IF reacting to a key is valid behavior for your program
- it may be possible to use pipes or some unixy thing in a shell script to deal with this
couple of off the cuff ideas with little info on what python has but assuming it can...
- can you detect a copy into the copy/paste buffer and just see if its valid, if so, grab & go? Your program would become a reactive listener to the copy/paste system.
- can you use something like sshkeyboard similar to getch to pull characters as they come in rather than wait on the enter key? You need a 'gaming' solution ... the ability to react to the keyboard without enter keys, like you would if using wasd to move in a game... surely py has something LIKE this out there, IF reacting to a key is valid behavior for your program
- it may be possible to use pipes or some unixy thing in a shell script to deal with this
Last edited on
On Windows you could wait for the user to press a key and then read directly from the clipboard.
@Jonnin really good thinking!
I like both ideas, I think the penultimate idea you mentioned may be easier to implement but then again, both are great starting points.
@helios if worse comes to worst, I may actually change to windows and try that. I'm guessing you would use the winapi or winapi wrapper assuming if python has one? or would there be a simpler way to read from the keyboard(using the OS module)?
I like both ideas, I think the penultimate idea you mentioned may be easier to implement but then again, both are great starting points.
@helios if worse comes to worst, I may actually change to windows and try that. I'm guessing you would use the winapi or winapi wrapper assuming if python has one? or would there be a simpler way to read from the keyboard(using the OS module)?
Last edited on
I'm bemused. Why are you cut'n'pasting anything? Python is perfectly capable of taking input directly from the terminal. Just use "input" - you don't need anything from the OS module.
Last edited on
but is there a way to take input without me hitting the enter key? i.e. pasting my data into my script when prompted and executing the input once it's pasted
Last edited on
Pasting just simulates pressing the keys. The program has no awareness of whether the input came from your keyboard or from a clipboard. Thus, the program would have no way to know when you've finished entering the data.
What you can do is copy including a newline. When you paste on the console the console will simulate the enter key as well.
What you can do is copy including a newline. When you paste on the console the console will simulate the enter key as well.
| adam2016 wrote: |
|---|
| but is there a way to take input without me hitting the enter key? |
You have to let the computer know that your input has finished. Otherwise, it wouldn't know whether you had stopped typing or just gone off to have a cup of tea. What's so time-consuming about hitting the enter key?
Even if you used cut'n'paste then you would still have to signal the script to go ahead and process it.
Last edited on
but is there a way to take input without me hitting the enter key?
Yes, but you still have to solve the problem we stated: how do you know when its done, or whether the input was meant for YOUR program. On an embedded/dedicated machine, that problem goes away - everything is meant for your program there. A machine can be dedicated for a time as well, by simply having the user not do other stuff and understand that doing other stuff breaks things -- there are situations where that may be OK (eg in a lab), but general purpose software isn't one of them.
I mean stealing directly from the copy/paste buffer is the most efficient way if the user is providing it by copy/paste mechanics. But you MUST know that the data is for your program or not. Its more efficient simply because the paste side is never needed, you intercept and process it upon copy. On windows for sure, but I believe also on unix, the act of printing to the screen is actually relatively slow. If you can avoid that entirely, (pasting into a console does not avoid it), it will run faster. Try it sometime, make a program that writes text to the screen, a few MB worth. Run it with a chrono timer and see how long it takes end to end. Repeat this, but now redirect the output to a text file from the console. It will run much, much faster.
Those are pretty basic things to try. But worrying about speed with a human in the loop is folly from the get-go. The computer is so much faster than the human... you are on the right track to make the human input as streamlines as possible from the keyboard to chair ... but even so, humans are slow. If you can instead do a supervised system where the data flows without the human, and the person just fixes things if something goes wrong or configures the data flow before turning it on ... dunno what you are doing to say but eliminate the person if you want it to run faster.
Yes, but you still have to solve the problem we stated: how do you know when its done, or whether the input was meant for YOUR program. On an embedded/dedicated machine, that problem goes away - everything is meant for your program there. A machine can be dedicated for a time as well, by simply having the user not do other stuff and understand that doing other stuff breaks things -- there are situations where that may be OK (eg in a lab), but general purpose software isn't one of them.
I mean stealing directly from the copy/paste buffer is the most efficient way if the user is providing it by copy/paste mechanics. But you MUST know that the data is for your program or not. Its more efficient simply because the paste side is never needed, you intercept and process it upon copy. On windows for sure, but I believe also on unix, the act of printing to the screen is actually relatively slow. If you can avoid that entirely, (pasting into a console does not avoid it), it will run faster. Try it sometime, make a program that writes text to the screen, a few MB worth. Run it with a chrono timer and see how long it takes end to end. Repeat this, but now redirect the output to a text file from the console. It will run much, much faster.
Those are pretty basic things to try. But worrying about speed with a human in the loop is folly from the get-go. The computer is so much faster than the human... you are on the right track to make the human input as streamlines as possible from the keyboard to chair ... but even so, humans are slow. If you can instead do a supervised system where the data flows without the human, and the person just fixes things if something goes wrong or configures the data flow before turning it on ... dunno what you are doing to say but eliminate the person if you want it to run faster.
Last edited on
Dealing with raw keyboard inputs is the usual way.
How that is implemented depends on the OS and programming language. Usually a third party library. C++ doesn't have AFAIK stdlib support.
How that is implemented depends on the OS and programming language. Usually a third party library. C++ doesn't have AFAIK stdlib support.
Topic archived. No new replies allowed.