This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 98656 - minicom cannot use zmodem to send files whose names contain "%l", "%b", or "%f"
minicom cannot use zmodem to send files whose names contain "%l", "%b", or "%f"
Status: CLOSED DUPLICATE of bug 98655
Product: Red Hat Linux
Classification: Retired
Component: minicom (Show other bugs)
9
All Linux
medium Severity low
: ---
: ---
Assigned To: Eido Inoue
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-07-06 17:33 EDT by David Costanzo
Modified: 2007-04-18 12:55 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:56:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David Costanzo 2003-07-06 17:33:29 EDT
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 18:29:50 EDT
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 18:30:16 EDT

*** This bug has been marked as a duplicate of 98655 ***
Comment 3 Red Hat Bugzilla 2006-02-21 13:56:57 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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