On Wed, Oct 9, 2013 at 4:25 PM, Graham Leggett <minf...@sharp.fm> wrote:
> On 03 Oct 2013, at 1:51 AM, Jeff Trawick <traw...@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. > Regards, > Graham > -- > > -- Born in Roswell... married an alien... http://emptyhammock.com/
