# Net::SSH - request a pty seems to put stderr in stdout

**URL:** <https://www.ruby-forum.com/t/net-ssh-request-a-pty-seems-to-put-stderr-in-stdout/186115>\
**Category:** Ruby\
**Created:** [March 31, 2010, 7:14pm UTC](https://www.ruby-forum.com/t/net-ssh-request-a-pty-seems-to-put-stderr-in-stdout/186115 "2010-03-31T19:14:11Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![najati](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/898d66/32.png) [@najati](https://www.ruby-forum.com/u/najati)\
**Post date:** [March 31, 2010, 7:14pm UTC](https://www.ruby-forum.com/t/net-ssh-request-a-pty-seems-to-put-stderr-in-stdout/186115/1 "2010-03-31T19:14:11Z")

</div>

Hi all,

As context, we’re simply trying to remotely (automatically) “su” to a  
different user and issue commands as that user, while still being able  
to differentiate between stderr and stdout on the subsequent commands.  
If there’s a common pattern for doing this, then answering my specific  
question isn’t all that important (to me). Thanks!

So, I’m trying to use Net::SSH to do some remote automation and when we  
need to su to do something, thus requiring a pty, it seems that the  
on\_extended\_data doesn’t get called on stderr and that it, instead, gets  
mashed into on\_data:

Example:

* * *

require ‘rubygems’  
require ‘net/ssh’

command = “cat slartibartfast”

Net::SSH.start(host, user, :password =\> password) do |ssh|  
channel = ssh.open\_channel do |ch|  
channel.request\_pty do |ch, success|  
raise “no pty!” if !success  
end

```
ch.exec command do |ch, success|
  raise "could not execute command" unless success

  password_sent = false
  ch.on_data do |c, data|
    puts "stdout: " + data
  end

  ch.on_extended_data do |c, type, data|
    puts "stderr: " + data
  end
end

```

end  
channel.wait  
end

* * *

Output:

* * *

stdout: cat: cannot open slartibartfast  
stdout:

* * *

If I take the request for the pty out, everything behaves as expected.  
Is this intentional behavior? I have yet to dig into the source, but  
will tomorrow.

Thanks again!  
Najati