Writing to STDOUT after closing controlling terminal

Discussion in 'Ruby' started by Matt Bleh, Sep 21, 2009.

  1. Matt Bleh

    Matt Bleh Guest

    Hi,
    I don't know if this is a dumb question or not (I hope it isn't), but it
    seems to me there's something wrong here. I've been using Ruby for a
    long time now, and I never noticed this (maybe it wasn't working like
    this in the past), and it just seems odd.
    If I write the following code:

    sleep(5)
    begin
    puts 'hi!'
    rescue
    File.open('output', 'w') {|io| io.puts $!.message }
    end

    And execute it in Ruby 1.9.1p243 in a graphical terminal (e.g.: konsole)
    as a foreground process I obviously get this:

    $ ./test.rb
    hi!

    And there's no "output" file created sine no exception was raised.

    Now, If I do:
    $ ./test.rb &
    [1] 28137
    and immediately close konsole, 5 seconds later I get:
    $ cat output
    Input/output error - <STDOUT>

    Is this ok? I seems to me that one shouldn't have to care if the
    controlling terminal is closed when doing "puts" to avoid this exception
    from ending my ruby process.

    As a sidenote, with Ruby 1.8.7p174 the process doesn't get any
    exception. If now I write (to check for normal process completion):

    sleep(5)
    begin
    puts 'hi!'
    File.open('output2', 'w') {|io| io.puts 'ok' }
    rescue
    File.open('output', 'w') {|io| io.puts $!.message }
    end
    with

    and execute it as before, I get the "output2" file with the "ok" string
    in it.

    Is this a bug? a feature?

    Thank you,
    Matt
    --
    Posted via http://www.ruby-forum.com/.
     
    Matt Bleh, Sep 21, 2009
    #1
    1. Advertising

  2. Matt Bleh

    Mario Camou Guest

    [Note: parts of this message were removed to make it a legal post.]

    As far as killing the controlling terminal is concerned, AFAIK it's standard
    Unix practice. If you want the process to stay alive even if you kill the
    terminal, you either redirect its stdin/stdout or use nohup.
    -Mario.

    --
    I want to change the world but they won't give me the source code.


    On Mon, Sep 21, 2009 at 03:14, Matt Bleh <> wrote:

    > Hi,
    > I don't know if this is a dumb question or not (I hope it isn't), but it
    > seems to me there's something wrong here. I've been using Ruby for a
    > long time now, and I never noticed this (maybe it wasn't working like
    > this in the past), and it just seems odd.
    > If I write the following code:
    >
    > sleep(5)
    > begin
    > puts 'hi!'
    > rescue
    > File.open('output', 'w') {|io| io.puts $!.message }
    > end
    >
    > And execute it in Ruby 1.9.1p243 in a graphical terminal (e.g.: konsole)
    > as a foreground process I obviously get this:
    >
    > $ ./test.rb
    > hi!
    >
    > And there's no "output" file created sine no exception was raised.
    >
    > Now, If I do:
    > $ ./test.rb &
    > [1] 28137
    > and immediately close konsole, 5 seconds later I get:
    > $ cat output
    > Input/output error - <STDOUT>
    >
    > Is this ok? I seems to me that one shouldn't have to care if the
    > controlling terminal is closed when doing "puts" to avoid this exception
    > from ending my ruby process.
    >
    > As a sidenote, with Ruby 1.8.7p174 the process doesn't get any
    > exception. If now I write (to check for normal process completion):
    >
    > sleep(5)
    > begin
    > puts 'hi!'
    > File.open('output2', 'w') {|io| io.puts 'ok' }
    > rescue
    > File.open('output', 'w') {|io| io.puts $!.message }
    > end
    > with
    >
    > and execute it as before, I get the "output2" file with the "ok" string
    > in it.
    >
    > Is this a bug? a feature?
    >
    > Thank you,
    > Matt
    > --
    > Posted via http://www.ruby-forum.com/.
    >
    >
     
    Mario Camou, Sep 21, 2009
    #2
    1. Advertising

  3. Matt Bleh

    Matt Bleh Guest

    Mario Camou wrote:
    > As far as killing the controlling terminal is concerned, AFAIK it's
    > standard
    > Unix practice. If you want the process to stay alive even if you kill
    > the
    > terminal, you either redirect its stdin/stdout or use nohup.
    > -Mario.
    >
    > --
    > I want to change the world but they won't give me the source code.


    I know it's not enough justification, but doing an "echo 1" from a
    backgrounded bash script process doesn't kill the script. I understand
    that you should redirect STDOUT, but in Ruby should programmers really
    need to concern about this?
    Or maybe this would translate to the users of that Ruby program to be
    forced to redirect STDOUT and STDERR to /dev/null or something (which
    also seems a bit weird to me).
    --
    Posted via http://www.ruby-forum.com/.
     
    Matt Bleh, Sep 21, 2009
    #3
  4. On Sunday 20 September 2009 08:49:56 pm Matt Bleh wrote:
    > I know it's not enough justification, but doing an "echo 1" from a
    > backgrounded bash script process doesn't kill the script.


    That's because your script is badly written. Try this script:

    #!/bin/sh
    sleep 5
    echo hi || echo $! > output

    This has exactly the same behavior as your Ruby script, except that you're
    only capturing the return value of that first echo command.

    In other words: In a shell script (bash or otherwise), the 'echo' command does
    indeed get killed. It's just that by default, shell scripts ignore the return
    values, which means errors are silently eaten. Ruby, on the other hand, raises
    an exception when something goes wrong.

    I don't like silent errors, so I usually write shell scripts that look more
    like this:

    #!/bin/sh
    first line &&
    second line &&
    third line &&
    fourth line

    That way, the script dies at the first error, unless I explicitly handle it.

    > I understand
    > that you should redirect STDOUT, but in Ruby should programmers really
    > need to concern about this?


    If you don't want to be concerned about this, abstract it away with some sort
    of logging class. I'm glad Ruby has the same behavior as any other language,
    when it comes to basic Unix semantics like this -- and I'm glad my output
    doesn't just silently get eaten when I close the terminal.
     
    David Masover, Sep 21, 2009
    #4
  5. Matt Bleh

    Seebs Guest

    On 2009-09-21, David Masover <> wrote:
    > I don't like silent errors, so I usually write shell scripts that look more
    > like this:


    You might use "set -e". I don't, but I check exactly those errors I care
    about. (I don't necessarily care about loss of output.)

    -s
    --
    Copyright 2009, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
     
    Seebs, Sep 21, 2009
    #5
  6. Matt Bleh

    Matt Bleh Guest

    David Masover wrote:
    > On Sunday 20 September 2009 08:49:56 pm Matt Bleh wrote:
    >> I know it's not enough justification, but doing an "echo 1" from a
    >> backgrounded bash script process doesn't kill the script.

    >
    > That's because your script is badly written. Try this script:
    >
    > #!/bin/sh
    > sleep 5
    > echo hi || echo $! > output
    >
    > This has exactly the same behavior as your Ruby script, except that
    > you're
    > only capturing the return value of that first echo command.
    >
    > In other words: In a shell script (bash or otherwise), the 'echo'
    > command does
    > indeed get killed. It's just that by default, shell scripts ignore the
    > return
    > values, which means errors are silently eaten. Ruby, on the other hand,
    > raises
    > an exception when something goes wrong.



    Ok, I didn't realized that about the bash script.
    So, this means that this difference between ruby 1.8 and ruby 1.9 is a
    feature?
    I guess that I should then use nohup if I don't want to think about this
    issue when writing other Ruby programs.
    --
    Posted via http://www.ruby-forum.com/.
     
    Matt Bleh, Sep 21, 2009
    #6
  7. On Monday 21 September 2009 09:36:31 am Matt Bleh wrote:
    > So, this means that this difference between ruby 1.8 and ruby 1.9 is a
    > feature?


    In my opinion.

    > I guess that I should then use nohup if I don't want to think about this
    > issue when writing other Ruby programs.


    Depends what you're using the output for. I would use some sort of logger, if
    you can't count on stdout being redirected.
     
    David Masover, Sep 22, 2009
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Evgeni Sergeev
    Replies:
    1
    Views:
    321
    Jeff Epler
    Jan 4, 2005
  2. gaurav kashyap
    Replies:
    3
    Views:
    6,664
    Paul Boddie
    Oct 31, 2008
  3. Steve
    Replies:
    2
    Views:
    942
    edicionsdigitals.com edicions digitals xarxa socia
    Dec 7, 2010
  4. Marc Weber
    Replies:
    0
    Views:
    118
    Marc Weber
    Feb 17, 2011
  5. Dilbert
    Replies:
    5
    Views:
    144
    Dilbert
    Jan 24, 2010
Loading...

Share This Page