Brian Murphy <brian@murphy.dk> writes:
Mark D. Baushke wrote:
Anthon van der Neut <AvanderNeut@pinnaclesys.com> writes:
This is against 1.12.1.1, I am trying to get it make it in the official
release, so I can stop worrying to break or processing on each upgrade of
the servers. Comments and critique are welcome, pointers on who to ask to
apply this patch as well.
diff -u -r1.70 logmsg.c
--- logmsg.c 23 Jul 2003 20:42:26 -0000 1.70
+++ logmsg.c 13 Aug 2003 03:58:53 -0000
@@ -882,6 +882,9 @@
cp += fmt_percent - filter;
*cp++ = '"';
cp = shell_escape (cp, srepos);
+ cp++ = '"';
+ cp++ = ' ';
+ cp++ = '"';
cp = shell_escape (cp, str_list);
*cp++ = '"';
(void) strcpy (cp, fmt_continue);
Regards
Anthon
I sent this patch a long time ago to fix the same problem but even
though I begged I got no comments ;-).
Yeah, that happens sometimes... last November was busy for me, so I
think I somehow missed your message.
I pass the repository name and each item generated from %{...}
as a seperate argument:
http://mail.gnu.org/archive/html/bug-cvs/2002-11/msg00092.html
I think the argument against such things is that it will break already
running scripts. Perhaps a command line argument should signal the
new format?
More likely a CVSROOT/config option or a different %{...} token would be
the right approach. That would allow script writers to do the right kind
of interpretation of the command-line arguments they get on their
scripts.
Possibilities:
- Use a NUL byte to separate token elements, a la GNU find's -print0
switch and xargs -0 switch and GNU textutils 'sort -z' option.
- Possibly go to a quoting mechanism such as is used for URLs. With
% being an escape for hexadecimal bytes. So, %20 is a space.
I have not really thought thru the implications of such a change, but it
would be useful to be able to handle all of the possible Unicode
characters that some filesystems are starting to use in filenames under
some operating systems.