Re: filenames in error messages

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[adding bug-gnulib, as owner of the quotearg module]

According to Karl Berry on 1/21/2008 3:47 PM:
| There was a suggestion on bug-standards
| http://lists.gnu.org/archive/html/bug-standards/2008-01/msg00000.html
| about enclosing the filename in <...> when it's a url.
|
| Two questions:
| 1) should we try to invent an unambiguous syntax for specifying "source"
|    names?
| 2) Does anyone know of anything besides next-error in Emacs that parses
|    these messages?  It seems inevitable that other programs (such as IDE's)
|    would, but I don't know of any specifically.
|
| Actually, I don't think the issue is about url's specifically so much as
| special characters in general.  Although next-error manages to parse
| simple filenames containing colons, I expect if a filename was
| sufficiently strange, it could be fooled.  It seems like it would be
| nice to have an unambiguous syntax.
|

According to Karl Berry on 1/30/2008 4:30 PM:
|     Are we talking about something like this?
|
|       http://www.example.com/some\:path
|
| It's the : after the http that concerns me.  Every url would have to
| have that \ after the protocol, and as Eric says, then cut-and-paste
| wouldn't work, which is a drag.  Using quotes as in "http://..."; doesn't
| suffer from that.
|

I noticed several potential issues with the quotearg module.  One is the
limitation mentioned above that quotearg_colon would output this when
using the "escape" style:

http\://www.example.com/some\:path

which cannot be copied.  Another is that quotearg_char ONLY outputs a
backslash before the char IF the quoting style is not "literal", "shell",
or "shell-always".  Those three styles ignore the request to escape
additional characters.  Another problem with those three styles is that
when used with quotearg_n_style_mem, they cannot handle embedded NUL (the
'\0' character is not escaped, but the API does not output a length of the
resulting quoted buffer).  Sure, you can use quotearg_buffer or
quotearg_alloc, but then you have to manage the string yourself, whereas
it would be kind of nice being able to do
~ error (...,"%s", quotearg_n_style_mem (n, shell_quoting_style, str, len))

Is there any reason that shortcuts like quotearg_style_mem are not
defined, in contrast with quotearg_style(s,a) short for
quotearg_n_style(0,s,a)?

I also noticed that once you call quotearg_colon, all future calls to
quotearg() will behave as though they were quotearg_colon unless you
manually call set_char_quoting(NULL,':',0).  In other words,
quotearg_colon does not remember nor restore the prior state of the colon
character in the default quoting options.

One thing I like about the "shell" quoting style is that its use of quotes
is dependent on the contents - in the common case, where nothing needs
quoting, the input can be reused as the output.  Along the lines of the
problem at hand, I wonder if the GNU Coding Standards should use a style
like the following:

If the file name comes from the portable set ([-_a-zA-Z0-9./], and
probably a few others like + that are not required by POSIX), then
messages relative to a file can look like:

program:file:line: message

If the file name contains problematic characters (including the : in a
URL, or non-printable characters), then the file name is surrounded in
quotes, and uses C escapes for the problematic characters:

program:"embedded colon:, quote\", and spaces":line: message
program:"http://example.com/file":line: message

Should I go ahead and hack on a new quoting style in quotearg.c that can
be used in this manner, adding "" around the string only if an escape
sequence or quote_these_too character is encountered?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHqmWm84KuGfSFAYARAie8AJ4r7s6Uaa0aNyqlcG77/4PkO+ASfgCfR7u6
QiTrtStmtAZmbm/c2Pv7K+U=
=Io2d
-----END PGP SIGNATURE-----