Red Hat Bugzilla – Bug 98656
minicom cannot use zmodem to send files whose names contain "%l", "%b", or "%f"
Last modified: 2007-04-18 12:55:30 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):
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.
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.
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
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.
*** This bug has been marked as a duplicate of 98655 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.