openssh-unix-dev Digest, Vol 174, Issue 9

[Dale Worley]

 > My scripts, which read stdout from ssh, weren't seeing EOF from the
 > remote session.? It was being sent, but lost.? I tracked it down to the
 > following code, in ssh.c, at ssh_session2_open:
 >
 >  ??????? if (stdin_null_flag) {
 >  ??????????????? in = open(_PATH_DEVNULL, O_RDONLY);
 >  ??????? } else {
 >  ??????????????? in = dup(STDIN_FILENO);
 >  ??????? }
 >  ??????? out = dup(STDOUT_FILENO);
 >  ??????? err = dup(STDERR_FILENO);
 >
 > The remote session did close stdout.? The sshd from which it was spawned
 > signaled to close stdout.? The ssh program received that signal and
 > closed, well, something, but not stdout.? It closed a copy.?
 > Importantly, it left a copy open, so my program got no EOF.
 >
 > Why not:
 >
 >  ??????? if (stdin_null_flag) {
 >  ??????????????? in = open(_PATH_DEVNULL, O_RDONLY);
 >  ??????? } else {
 >  ??????????????? in = STDIN_FILENO;
 >  ??????? }
 >  ??????? out = STDOUT_FILENO;
 >  ??????? err = STDERR_FILENO;
 >
 > If not that, how is a program that reads from ssh's output ever going to
 > see EOF?

I'm not sure if the current behavior is the best, but it's pretty clear 
that the reason for it is that the usual way to signal "end" on stdout 
is to terminate the process.  So ssh waits for the process it is running 
on the server end to terminate, then it terminates, and then whatever is 
piped from ssh sees EOF.

What you're proposing is if the server-end program deliberately closes 
stdout before it terminates, should ssh then close stdout before *it* 
terminates?

This could be especially interesting if the remote program hasn't closed 
stderr yet -- the next program in the pipe would expect, having seen EOF 
on stdin that it could depend on everything ssh was to do (including 
perhaps saving its stderr) to be complete already, but that might not be so.

Dale


Dale