[OpenAFS-devel] Why does default_com_err_proc() spit out a carriage return?

Phillip Moore w.phillip.moore@gmail.com
Thu, 4 Nov 2010 16:53:37 -0400


--0015175cb2c224aa920494405a47
Content-Type: text/plain; charset=ISO-8859-1

Determining whether or not the tty *is* in raw tty mode is not something we
want to be checking in that particular function though, and it's also
somewhat platform specific.

Seems to me that the patch suggested by jaltman at least makes sense by
ordering those two characters correctly.   I don't think it's practical to
query the tty state in that function.

On Thu, Nov 4, 2010 at 4:38 PM, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:

> --On Thursday, November 04, 2010 03:49:32 PM -0400 Jeffrey Altman <
> jaltman@secure-endpoints.com> wrote:
>
>  On 11/4/2010 3:30 PM, Phillip Moore wrote:
>>
>>> Does anyone know why, in src/comerr/com_err.c,
>>> in default_com_err_proc(), the code does the following:
>>>
>>>    putc('\n', stderr);
>>>    /* should do this only on a tty in raw mode */
>>>    putc('\r', stderr);
>>>    fflush(stderr);
>>>
>>>
>> This should be:
>>
>>        /* should do this only on a tty in raw mode */
>>        putc('\r', stderr);
>>        putc('\n', stderr);
>>        fflush(stderr);
>>
>> since the CR always is before the LF.  MIT fixed this in their code base
>> more than a decade ago.   OpenAFS inherited the brokenness.
>>
>> Whether OpenAFS wishes to output as CR-LF at all is a separate matter.
>> I suspect the answer should be 'no'.
>>
>
> In fact, the answer should be to do so only when stderr is a tty in raw
> mode, like the comment says.
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>

--0015175cb2c224aa920494405a47
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><br></div>Determining whether or not the tty *is* in raw tty mode is n=
ot something we want to be checking in that particular function though, and=
 it&#39;s also somewhat platform specific.<div><br></div><div>Seems to me t=
hat the patch suggested by jaltman at least makes sense by ordering those t=
wo characters correctly. =A0 I don&#39;t think it&#39;s practical to query =
the tty state in that function.</div>
<div><br><div class=3D"gmail_quote">On Thu, Nov 4, 2010 at 4:38 PM, Jeffrey=
 Hutzelman <span dir=3D"ltr">&lt;<a href=3D"mailto:jhutz@cmu.edu">jhutz@cmu=
.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class=3D"h5">--On Thursday, November 04, 2010 03:49:32=
 PM -0400 Jeffrey Altman &lt;<a href=3D"mailto:jaltman@secure-endpoints.com=
" target=3D"_blank">jaltman@secure-endpoints.com</a>&gt; wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 11/4/2010 3:30 PM, Phillip Moore wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Does anyone know why, in src/comerr/com_err.c,<br>
in default_com_err_proc(), the code does the following:<br>
<br>
 =A0 =A0putc(&#39;\n&#39;, stderr);<br>
 =A0 =A0/* should do this only on a tty in raw mode */<br>
 =A0 =A0putc(&#39;\r&#39;, stderr);<br>
 =A0 =A0fflush(stderr);<br>
<br>
</blockquote>
<br>
This should be:<br>
<br>
 =A0 =A0 =A0 =A0/* should do this only on a tty in raw mode */<br>
 =A0 =A0 =A0 =A0putc(&#39;\r&#39;, stderr);<br>
 =A0 =A0 =A0 =A0putc(&#39;\n&#39;, stderr);<br>
 =A0 =A0 =A0 =A0fflush(stderr);<br>
<br>
since the CR always is before the LF. =A0MIT fixed this in their code base<=
br>
more than a decade ago. =A0 OpenAFS inherited the brokenness.<br>
<br>
Whether OpenAFS wishes to output as CR-LF at all is a separate matter.<br>
I suspect the answer should be &#39;no&#39;.<br>
</blockquote>
<br></div></div>
In fact, the answer should be to do so only when stderr is a tty in raw mod=
e, like the comment says.<br>
_______________________________________________<br>
OpenAFS-devel mailing list<br>
<a href=3D"mailto:OpenAFS-devel@openafs.org" target=3D"_blank">OpenAFS-deve=
l@openafs.org</a><br>
<a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-devel" target=
=3D"_blank">https://lists.openafs.org/mailman/listinfo/openafs-devel</a><br=
>
</blockquote></div><br></div>

--0015175cb2c224aa920494405a47--