Project

General

Profile

Backport #5253

PTY with wait incorrectly sets exit status for exit command

Added by thinkerbot (Simon Chiang) about 9 years ago. Updated over 4 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
[ruby-core:39216]

Description

Realizing this is irrelevant under normal usage, it appears wait on a PTY process does not set the correct exit status for an 'exit' command. For example:

PTY.spawn("exit 8") do |r,w,pid|
  Process.wait(pid)
end
$?.exitstatus  # => 1

Incidentally 'system' also appears to suffer from this unexpected behavior.

system "exit 8"
$?.exitstatus  # => 127

I think that either the most obvious exit status (8) should be set by both PTY and system or, if for some reason that can't happen then the behavior should be consistent between them. A test case is attached.

Note that on 1.9.3-preview1 you get different behavior. The PTY code results in "Errno::ENOENT: No such file or directory - exit 8".

Also, a similar inconsistency happens with an empty string (although I don't know what the correct behavior is in this case):

PTY.spawn("") do |r,w,pid|
  Process.wait(pid)
end
$?.exitstatus  # => 1

system ""
$?.exitstatus  # => 127

I know, I know... these are edge cases! I won't try to argue calling PTY with an exit command or empty string is normal, but it came up in exploration while trying to make some example code.


Files

pty_exitstatus_test.rb (730 Bytes) pty_exitstatus_test.rb thinkerbot (Simon Chiang), 09/01/2011 05:34 AM
#1

Updated by nobu (Nobuyoshi Nakada) about 9 years ago

  • Tracker changed from Bug to Backport
  • Project changed from Ruby master to Backport192
  • Priority changed from Normal to 3
  • Target version deleted (1.9.2)

PTY.spawn should be different from Kernel#system but similar to Kernel#spawn, as its name means.
So the behavior in 1.9.3 is consistent enough, and this issue would be a backport request but I think that it's trivial to change 1.9.2 now.

Updated by thinkerbot (Simon Chiang) about 9 years ago

Apologies for the delay in reply, for some reason I don't get email updates even though I'm watching this ticket.

That is a reasonable assertion that the behavior should be consistent PTY.spawn to Kernel.spawn. I'm still curious, what is the correct behavior? Specifically, why doesn't/can't spawn return the exit status as specified by 'exit'?

I know in the case of system (ie /bin/sh) a 127 could be returned for a command that is not found... so maybe it's not finding exit because it's a built-in utility... but I'm not clear why returning 1 could be correct for spawn. I am confused and would appreciate clarification if you have time to explain.

Updated by nobu (Nobuyoshi Nakada) about 9 years ago

Hi,

At Wed, 14 Sep 2011 03:38:53 +0900,
Simon Chiang wrote in [ruby-core:39527]:

Apologies for the delay in reply, for some reason I don't get
email updates even though I'm watching this ticket.

No apologies. I've not received the post by myself too.
Something didn't go fine.

That is a reasonable assertion that the behavior should be
consistent PTY.spawn to Kernel.spawn. I'm still curious, is
the behavior correct? Specifically, why doesn't/can't spawn
return the exit status as specified by 'exit'?

It's not that spawn doesn't return the exit status, but that
spawn failes to start non-existent programs, i.e., "exit 8" and
"". You don't seem to have "/usr/bin/exit 8" file obviously.
Since it can't start a new process, so it raises an exception.

I know in the case of system a 127 can be returned for a
command that is not found... so maybe it's not looking up
exit because it's a built-in utility... but I'm not clear why
returning 1 is could be correct for spawn. I am confused and
would appreciate clarification if you have time to explain.

It's deprecated behavior to return 127 instead of an exception.

--
Nobu Nakada

Updated by thinkerbot (Simon Chiang) about 9 years ago

Thank you for you explanation!

#5

Updated by naruse (Yui NARUSE) over 4 years ago

  • Status changed from Open to Rejected

Also available in: Atom PDF