I have a serial usb device that is connected to a linux box and it works fine with serial communication programs, such as minicom.
For instance, within that program, I send the string "V" and I get back an answer: "UBW FW D Version 1.4.3".
Now, I'd like to do a shell script that could do the same, in order to test variables. I investigated the possibility to use minicom without being "interactive" but it seems is not possible. I also tried the obvious "echo V > /dev/ttyACM0" but had no luck as well.
Any idea of how can I send and receive strings to/from a serial device in such way I can use the received data in a shell script?
Thanks
In the olden days of modems, we would use the program 'expect' to send and receive data from the serial line. This doesn't exactly solve your problem, but might get you some of the way there.
Have a look at Use expect in bash script to provide password to SSH command
The atinout program does exactly what you are asking for. Example:
$ echo AT | atinout - /dev/ttyACM0 -
AT
OK
$
Now, from you example command and response, I see that your "modem" seems to able to configure or modify to not return the OK Final Result Code, and atinout absolutely needs that for its operation, so make sure the UBW behaves properly.
Related
I am required to read the serial number of connected J-Link (I use J-Link Compact Plus from Segger) via the command line.
I am using tools from Segger such as JFlash.exe and JLink.exe
I managed to find a way to read a serial number via JLink.exe by executing the following command:
JLink.exe -CommanderScript -CommandFile GetSerial.jlink
Where GetSerial.jlink is a custom file that I have created and it looks like:
ShowEmuList
exit
The response is as following:
The above method seems to work fine but I am not convinced that this is the most optimal way.
My questions:
Is it possible to read the serial number using JFlash.exe instead of JLink.exe. Since I use JFlash.exe from flashing, I would prefer to rely on a single tool instead of 2.
If the answer to above is no. I would like to know if there is any way to optimise the JLink.exe command to read the device serial number. I do not fully understand why do I need to pass GetSerial.jlink as an argument to the command. I would much rather prefer something like:
Jlink.exe -ShowEmuList
But the above does not seem to work:
Thanks in advance for the help.
I'm using go's exec Run command to get command output, which works great when the command 'Stdout' field is set to os.Stdout, and the error is sent to os.Stderr.
I want to display the output and the error output to the console, but I also want my program to see what the output was.
I then made my own Writer type that did just that, wrote both to a buffer and printed to the terminal.
Here's the problem—some applications change their output to something much less readable by humans when it detects it's not writing to a tty. So the output I get changes to something ugly when I do it in the latter way. (cleaner for computers, uglier for humans)
I wanted to know if there was some way within Go to convince whatever command I'm running that I am a tty, despite not being os.Stdout/os.Stderr. I know it's possible to do using the script bash command, but that uses a different flag depending on Darwin/Linux, so I'm trying to avoid that.
Thanks in advance!
The only practical way to solve this is to allocate a pseudo terminal (PTY) and make your external process use it for its output: since PTY is still a terminal, a process checking whether it's connected to a real terminal thinks it is.
You may start with this query.
The github.com/creack/ptyis probably a good starting point.
The next step is to have a package implementing a PTY actually allocate it, and connect "the other end" of a PTY to your custom writer.
(By the way, there's no point in writing a custom "multi writer" as there exist io.MultiWriter).
Hi I would like to create a small program that listens for copy comands copied content for later retrival in bash. Is it possible to listen to key strokes while still keeping the shell interactive? And how can this be don arcitectualy. I don't need the whole program just a hint at how it can be done. I have no preferance when it comes to language exept that it should be implemented in a scripting language or maby c++.
Pherhaps this needs to be written like a shell extension or somthing. just a hint would be fine.
Consider the way that the script program works (see man script). I havn't done this in a while, but basically you write your pseudo terminal in C and push that into the stream, then launch the shell.
See tcgetattr/tcsetattr, grantpt, unlockpt, and ptsname, with ptem, ldterm and possibly ttcompat to be pushed using ioctl.
A simpler, though less efficient, is to run script into a pipe and capture the output. You probably will need script -f to flush the buffer (I think the -f is only in the GNU version).
I have a script which solicits a numeric input from the user while booting the computer. The computer is running Fedora 16. It used work, on Fedora 13, but after the upgrade
read INTEGER
returns immediately, without catching any user input. I tried
read INTEGER
wait $!
but (predictably) that too doesn't work. The script is run from a systemd service file (see comments below). It must be run as root, and must started before the user logs in. It currently calls bash as its interpreter, but with some effort, that could be changed. Can anyone help return this script to normal?
Extra credit: In F13, it used to halt booting for user input (as desired) but the input was not displayed as the user typed. Is there a way to add this functionality?
During a normal boot, the keyboard is connected to Plymouth (I believe)
On Fedora, I believe you want something like:
plymouth ask-question --prompt="Pick a number between 0 and ∞" \
--command="/usr/bin/numberguesser"
possibly with
--dont-pause-progress
That should display the Plymouth prompt screen, not dissimilar from the way that crypto filesystems prompt for their passwords.
Note that /usr/bin/numberguesser would only get the string entered piped in on its standard input.
Untested, sorry :-(
I was hacking away the source code for plink to make it compatible with unison.
If you don't know, unison is a file synchronization tool, it runs an "ssh" command to connect to a remote server, but there's no ssh.exe for windows; there's plink, which is very close but not close enough (it doesn't behave like unison expects it to), so people usually make wrappers around it, like this one.
one of the problems is that unison expects the password prompt to print to stderr (but plink prints it to stdout, and causes unison to be confused), so I thought, well, should be simple enough, hack my thru plink's code and make it print the prompt to stdout. so I hacked my way through and did that.
Next problem: I can't respond to the prompt!! no matter what I type, it has no effect.
the code for getting input is roughly like this:
hin = GetStdHandle(STD_INPUT_HANDLE);
....
r = ReadFile(hin, .....);
I'm not sure why it's done this way, but I'm not an expert in designing command line tools for windows, so what do I know! But I figure something is missing in setting up the input handle.
I looked at the source code for the above wrapper tool and I see this:
hconin=CreateFile("CONIN$",GENERIC_READ|GENERIC_WRITE,FILE_SHARE_READ,0,OPEN_EXISTING,0,0)
and I try it (just for the heck of it)
hin=CreateFile("CONIN$",GENERIC_READ|GENERIC_WRITE,FILE_SHARE_READ,0,OPEN_EXISTING,0,0);
....
r = ReadFile( hin ...... )
and surprisingly it works! I can now respond to the prompt!
Why is this? what is "CONIN$"? and why is it different from the STD_INPUT_HANDLE?
I can sort of "guess" that FILE_SHARE_READ and OPEN_EXISTING are playing a role in this (since ssh is being run from within another process), but I want to understand what's going on here, and make sure that this code doesn't have some unwanted side effects or security holes or something scary like that!
CONIN$ is the console input device. Normally, stdin is an open file handle to this, but if stdin is redirected for some reason, then using CONIN$ will allow you to get access to the console despite the redirection. Reference.