I have an expect bash to enter BIOS setup when machine bootup via serial redirection of that target machine. The following is my script where i use spawn to read & write the serial port, but the keystroke (Del) used to enter BIOS is not respond in that script
set timeout -1
match_max 100000
set port /dev/ttyUSB0
set rate 115200
exec stty -F $port $rate
spawn -open [open $port w+]
expect "American Megatrends"
sleep 1
send -- "^\[\[3~"
send_user "\nok\n"
The last line "ok" is printed that's means my keyword is expected but it doesn't go into BIOS setting
Meanwhile in another script where it read and write with screen /dev/ttyUSB0 115200 able to send the keystroke and enter BIOS setup successfully.
Anyone could help on this?
Thanks.
^[ means CTRL-[ which is the ESC char (0x1b or 033) so you can try like this:
send -- "\033\[3~"
Related
I want to echo something from my Ubuntu host to some device.
It works well if I use putty or minicom.
However, it doesn't work if I do echo from the shell terminal:
echo "cmd" > /dev/ttyUSB0
From my device, I saw that the first letter of the cmd is received correctly while the second one received is ASCII bigger than 200. I also have tried to use the "stty" command to adjust the serial communication settings but didn't help. Does anythone know why?
Thanks,
First You need to set the tty device settings and then you need to transmit the data whatever you want
stty -F /dev/ttyUSB0 9600 -parity cs8 -cstopb
OR
stty -speed 9600 < /dev/ttyUSB0
Now Send data:
echo "cmd" > /dev/ttyUSB0
I am working on a CentOS box.
What I expect: To run my own CLI/setup on startup instead of login prompt on serial console (telnet).
What I did so far:-
I changed call to "agetty" command in serial.conf and serial-ttyUSB0.conf files under /etc/init/, as follows:-
exec /sbin/agetty -n -l <path-to-my-custom-script> ........
My custom.sh script is:-
#!/bin/bash
LOOP_FLAG=0
while [ $LOOP_FLAG -eq 0 ]; do
for TTY in /dev/ttyS0 /dev/tty0; do
echo "Please choose to enter in 'setup' or 'cli'. (s/c)? " > $TTY
done
read sc
case $sc in
[Ss]* ) LOOP_FLAG=1; <some-executable-cli-file-path>; break;;
[Cc]* ) LOOP_FLAG=1; <some-executable-setup-file-path>; break;;
* ) for TTY in /dev/ttyS0 /dev/tty0; do
echo "Please press 's' or 'c'." >$TTY
done;;
esac
done
But when system boots, on a telnet session, I could only see the "Please choose to enter.." question on screen and after that I couldn't able to type anything on console.
One more update:
If I run the above agetty command on shell prompt as it is (say from ssh session), then it works fine on serial console (telnet). But, from the above startup scripts, it doesn't work.
Can anybody help me out with this?
Thanks in advance.
-Neo
Sorry I'm a few years late. Hopefully this will be of help for people searching for solution to this problem in the future.
The issue lies here:
-n, --skip-login Do not prompt the user for a login name. This can be used in connection with -l option to invoke a non-standard login
process such as a BBS system. Note that with the -n option, agetty
gets no input from user who logs in and therefore won't be able to
figure out parity, character size, and newline processing of the
connection. It defaults to space parity, 7 bit characters, and ASCII
CR (13) end-of-line character. Beware that the program that agetty
starts (usually /bin/login) is run as root.
So you need to initialize the terminal yourself in the script you are replacing the login prompt with. I found the settings below work well:
/bin/stty -F /dev/ttyO0 115200 cs8 sane
Remember to replace the baud rate and terminal name to your own.
I'm using Expect to connect to my server over a (virtual) serial port. (HP iLo, to be specific)
When booting from a Linux OS ISO image, you eventually get to the 'boot:' prompt. When my server reaches that prompt, I would like to enter my own custom boot options and press enter. Easy, right?
This is how the boot prompt looks when you're watching my Expect script execute (looks normal):
boot:
However, I have not been able to match 'boot:'. Looking at the Expect Buffer in my logfile, this is what is being captured for that line:
ESC\[25;01HbbESC\[25;01HESC\[25;02HooESC\[25;02HESC\[25;03HooESC\[25;03HESC\[25;04HttESC\[25;04HESC\[25;05H::ESC\[25;05HESC\[25;06H ESC\[25;06HESC\[25;07H"
I think all those control sequences are screwing up my match. If you look closely 'boot:' is actually in there, but it's surrounded by what I believe are ANSI control sequences.
In fact, the logfile is absolutely full of ANSI control characters.
Relevant pieces of the Expect script I've been playing around with:
bash #] expect -d -c '
.....
# SSH to the Virtual Serial Port Management server
spawn ssh user#1.2.3.4
.....
# Access the Virtual Serial Port for the server being booted
send "vsp\r"
.....
# After rebooting the server, when the boot: prompt appears, enter boot options
expect {
"boot:" {send $bootOptions \r\n"}
timeout {send_user "Never found boot prompt\n"; send_user "$expect_out(buffer)"; exit 1}
}
.....
exit'
Any ideas about what the best way to handle those control characters would be? I've tried exporting TERM=dumb and TERM=vt1000 on the machine I'm running the script on. Didn't make much of a difference.
Not sure if this will help, but you could create a wrapper for ssh and exec that instead of ssh and then have
ssh <host> | perl -pe 's/\e([^\[\]]|\[.*?[a-zA-Z]|\].*?\a)//g' | col -b
perhaps take out the col -b which filters newlines if you don't need that.
I'm running ffmpeg on another machine for screen capture. I'd like to be able to stop it recording remotely. FFMPEG requires that q is pressed to stop encoding as it has to do some finalization to finish the file cleanly. I know I could kill it with kill/killall however this can lead to corrupt videos.
Press [q] to stop encoding
I can't find anything on google specifically for this, but some there is suggestion that echoing into /proc//fd/0 will work.
I've tried this but it does not stop ffmpeg. The q is however shown in the terminal in which ffmpeg is running.
echo -n q > /proc/16837/fd/0
So how can I send a character to another existing process in such a way it is as if it were typed locally? Or is there another way of remotely stopping ffmpeg cleanly.
Here's a neat trick I discovered when I was faced with this problem: Make an empty file (it doesn't have to be a named pipe or anything), then write 'q' to it when it's time to stop recording.
$ touch stop
$ <./stop ffmpeg -i ... output.ext >/dev/null 2>>Capture.log &
$ wait for stopping time
$ echo 'q' > stop
FFmpeg stops as though it got 'q' from the terminal STDIN.
Newer versions of ffmpeg don't use 'q' anymore, at least on Ubuntu Oneiric, instead they say to press Ctrl+C to stop them. So with a newer version you can simply use 'killall -INT' to send them SIGINT instead of SIGTERM, and they should exit cleanly.
Elaborating on the answer from sashoalm, i have tested both scenarios, and here are the results:
My experiments shows that doing
killall --user $USER --ignore-case --signal INT ffmpeg
Produces the following on the console where ffmpeg was running
Exiting normally, received signal 2.
While doing
killall --user $USER --ignore-case --signal SIGTERM ffmpeg
Produces
Exiting normally, received signal 15.
So it looks that ffmpeg is fine with both signals.
System: Debian GNU/Linux 9 (stretch), 2020-02-28
You can also try to use "expect" to automate the execution and stop of the program. You would have to start it using some virtual shell like screen, tmux or byobu and then start the ffmpeg inside of it. This way you would be able to get again the virtual shell screen and give the "q" option.
Locally or remotely start a virtual shell session, lets say with "screen". Name the session with -S option, like screen -S recvideo Then you can start the ffmpeg as you like. You can, optionally, detach from this session with a Ctrl+a + d.
Connect to the machine where the ffmpeg is running inside the screen (or tmux or whatever) and reconnect to it: screen -d -RR recvideo and then send the "q"
To do that from inside a script you can then use expect, like:
prompt="> "
expect << EOF
set timeout 20
spawn screen -S recvideo
expect "$prompt"
send -- "ffmpeg xxxxx\r"
set timeout 1
expect eof
EOF
Then, in another moment or script point or in another script you recover it:
expect << EOF
set timeout 30
spawn screen -d -RR recvideo
expect "$prompt"
send -- "q"
expect "$prompt"
send -- "exit\r"
expect eof
EOF
You can also automate the whole ssh session with expect, passing a sequence of commands and "expects" to do what you want.
The question has already been answered for Linux, but it came up when I was looking for the windows equivalent, so I'm gonna add that to the answers:
On powershell, you start the process like this:
$((Start-Process ffmpeg -passthru -argument "FFMPEG_ARGS").ID)
This sends back the PID of the FFMPEG process that you can store in a variable, or echo, and then you send the windows equivalent of sigint (Ctrl + C) using taskkill
taskkill /pid FFMPEG_PID
I tried with Stop-Process (which is what comes up when looking how to do this on Google) but it actually kills the process. (And yes, taskkill doesn't kill it, it gently asks the process to stop... good naming :D)
I have tty device in /dev , where I send AT commands. I want to read line by line and stop reading file after timeout.
You can use the program stty to configure the tty device. To see the settings for terminal /dev/ttyS0, try
stty -a -F /dev/ttyS0
The default settings regarding timeout are min = 1; time = 0, which means that the reading program will read until at least one character has been read and there is no timeout. Using e.g.
stty -F /dev/ttyS0 min 0 time 10
the reading program (e.g. cat) will finish reading after one second whether anything has been read or not. The unit for the parameter time is tenths of a second; you can check out man stty for more information.
Compiling some info from here, you can have a script in the sorts of:
#!/bin/bash
#SPECIFYING THE SERIAL PORT
SERIAL=ttyS0
#SETTING UP AN ERROR FLAG
FLAG="GO"
#OPENING SERIAL PORT FOR READING
exec 99</dev/${SERIAL}
#READING FROM SERIAL
while ["${FLAG}" == "GO" ]
do
#IF NO INPUT IS READ AFTER 5 SECONDS, AN ERROR FLAG IS RAISED
read -t 5 INPUT <&99
STATUS=$?
if test $STATUS -ne 0;
then
FLAG="ERROR"
fi
done
#CLOSING SERIAL PORT
exec 99>&-
While FLAG==GO, the script will read one line at a time from the serial port. The STATUS variable gets the return of READ command. According to the manual READ will return anything different than 0 if the specified timeout is reached; when that happens, FLAG is updated, exiting the read loop.