I have a USB LTE modem connected to my Raspberry and I need to read replies sent via serial line, generated by requests sent using the "echo" command.
Example:
cat /dev/ttyUSB0 &>> /ttyUSB0_logs &
echo "AT+csq" > /dev/ttyUSB0
echo "AT+cgreg=2" > /dev/ttyUSB0
echo "AT+cgreg?" > /dev/ttyUSB0
The problem is, although the "cat" command should run on the background and all output is directed to the file, script still freezes at this point. If I use the first command outside of the script, it works as I expect - it stores all output to the file ttyUSB0_logs on the background and I can use the received data for other operations. The question is - how can I integrate the first command to the script to get it work this way? Thanks a lot.
you want:
cat /dev/ttyUSB0 >> /ttyUSB0_logs &
if that doesn't work, you should double check what is actually freezing. you can put set -x at the top of the script to get tracing output.
Related
I began with playing ctfs challenges, and I encountered a problem where I needed to send an exploit into a binary and then interact with the spawned shell.
I found a solution to this problem which looks something like this:
(echo -ne "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\xbe\xba\xfe\xca" && cat) | nc pwnable.kr 9000
Meaning:
without the "cat" sub-command, I couldn't interact with the shell, but with it, i now able to send commands into the spawned shell and get the returned output to my console stdout.
What exactly happens there? this command line confuses me
If you just type in cat at the command line, you'll be able to see that this command simply copies stdin to stdout one line at a time. It will carry on doing this until you either quit with Ctrl-C or send an EOF with Ctrl-D.
In this example you're running cat immediately after successfully printing the payload (the concatenator && tells the shell to run the second command only if the first command has an exit code of zero; i.e., no error). As a result, the remote terminal won't see an EOF until you terminate it as described above. When this is piped to nc, everything you type in is sent via cat to the remote server, and everything it sends back appears on your stdout.
So yes, in effect you end up with an interactive shell. You can get pretty much the same effect on your own machine by running cat | sh.
I am trying to start a number of jobs in different screens from a shell script. Each job will read in a different value of a parameter from a premade input file and run a simulation based on that value, then tee or > the output to a differently named file. So in a do loop around all the jobs, job 40 on screen "session40" will read in line 40 of the input file, run the simulation, and output to output40.dat, for example. (I am basically trying to run a few jobs in parallel in a very elementary way; it appears my computer has plenty of RAM for this).
I am encountering the issue that the > and | tee commands do not seem to work when I use "exec" to run a command on the remote screen, despite having attempted to start a bash shell there; when I use these commands, it just prints to standard output. Although these commands do work with the command "stuff," I do not know how to pass the job number to stuff, as it appears to only work with string inputs.
The current attempted script is as follows. I have replaced the simulation script with echo and > for a simpler example of the problem. Neither of the last two screen lines work.
for i in 1:10; do
screen -Sdm session$i bash
screen -S session$i -X exec echo $i > runnumber$i.output (method 1)
screen -S session$i -X stuff $'echo $i > runnumber$i.output\r' (method 2)
done
Might there be an easy fix?
I've been trying to send commands to an ESP8266 using the terminal on OSX. I've been able to open the nodemcu interface using screen and send commands successfully, but when I try and send commands via echo (turning the on board LED on):
echo "gpio.mode(3,gpio.OUTPUT) gpio.write(3,gpio.LOW)" > /dev/cu.SLAB_USBtoUART
the command executes but nothing happens. However if I have a second terminal running:
cat /dev/cu.SLAB_USBtoUART
to read the console the echo command executes and the light turns on.
I've been able to run the command on ubuntu (changing the /dev/ path) and it worked without the second terminal. I've found using screen that any command executed via echo without the cat terminal being open just sends the first letter. I've also found the same problem using printf instead of echo.
In bash how can I issue a command to a running process I just started?
For example;
# Start Bluez gatttool then Connect to bluetooth device
gatttool -b $MAC -I
connect # send 'connect' to the gatttool process?
Currently my shell script doesn't get to the connect line because the gatttool process is running.
If you simply want to send the string "connect\n" to the process, you can use a standard pipe:
echo "connect" | gatttool -b $MAC -I
If you want to engage in a more complex "conversation" with the gatttool process, take a look at the expect (1) and chat (8) tool, which allow you to send a sequence of strings, and wait for certain responses.
If you'd prefer a slightly "lighter" way of piping you could use a heredoc such as in:
gatttool -b $MAC -I <<EOF
connect
(...)
EOF
Everything contained between the two EOF tags will be piped to the command's input. I believe this will not allow you to interact with the command whilst between the EOF tags so, as mentioned in the previous answer, you might want to consider using expect if you need to act upon the commands' output before sending something back to it.
echo -ne "ATZ\r\n" > /dev/ttyUSB0
echo -ne "AT+CMGF=1\r\n" > /dev/ttyUSB0
echo -ne "AT+CMGS=\"888XXXXXXX\"\rhello\x1a\n" > /dev/ttyUSB0
Since CMS ERROR-96 is for mandatory information missing.
No, you cannot send AT commands in this way. Start by reading the V.250 (all of chapter 5) and 27.005 specifications (the AT+CMGS command), links are in the tag info page. Those documents will teach you a lot with regards to AT command handling, syntax and behaviour.
The worst mistake is to send AT command lines without waiting for the final result code. In the same way you would not write a HTTP client that totally ignores responses from the HTTP server, you should not send AT commands and totally ignore responses from the modem.
And for the AT+CMGS command you have to wait with sending the sms payload data until after you have received the "\r\n> " prefix (see the first part of this answer for details).
Other things, AT command lines should be terminated with \r only and not \r\n. Opening and closing the modem device over and over again like multiple shell command redirects will cause might be an issue. That totally depends on the specific modem, and there is no guarantee that this will work reliably.
To address these last points I wrote the atinout program to make sending AT command from the command line simple and reliable. The first two AT commands can be sent as
$ echo ATZ | atinout - /dev/ttyUSB0 -
ATZ
OK
$ echo AT+CMGF=1 | atinout - /dev/ttyUSB0 -
AT+CMGF=1
OK
$
or alternatively
$ echo ATZ > commands.txt
$ echo AT+CMGF=1 >> commands.txt
$ atinout commands.txt /dev/ttyUSB0 output.txt
but for AT+CMGS I guess you have to use expect for the time being (in the future atinout will have a companion program specifically for sending AT+CMGS).