Bug 74451 - --noinit or -o option does not work
--noinit or -o option does not work
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: minicom (Show other bugs)
7.3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eido Inoue
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-24 12:46 EDT by Nathan Crapo
Modified: 2007-04-18 12:46 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-23 16:48:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
New Source RPM containing updated spec file, patch, etc. (402.58 KB, application/octet-stream)
2002-09-24 12:48 EDT, Nathan Crapo
no flags Details

  None (edit)
Description Nathan Crapo 2002-09-24 12:46:08 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513

Description of problem:
Was trying to use minicom with /dev/usb/ttyUSB0.  Since I couldn't get the lock
file, I tried using --noinit and -o, which did not work.  Minicom was still
trying to get the lock file and failing.  Verified that using the vanilla
minicom source, the --noinit or -o option skipped grabbing the lock on the file.
 Checked out the Red Hat source RPM and found a minor change in the open_term
logic that was keeping the --noinit option from skipping lock file attempts.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.  Start up minicom (type "minicom").  If you haven't created a default or
something that works, do so now so you can go on to the next step.
2.  Assuming step one was successful, while minicom is still running, observe
lock files in /var/lock in another terminal.
3.  Quit out of minicom.
4.  Start up minicom with the --noinit option (type "minicom --noinit").
5.  Assuming step four was successful, while minicom is still running, observe
lock files in /var/lock from another terminal.  Since the --noinit option was
used, there shouldn't be lock files.


Actual Results:  Minicom attempts to create lock files even when the --noinit
option is used.  This kept me from opening /dev/usb/ttyUSB0 without using a lock
file.

Expected Results:  Minicom should have skipped lock file creation and merely
opened the port without checking if it could be locked.

Additional info:

I've created a patch, and new SRPM to fix the problem.  It's a one liner.  I'll
add them to the bug later.

Incidentally, this whole thing was stumbled upon because we have two copies of
ttyUSB0 in the dev tree (one in /dev/usb and one in /dev).  The lockdev package
was redirecting me to /dev/ttyUSB0 from /dev/usb/ttyUSB0 when it makes a call to
ttyname() from the dev_lock() call.  I figured out that I had to change the
perms on /dev/ttyUSB0.  Didn't even realize if was there until I debugged
lockdev a little.  I'm not sure whether to file a bug against lockdev or the dev
package.
Comment 1 Nathan Crapo 2002-09-24 12:48:12 EDT
Created attachment 77048 [details]
New Source RPM containing updated spec file, patch, etc.

Note You need to log in before you can comment on or make changes to this bug.