On Wed, Mar 13, 2013 at 09:10:49AM -0400, 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. > > But as the kernel device is closed when minicom is killed, whatever driver > is responsible for it may be doing something... > > 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). This is a very timely question Robert... A couple of days ago I was fighting with a ttyACM device. It is embedded in a Teensy3.0 that is now running this: http://smart_panel.tricolour.ca/ http://tricolour.ca/photos/2013/02/19/ I have been developing on and running Arduinos for more than a year on 3 different ancient machines running Debian Squeeze or Wheezy and more recently the Teensy3.0 without seeing this problem, then just this past weekend, I tried to connect the Teensy to a different machine running Wheezy and I'd get one line of text output (~350 chars), then after a 5 second pause in the output, the line would lock up. I was using a perl script with a shell call to stty, then open(), select(), read(), also using cat(1) and minicom(1) and all were locking up. This also happenned on a brand new Thinkpad running bleeding edge fedora rawhide, but not a brand new workstation running RHEL6.4. The stty call was: stty -F /dev/ttyACM$deviceno 115200 -parenb -cstopb cs8 After beating my head on this for a while, someone suggested using "screen /dev/ttyACM0", then killing that with "^Aky" which worked fine to initialize that device in both places. Huh? The problem with killing minicom is it will leave behind a /var/lock/ttyACM0 file that needs to be removed before some programs will try to talk to it. > 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 > > a. > > > On Wed, Mar 13, 2013 at 7:29 AM, Robert P. J. Day <rpjday [ at ] crashcourse [ dot ] ca>wrote: > > > > > i'm currently working with minicom to initialize a modem using > > a minicom "runscript" -- for those of you unfamiliar with this, you > > can run: > > > > $ minicom -S script > > > > where "script" is a shell script that minicom will execute, doing > > things like sending various "AT" commands to the modem. at the end > > of all that, i get the desired > > > > Modem is connected > > > > but at that point, if i invoked minicom in the foreground, it's > > obviously still running and it will have a lock file on the device > > file (in my case, /dev/ttyUSB0). that means i can't start pppd on > > that port since i will immediately get > > > > Device ttyUSB0 is locked by pid .... > > > > so what i want is for minicom to now exit gracefully *without* > > resetting the modem, since that would defeat everything's that's > > been done up to now. that's equivalent to exiting minicom manually > > with "Q" (quit with no reset) as opposed to "X" (exit and reset), > > and i need to do that programatically from within a script. > > > > all the documentation i've seen suggests that can be done with > > > > $ killall -9 minicom > > > > which (as i read it) *claims* that that will kill minicom without > > resetting the modem, but that just doesn't seem true with all the > > tests i've run -- resets it every time. > > > > i know i can cheat and simply "rm" the lock file under /var/lock, > > but that's seems tacky and i'd rather do this the right way. anyone > > know how to kill off a minicom session without resetting the modem > > it's talking to? > > > > rday > Aidan Van Dyk Create like a god, slainte mhath, RGB -- Richard Guy Briggs -- ~\ -- ~\ <hpv.tricolour.net> <www.TriColour.net> -- \___ o \@ @ Ride yer bike! Ottawa, ON, CANADA -- Lo_>__M__\\/\%__\\/\% Vote! -- <greenparty.ca>_____GTVS6#790__(*)__(*)________(*)(*)_________________