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.
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.
*** This bug has been marked as a duplicate of 98655 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.