Could it be the configuration of the modem itself which is leading to it
resetting? I believe the DTR pin is usually asserted when a process
opens the serial port and it is cleared when the port is closed. If
that is true, then perhaps the modem is configured to reset on loss of DTR:
http://en.wikipedia.org/wiki/Data_Terminal_Ready
Specifically look at the AT&D3 command. So if you are finding the modem
is resetting itself when you kill minicom with -9, perhaps it is the
modem itself doing it. Maybe...
On 03/13/2013 10:51 AM, Robert P. J. Day wrote:
On Wed, 13 Mar 2013, Aidan Van Dyk wrote:
kill -9 will absolutely prevent *minicom* from resetting the modem.
With kill -9 (-KILL), minicom is gone, it can't reset it. That's
the point of -KILL.
i've tried this a number of times and have never had any success in
leaving the modem in a usable state, even though the docs explicitly
claim that a -9 kill should do this.
But as the kernel device is closed when minicom is killed, whatever
driver is responsible for it may be doing something...
a hacky workaround i've been using is to simply leave minicom
running, and manually remove the lock file (gack!). i hate doing
that but, for now, at least it lets me test until i find a cleaner
solution.
I know this is the whole "use the tool you know" thing, but it might
be better to use something intended for "scripting" serial ports, or
even fall back to setserial and if you don't like io in bash, expect
(or perl even if tk isn't your thing).
If you want a shell script that talks to modems as an example,
HylaFAX uses shell for probing modems:
http://git.hylafax.org/HylaFAX?a=blob;f=etc/probemodem.sh.in;hb=master
i would be more than happy to find a better utility than minicom,
i'll check that out. i see RGB has also weighed in ...
rday
--
Jeremy Rand
jeremy [ dot ] rand [ at ] alcatel-lucent [ dot ] com