On Wed, Oct 9, 2013 at 4:25 PM, Graham Leggett <minfrin@sharp.fm> wrote:
On 03 Oct 2013, at 1:51 AM, Jeff Trawick <trawick@gmail.com> wrote:

> I dug into the glitches seen on Windows...   \e is a non-portable escape (GNU extension), and shell escaping treats \n differently on Windows and OS/2, which the testcase didn't account for.
> I guess the code that used \e doesn't match anything in httpd?

Looking back at the code it originated from ap_escape_logitem() and ap_escape_errorlog_item() which are almost identical but for additional escape sequences.

If \e is non-portable in C it can be removed, an escape character is unlikely to cause harm.

The function is trying to escape any binary values that could conceivably cause problems when printed to the terminal, whether or not those values happen to have a C escape sequence "shortcut".  The escaping is done regardless IIUC.  It looks like the code which uses \e is just trying to use well-known shortcuts for certain escape sequences, and if the \e code is removed then it will use the hex equivalent.


Born in Roswell... married an alien...