Re: PATCH: hiding of specials and namerefs

--0000000000000b5a1c0657979e62
Content-Type: text/plain; charset="UTF-8"

>
> What's the point of doing 2>&1 and checking stdtout for the error
> message?


The great benefit is that it ensures that the expected and actual output
lines match not only in content but also in order. When you have stdout and
stderr output, one option is to first put all > lines followed by all ?
lines. However, this often makes reading and understanding tests
particularly difficult because it makes it unclear which of the
statements are expected to produce the ? lines. A better approach is to
interleave the > and ? lines to reflect the expected order. However, in
that case there is still nothing that ensures that the order of one
actual stdout line and one actual stderr line matches the order of the
corresponding > and ? lines. If you initially get the order wrong, or if
some later patch inadvertently changes the order, nothing breaks. By using
2>&1 on statements that produce stderr output, you ensure that all actual
output lines do indeed match the stated expected order and that any future
order change will break the test.


> Isn't it at least a little useful to confirm that the
> message is in fact printed on stderr?
>

It's true that with 2>&1 we lose this ability however I think that it's
highly unlikely that any new code would emit errors or warnings on stdout.
The functions to emit errors and warnings are wired to do it on stderr. And
if someone proposes a patch that emits an error or a warning using an ad
hoc mechanism, that would surely be caught at review time. It's even less
likely that a patch would inadvertently modify an error or warning to now
go to stdout, while on the other hand patches that inadvertently change how
and when a particular condition is detected and signaled is much more
likely.

Philippe

--0000000000000b5a1c0657979e62
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">What&#39;s the point of doing 2&gt=
;&amp;1 and checking stdtout for the error<br>
message?</blockquote><div><br></div><div>The great benefit is that it ensur=
es that the expected and actual output lines match not only in content but =
also in order. When you have stdout and stderr output, one option is to fir=
st put all &gt; lines followed by all ? lines. However, this often makes re=
ading and understanding tests particularly=C2=A0difficult because it makes =
it unclear which of the statements=C2=A0are expected to produce the ? lines=
. A better approach is to interleave the &gt; and ? lines to reflect the ex=
pected order. However, in that case there is still nothing that ensures tha=
t the order of one actual=C2=A0stdout line and one actual=C2=A0stderr line =
matches the order of the corresponding=C2=A0&gt; and ? lines. If you initia=
lly get the order wrong, or if some later patch inadvertently=C2=A0changes =
the order, nothing breaks. By using 2&gt;&amp;1 on statements that=C2=A0pro=
duce stderr output, you ensure that all actual output lines do indeed match=
 the stated expected order and that any future order change will break the =
test.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">Isn&#39;t it at least a little useful to confirm that the<br>
message is in fact printed on stderr?<br></blockquote><div><br></div><div><=
span style=3D"background-color:transparent">It&#39;s true that with 2&gt;&a=
mp;1 we lose this ability however I think that it&#39;s highly unlikely tha=
t any new code would emit errors or warnings on stdout. The functions to em=
it errors and warnings are wired to do it on stderr. And if someone propose=
s a patch that emits an error or a warning using an ad hoc mechanism, that =
would surely be caught at review time. It&#39;s even less likely that a pat=
ch would inadvertently modify an error or warning to now go to stdout, whil=
e on the other hand patches that inadvertently change how and when a partic=
ular condition is detected and signaled is much more likely.</span></div><d=
iv><span style=3D"background-color:transparent"><br></span></div><div><span=
 style=3D"background-color:transparent">Philippe</span></div><div><span sty=
le=3D"background-color:transparent"><br></span></div></div></div>

--0000000000000b5a1c0657979e62--