I'm creating a command line terminal/parser that displays a prompt and takes commands from the user. I do this with a simple:
'prompt: loop{
# display prompt, stdin.read_line, and execute commands based on input...
}
What I'd like to do is have the ability to output text based on some trigger (timer or otherwise) that will "interrupt" the prompt but then immediately go back to accepting stdin. It might look something like this:
[11:39:00] Enter your command:
Alert! AAPL has decreased by greater than 5%
[11:40:00] Enter your command:
Basically, the loop needs to keep running and checking for events, while also accepting user input.
What's the best way to accomplish this?
Related
I have a python script that takes some inputs from the user & then executes the code based on the input. The code takes some time to complete; during this code runtime the user can close the terminal(the code is run from a Linux machine)
As soon as the user closes the terminal the script stops as well. I know there are options like nohup but it wouldn't accept any input(where input is required in my script).
How can I fix this?
Requirement is -
Run the script, enter the inputs
Let the code run in the background even if the terminal is closed
Also is there a way to write whatever is being printed in the terminal(during the script runtime) to some file
Linux's screen tmux served my purpose.
There is a work around possible,
you can split your programm into two parts.
And start your background task with:
import os
usr_inp=input("test input: ")
os.popen(f"python3 background_task.py {usr_inp} &")
This should start the other programm in the background, there you can use the input over the sys.argv[1] variable.
(Usually it's not recommended using os.popen)
I have a script that runs a program that generates an email and then waits for the user to input information from that email. Because of this, the information is not available to pipe to the program on execution. It has to be done after it's running already.
I've tried a number of the different method suggestions, redirecting to the terminal (echo or cat > /dev/pts/#), mkfifo, expect, etc. Most of these methods are successful in actually sending the information to the target terminal - I actually see the information show up there. But there doesn't seem to be a way to send the equivalent of someone pressing the enter key.
Newline (using echo -en) or \n inside of the information send actually makes the cursor move in the target terminal - but it's not the same as actually pressing enter. It just scrolls the screen down one line. If I select the terminal window and press enter, it then accepts the input.
How can I do this from a different terminal (or can I?)
Or better yet, is there a way from the same script that's launched the program now waiting for input to send the program input?
Most of what I've seen has gone the route of using another terminal to try to send the information to the program.
Flow:
Simple similar example is if you were running a shell script that during its execution, runs a program that generates a PIN sent to your email, and then waits for the PIN to be entered before continuing.
In terminal 1, a bash script is run - one of the steps this script does is launch a program that generates an email and then sits at a prompt, waiting for the user to provide input (data from the email sent).
In terminal 2 (or if you can do this through terminal 1 somehow), take the value from the email and input it to the program in terminal 1, including pressing the enter key, so the program sees this value as actually entered and the program can complete its execution.
script in terminal 1:
...
if [ -f $progamToRun ]; then
$programToRun # This program sends the email and prompts the user for information from the email. It waits here...
# once information from email is entered, continue executing commands here
fi
script in terminal 2:
...
# monitor email
# retrieve information from email
# send information to program in terminal 1 that is waiting for this input
# exit script
The steps for the script in terminal 2 are working - and all of the methods I've tried to send the information to the program in terminal 1 haven't worked - that is to say, even if the information appears in the terminal through STDIN, etc. the application running doesn't recognize it as input so it's still sitting in the wait state.
I attempted to use netcat as suggested, but that's failing differently.
In terminal 1 I ran:
cat /tmp/nctest | /tmp/docl.sh -i 2>&1 | nc -l 127.0.0.1 8080 > /tmp/nctest
docl.sh contains one line, the application I am running to generate the email and wait.
In terminal 2 I ran:
nc 127.0.0.1 8080 <information from email>
When I run this in terminal 2, I immediately get the error from the program run in the script in terminal 1 that it failed. I tried this:
nc 127.0.0.1 8080
by itself to see if there was an issue passing the information on the same line I run nc, but get the same result. It's like the first terminal's nc command actually runs the application and then somehow bypasses or processes the prompt, so it's gone before I can enter the information from the email.
I also tried the command in terminal 1 without the -i and without the 2>&1, but there was no difference in the result.
I'm working on a shell script, which has lot of network calls and installations. When it is executed I need to enter yes/no for each prompt. Which is fine.
But now i have a requirement to run it as cron. In which case i won't be able to give inputs for each of the prompt that comes up.
Is there any way I can automate this or have some mechanism of knowing in script that a prompt has come up?
Use the yes command to answer interactive prompts,
yes Y | ./script.sh
The above syntax constantly puts the string Y to all your prompts. You can pass the string as you need after yes.
You can also use expect tool meant for this, but you need to know the exact prompt message for capturing and responding to it accordingly. If your prompt is simple and just need a simple input to pass yes would be the right tool.
Also you can use bash built-in printf, but you need to add the responses manually depending upon the number of prompts you have to respond to, e.g.
printf 'Y\nY\nY\n' | ./script.sh
to send response as Y for three prompts. As again, to avoid doing this manually, prefer using the yes command.
Trying to make a small script and cron job it in order to automate a task. Said script runs another script which has already been created, grabs the output, emails to specified recipients, and cleans up the output. I've got it almost down however am running into one major issue. The script that mine is running has a menu on the outset. That is to say, running the script by itself manually, i would have to select option 1 in order to get the output i want (the only other option, 2, is quit.)
How can I automatically enter (or simulate entering) the value 1 into the other script, so it does not hang when in a cron job waiting for user input?
Is there a sane way to do this?
Thanks in Advance.
You could try something as simple as using yes | command if answering yes is all that is needed. Otherwise you probably want to use expect to drive the imaginary keyboard for you.
http://expect.sourceforge.net/
Using autoexpect to record your session is a convenient way to come up with rough draft expect scripts as well.
I have a BASH script that runs on bg and print messages to the user when according to system events.
My problem is that after the echo of these messages, the user need to press on the ENTER key in order to get back to the prompt line.
Adding new line to the printed messages didn't help since it still comes from the bg and not from the user shell.
Does anyone have an elegant & simple solution to get the user back to the prompt line?
I will appreciate any help here..
You don't need to press enter to get to a prompt. You are still at the prompt that was there before the output was printed. Try just entering a command and hitting enter. (You can also hit ctrl-l to clear the screen instead of hitting enter to input an empty command.)
The problem here is that the background/alternative process has no relationship to the running shell session and so it is simply writing output to wherever the terminal sticks it. The process might be able to use control sequences to control the output location (but I don't know if this actually works).
Other than that there isn't much to be done about this that I'm aware of. And it isn't a problem in any real way.