sshd and .bashrc

[Mark Bartelt]

>>  bash was doing the wrong thing varying its behaviour based on the
>>  type of fd it was talking to, so please turn your attention there.

Fair enough; I'm basically agnostic on the issue of whether bash
{is|isn't} doing the wrong thing.  But regardless, I still feel
that the change in sshd's behaviour shouldn't have been sprung
on people without a big "hey, heads-up, bash users!" in one of
the README files.  It first appeared in the 5.1p1 release (it
wasn't there in 5.0p1), and although the change was documented
in that ChangeLog file, it's more than 800 lines down, with no
suggestion about what the potential side-effects of the change
might be.  But if I've overlooked something in a location that
people are more likely to pay attention to, feel free to point
me in its direction.  Just seems that when a change gets made
which affects backward compatibility and interoperability, it
would be best if folks were alerted about the potential impact
of moving from an older release to the newer one.

But my main gripe is the fact that the "#define USE_PIPES" was
buried more than 400 lines down inside a .c source file, while
the relevant header file (or at least the file which one might
naively assume is relevant, defines.h) still (as of the 5.8p2
release) contains ...

/*
 * Define this to use pipes instead of socketpairs for communicating with the
 * client program.  Socketpairs do not seem to work on all systems.
 *
 * configure.ac sets this for a few OS's which are known to have problems
 * but you may need to set it yourself
 */
/* #define USE_PIPES 1 */

... which suggests that, if that statement were left as it is
(i.e. commented out), USE_PIPES would be undefined when sshd
was built.