Prev: wxruby problem
Next: ruby-oci8 function
From: Matt Bleh on 20 Sep 2009 21:14
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/.

From: Mario Camou on 20 Sep 2009 21:44
[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 <phreakuencies(a)gmail.com> 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/.
>
>

From: Matt Bleh on 20 Sep 2009 21:49
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/.

From: David Masover on 21 Sep 2009 09:20
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.

From: Seebs on 21 Sep 2009 09:35
On 2009-09-21, David Masover <ninja(a)slaphack.com> 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 / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
 |  Next  |  Last
Pages: 1 2
Prev: wxruby problem
Next: ruby-oci8 function