Re: [avrdude-dev] [bug #6764] -U syntax doesn't allow full paths in Windows

[Joerg Wunsch]

As address@hidden wrote:

> The parsing is done on the colon first, not grouping on
> quotes. Doulbe quotes would also be needed to handle spaces in the
> pathname, which is allowable on Windows. Example:

Spaces in path names are allowable in Unix as well.  Generally, any
character except a slash and a NUL char is allowable. :-)  (Using a
newline inside a filename is not a very good idea though. ;-)

Note that the quotes will (usually) be eliminated by the shell, so the
application will only see the string including the spaces, but that
should be fine.  (If you escape the quote with a backslash, the shell
will pass it down, that's the way how you access a filename that
contains a quote...)

So the only problem is that the colon serves both as a delimiter for
the fields in the -U option, as well as a possible part of a
legitimate filename.  It could be argued that a colon is a poor choice
for a field delimiter in -U then, but see above, since under Unix any
character is a legitimate filename character (the slash will be
allowable here as well, obviously), any character is an equally poor
field delimiter. ;-)

The attached patch is supposed to solve the problem.  It does this by
looking for the rightmost colon when the parser reaches the file name
component, and if we found one, using anything up to that colon as the
file name (which then might contain any number of colons).  So the
only side effect is that file names containing a colon will make the
trailing :format specification mandatory (i. e., you need to append
a :a).

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/

main.c.diff
Description: Text document