Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 98656

Summary: minicom cannot use zmodem to send files whose names contain "%l", "%b", or "%f"
Product: [Retired] Red Hat Linux Reporter: David Costanzo <david_costanzo>
Component: minicomAssignee: Eido Inoue <havill>
Status: CLOSED DUPLICATE QA Contact: Brock Organ <borgan>
Severity: low Docs Contact:
Priority: medium    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 18:56:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Costanzo 2003-07-06 21:33:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

Description of problem:
When minicom sends files using zmodem (sz), it copies the command-line into a
buffer.  Then, just before exec-ing it, it calls translate() (in updown.c) to
convert "%l", "%b", and "%f" into port device name, baud rate, and device file
descriptor number, respectivly.

This translation is important for passing arguments to the external application.
 However, translate should NOT be called over the entire command line.  It
should only be called on the non-file arguments.

At the code level, updown() should call translate on P_PPROG(g) and then
concatenate s, rather than concatenating P_PROG(g) and s, then calling translate.

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

How reproducible:
Always

Steps to Reproduce:
1.Create a one-byte file called ";%l;%b;%f;"
2.Try to send it using zmodem.
NOTE: It may be helpful to put do_log("%s",cmd) in util.c:fastexec() to see the
command-line that was actually executed.

Actual Results:  The file is not sent (or a different file is sent in its
place).  sz complains that the file does not exist.

Expected Results:  The file should be sent.

Additional info:

It's unlikely that this will bug will bother anyone, but it's something that I
noticed, so I figured I'd file it.

This is not the same as defect #98655, even though it has the same symptoms.  At
the code level, defect #98655 is a problem with how the command-line is
tokenized.  This is a problem with how the command-line is constructed.

Comment 1 Eido Inoue 2003-08-01 22:29:50 UTC
I'm marking it as a duplicate, because the solution to both problems will most
likely be the same patch: the filename needs to be preprocessed to change
troublesome characters into something else before being passed to fastexec() for
further parsing.

My gut feeling is that a simple transformation of non-alnum chars (excluding the
forward slash) into backslash+octal escape should do the trick, but I'll need to
look at it more carefully later.


Comment 2 Eido Inoue 2003-08-01 22:30:16 UTC

*** This bug has been marked as a duplicate of 98655 ***

Comment 3 Red Hat Bugzilla 2006-02-21 18:56:57 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.