# Closing stderr

**URL:** <https://rubytalk.org/t/closing-stderr/8132>\
**Category:** ruby-talk\
**Created:** [18 September 2003 15:49 UTC](https://rubytalk.org/t/closing-stderr/8132 "2003-09-18T15:49:43Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![Michael\_Garriss1](https://avatars.discourse-cdn.com/v4/letter/m/958977/32.png) [@Michael\_Garriss1](https://rubytalk.org/u/Michael_Garriss1)\
**Post date:** [18 September 2003 15:49 UTC](https://rubytalk.org/t/closing-stderr/8132/1 "2003-09-18T15:49:43Z")

</div>

I would like to prevent some output that is going to stderr during a  
call to a third party lib just during that call. My first guess was:

STDERR.close\_write  
ThirdPartyLib::call\_some\_annoying\_function  
STDERR.???

I guess you can see my problem. Can anyone give me a lead on this?

TIA,  
Michael

---

<div class="post-metadata">

**Author:** ![Robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@Robert](https://rubytalk.org/u/Robert)\
**Post date:** [18 September 2003 16:14 UTC](https://rubytalk.org/t/closing-stderr/8132/2 "2003-09-18T16:14:45Z")

</div>

“Michael Garriss” [mgarriss@earthlink.net](mailto:mgarriss@earthlink.net) schrieb im Newsbeitrag  
[news:3F69D414.70008@earthlink.net](mailto:news:3F69D414.70008@earthlink.net)…

> I would like to prevent some output that is going to stderr during a  
> call to a third party lib just during that call. My first guess was:
> 
> STDERR.close\_write  
> ThirdPartyLib::call\_some\_annoying\_function  
> STDERR.???
> 
> I guess you can see my problem. Can anyone give me a lead on this?
> 
> TIA,  
> Michael

require ‘StringIO’

oldStdErr = $stderr  
oldSTDERR = STDERR

$stderr = StringIO.new  
STDERR = $stderr

begin

# lib call

ensure  
$stderr = oldStdErr  
STDERR = oldSTDERR  
end

```
robert

```

---

<div class="post-metadata">

**Author:** ![Mark\_J\_Reed](https://avatars.discourse-cdn.com/v4/letter/m/f6c823/32.png) [@Mark\_J\_Reed](https://rubytalk.org/u/Mark_J_Reed)\
**Post date:** [18 September 2003 16:35 UTC](https://rubytalk.org/t/closing-stderr/8132/3 "2003-09-18T16:35:01Z")

</div>

If the third-party library is a Ruby library and is well-behaved,  
then you don’t have to mess with STDERR; just change $stderr to  
point to someplace else.

Remember: the global variable $stderr is where Ruby actually sends  
standard error output. The constant STDERR is just a saved  
copy of the value $stderr got when Ruby started up.

So something like this should do the trick:

begin  
$stderr = File.open(‘/dev/null’, ‘w’)  
ThirdPartyLib::call\_some\_annoying\_function  
ensure  
$stderr = STDERR  
end

If, on the other hand, the third-party library is not so well-behavied  
and messes with STDERR directly, then you can close it. But you need to save  
a copy of it first and restore it later.

begin  
errCopy = ($stderr = STDERR).dup  
STDERR.close  
ThirdPartyLib::call\_some\_annoying\_function  
ensure  
$stderr = errCopy   
STDERR = $stderr  
end

Note that you have to assign something open to $stderr before assigning  
to STDERR, or else the assignment to STDERR throws an exception trying to  
print the “already initialized constant” warning and the assignment  
doesn’t complete. There is probably a cleaner way of doing this.

Question on the subject of well-behaved libraries: if you invoke  
native code from Ruby, is that run with file descriptor 2 initially  
matching $stderr?

-Mark

> **···**
>
> On Fri, Sep 19, 2003 at 12:49:43AM +0900, Michael Garriss wrote:
> 
> > I would like to prevent some output that is going to stderr during a  
> > call to a third party lib just during that call. My first guess was:
> > 
> > STDERR.close\_write  
> > ThirdPartyLib::call\_some\_annoying\_function  
> > STDERR.???

---

<div class="post-metadata">

**Author:** ![Alan\_Davies1](https://avatars.discourse-cdn.com/v4/letter/a/9e8a1a/32.png) [@Alan\_Davies1](https://rubytalk.org/u/Alan_Davies1)\
**Post date:** [18 September 2003 16:34 UTC](https://rubytalk.org/t/closing-stderr/8132/4 "2003-09-18T16:34:54Z")

</div>

Robert Klemme wrote:

> “Michael Garriss” [mgarriss@earthlink.net](mailto:mgarriss@earthlink.net) schrieb im Newsbeitrag  
> [news:3F69D414.70008@earthlink.net](mailto:news:3F69D414.70008@earthlink.net)…
> 
> > I would like to prevent some output that is going to stderr during a  
> > call to a third party lib just during that call. My first guess was:
> > 
> > STDERR.close\_write  
> > ThirdPartyLib::call\_some\_annoying\_function  
> > STDERR.???
> > 
> > I guess you can see my problem. Can anyone give me a lead on this?
> > 
> > TIA,  
> > Michael
> 
> require ‘StringIO’
> 
> oldStdErr = $stderr  
> oldSTDERR = STDERR
> 
> $stderr = StringIO.new  
> STDERR = $stderr
> 
> begin
> 
> # lib call
> 
> ensure  
> $stderr = oldStdErr  
> STDERR = oldSTDERR  
> end
> 
> ```
> robert
> 
> ```

I did it like this on windows recently:

oldStderr = $stderr.dup  
$stderr.reopen(“NUL”, ‘w’)

$stderr.reopen(oldStderr)

Not sure if NUL works on linix/unix

---

<div class="post-metadata">

**Author:** ![Rudolf\_Polzer3](https://avatars.discourse-cdn.com/v4/letter/r/ecc23a/32.png) [@Rudolf\_Polzer3](https://rubytalk.org/u/Rudolf_Polzer3)\
**Post date:** [18 September 2003 16:35 UTC](https://rubytalk.org/t/closing-stderr/8132/5 "2003-09-18T16:35:02Z")

</div>

Scripsit illa aut ille »Robert Klemme« [bob.news@gmx.net](mailto:bob.news@gmx.net):

> “Michael Garriss” [mgarriss@earthlink.net](mailto:mgarriss@earthlink.net) schrieb im Newsbeitrag [news:3F69D414.70008@earthlink.net](mailto:news:3F69D414.70008@earthlink.net)…
> 
> > I would like to prevent some output that is going to stderr during a  
> > call to a third party lib just during that call. My first guess was:
> > 
> > STDERR.close\_write  
> > ThirdPartyLib::call\_some\_annoying\_function  
> > STDERR.???
> > 
> > I guess you can see my problem. Can anyone give me a lead on this?  
> > […]  
> > $stderr = StringIO.new  
> > STDERR = $stderr

Are you sure it occupies file descriptor 2 (which external libraries  
normally use)?

def without\_stderr(&block)  
save = $stderr.dup()  
$stderr.close() # this will affect STDERR, too.  
begin  
yield  
ensure  
$stderr = save.dup()  
# SIDE EFFECT: the file descriptor STDERR points to will be valid again  
end  
end

However, this routine assumes that all file descriptors before  
$stderr are used. This is the case unless $stdin or $stdout have  
been closed. Is there something like dup2() in Ruby?

> **···**
>
> –  
> The only thing that Babelfish is good at is proving that Vogons are  
> great poets.  
> Josef ‘Jupp’ Schugt in japan.anime.evangelion

---

<div class="post-metadata">

**Author:** ![Michael\_Garriss1](https://avatars.discourse-cdn.com/v4/letter/m/958977/32.png) [@Michael\_Garriss1](https://rubytalk.org/u/Michael_Garriss1)\
**Post date:** [18 September 2003 17:18 UTC](https://rubytalk.org/t/closing-stderr/8132/6 "2003-09-18T17:18:35Z")

</div>

Mark J. Reed wrote:

> 

> Note that you have to assign something open to $stderr before assigning  
> to STDERR, or else the assignment to STDERR throws an exception trying to  
> print the “already initialized constant” warning and the assignment  
> doesn’t complete. There is probably a cleaner way of doing this.

Thanks to all who responded!

Assign something open? I don’t understand. I get a syntax error on  
that assignment:

bin/ruglyctl:132:in `require': /usr/www/apache/rugly/lib/rdb_rugly.rb:40: dynamic constant assignment (SyntaxError) STDERR = $stderr ^ from bin/ruglyctl:132:in `handle\_db\_cmdtype’  
from bin/ruglyctl:146

Regards,  
Michael

---

<div class="post-metadata">

**Author:** ![Robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@Robert](https://rubytalk.org/u/Robert)\
**Post date:** [19 September 2003 08:37 UTC](https://rubytalk.org/t/closing-stderr/8132/7 "2003-09-19T08:37:19Z")

</div>

“Mark J. Reed” [markjreed@mail.com](mailto:markjreed@mail.com) schrieb im Newsbeitrag  
[news:20030918162950.GA14933@mulan.thereeds.org](mailto:news:20030918162950.GA14933@mulan.thereeds.org)…

> > I would like to prevent some output that is going to stderr during a  
> > call to a third party lib just during that call. My first guess was:
> > 
> > STDERR.close\_write  
> > ThirdPartyLib::call\_some\_annoying\_function  
> > STDERR.???
> 
> If the third-party library is a Ruby library and is well-behaved,  
> then you don’t have to mess with STDERR; just change $stderr to  
> point to someplace else.
> 
> Remember: the global variable $stderr is where Ruby actually sends  
> standard error output. The constant STDERR is just a saved  
> copy of the value $stderr got when Ruby started up.

Ah, thanks for reminding me!

> So something like this should do the trick:
> 
> begin  
> $stderr = File.open(‘/dev/null’, ‘w’)  
> ThirdPartyLib::call\_some\_annoying\_function  
> ensure  
> $stderr = STDERR  
> end

I typically prefer

$stderr = File.open(‘/dev/null’, ‘w’)  
begin  
ThirdPartyLib::call\_some\_annoying\_function  
ensure  
$stderr = STDERR  
end

because if the resource assignment (File.open) fails with an exception, no  
assignment takes place and thus $stderr = STDERR is superfluous. In this  
simple example there is no functional and not much performance difference  
but if the init and cleanup actions are more complex then it might indeed  
be crucial to follow the pattern to do the init before the block.

Just as an additional note, this complete scheme might break in  
multithreaded applications. You migh lose messages from other threads or  
other strange things. That’s the price of $globals…

> If, on the other hand, the third-party library is not so well-behavied  
> and messes with STDERR directly, then you can close it. But you need to  
> save  
> a copy of it first and restore it later.
> 
> begin  
> errCopy = ($stderr = STDERR).dup  
> STDERR.close  
> ThirdPartyLib::call\_some\_annoying\_function  
> ensure  
> $stderr = errCopy  
> STDERR = $stderr  
> end
> 
> Note that you have to assign something open to $stderr before assigning  
> to STDERR, or else the assignment to STDERR throws an exception trying  
> to  
> print the “already initialized constant” warning and the assignment  
> doesn’t complete. There is probably a cleaner way of doing this.

(see above)

> Question on the subject of well-behaved libraries: if you invoke  
> native code from Ruby, is that run with file descriptor 2 initially  
> matching $stderr?

Dunno.

Kind regards

```
robert

```

> **···**
>
> > On Fri, Sep 19, 2003 at 12:49:43AM +0900, Michael Garriss wrote:

---

<div class="post-metadata">

**Author:** ![Mark\_J\_Reed](https://avatars.discourse-cdn.com/v4/letter/m/f6c823/32.png) [@Mark\_J\_Reed](https://rubytalk.org/u/Mark_J_Reed)\
**Post date:** [18 September 2003 16:54 UTC](https://rubytalk.org/t/closing-stderr/8132/8 "2003-09-18T16:54:59Z")

</div>

Definitely not. It will just create a file in the current directory  
named “NUL”. 🙂

There are no magic filenames on \*N?X. There are, however, special  
files which refer to hardware devices rather than disk storage. These  
can be named anything, since it’s not the name that matters but  
the file attributes, but there is a standard set of such files  
in /dev on all systems. One of these is /dev/null, which points  
to the “null device”, which is not a real piece of hardware but a  
virtual device that just discards everything written to it.  
Another popular virtual device is /dev/zero, which will happily output  
zero bytes as long as you care to continue reading from it.

In any case, we came up with much the same solution, differing only  
in the filenames for the null device. The StringIO solution  
seems like a better choice for cross-platform compatibility, however.

-Mark

> **···**
>
> On Thu, Sep 18, 2003 at 05:28:31PM +0100, Alan Davies wrote:
> 
> > Not sure if NUL works on linix/unix

---

<div class="post-metadata">

**Author:** ![Mark\_J\_Reed](https://avatars.discourse-cdn.com/v4/letter/m/f6c823/32.png) [@Mark\_J\_Reed](https://rubytalk.org/u/Mark_J_Reed)\
**Post date:** [18 September 2003 18:15 UTC](https://rubytalk.org/t/closing-stderr/8132/9 "2003-09-18T18:15:15Z")

</div>

> Mark J. Reed wrote:
> 
> > Note that you have to assign something open to $stderr before assigning  
> > to STDERR, or else the assignment to STDERR throws an exception trying to  
> > print the “already initialized constant” warning and the assignment  
> > doesn’t complete. There is probably a cleaner way of doing this.
> 
> Assign something open? I don’t understand. I get a syntax error on  
> that assignment:

What I mean is that this assignment:

```
STDERR = blah

```

Generates a warning:

```
warning: already initialized constant STDERR

```

And that warning message is sent to - where else - $stderr.  
Which means if $stderr is still pointing to a closed File object  
at the time you try to assign to STDERR, Ruby tries to send the  
warning about the assignment, fails to do so because $stderr is  
closed, and aborts the assignment.

(It seems odd that failure to emit a warning would itself be fatal  
to the surrounding operation, but that’s the behavior I’m seeing  
on final 1.8.0)

> bin/ruglyctl:132:in `require’:  
> /usr/www/apache/rugly/lib/rdb\_rugly.rb:40: dynamic constant assignment  
> (SyntaxError)  
> STDERR = $stderr

Hm, I’m not sure what that means. Is this running in mod\_ruby?

-Mark

> **···**
>
> On Fri, Sep 19, 2003 at 02:18:35AM +0900, Michael Garriss wrote:

---

<div class="post-metadata">

**Author:** ![Robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@Robert](https://rubytalk.org/u/Robert)\
**Post date:** [19 September 2003 08:37 UTC](https://rubytalk.org/t/closing-stderr/8132/10 "2003-09-19T08:37:11Z")

</div>

“Rudolf Polzer” [denshimeiru-sapmctacher@durchnull.de](mailto:denshimeiru-sapmctacher@durchnull.de) schrieb im  
Newsbeitrag  
news:slrnbmjng5.kqp.denshimeiru-sapmctacher@message-id.durchnull.ath.cx…

> Scripsit illa aut ille »Robert Klemme« [bob.news@gmx.net](mailto:bob.news@gmx.net):
> 
> > “Michael Garriss” [mgarriss@earthlink.net](mailto:mgarriss@earthlink.net) schrieb im Newsbeitrag  
> > [news:3F69D414.70008@earthlink.net](mailto:news:3F69D414.70008@earthlink.net)…
> > 
> > > I would like to prevent some output that is going to stderr during a  
> > > call to a third party lib just during that call. My first guess  
> > > was:
> > > 
> > > STDERR.close\_write  
> > > ThirdPartyLib::call\_some\_annoying\_function  
> > > STDERR.???
> > > 
> > > I guess you can see my problem. Can anyone give me a lead on this?  
> > > […]  
> > > $stderr = StringIO.new  
> > > STDERR = $stderr
> 
> Are you sure it occupies file descriptor 2 (which external libraries  
> normally use)?
> 
> def without\_stderr(&block)  
> save = $stderr.dup()  
> $stderr.close() # this will affect STDERR, too.  
> begin  
> yield  
> ensure  
> $stderr = save.dup()  
> # SIDE EFFECT: the file descriptor STDERR points to will be valid  
> again  
> end  
> end
> 
> However, this routine assumes that all file descriptors before  
> $stderr are used. This is the case unless $stdin or $stdout have  
> been closed. Is there something like dup2() in Ruby?

This routine has a totally different problem: closing $stderr make the lib  
function abort because it will get an exception on writing to $stderr.  
$stderr has to be something that is open.

Regards

```
robert

```

---

<div class="post-metadata">

**Author:** ![Michael\_Garriss1](https://avatars.discourse-cdn.com/v4/letter/m/958977/32.png) [@Michael\_Garriss1](https://rubytalk.org/u/Michael_Garriss1)\
**Post date:** [18 September 2003 18:40 UTC](https://rubytalk.org/t/closing-stderr/8132/11 "2003-09-18T18:40:04Z")

</div>

Mark J. Reed wrote:

> **···**
>
> > On Fri, Sep 19, 2003 at 02:18:35AM +0900, Michael Garriss wrote:
> > 
> > > Mark J. Reed wrote:
> > > 
> > > > Note that you have to assign something open to $stderr before assigning  
> > > > to STDERR, or else the assignment to STDERR throws an exception trying to  
> > > > print the “already initialized constant” warning and the assignment  
> > > > doesn’t complete. There is probably a cleaner way of doing this.
> > > 
> > > Assign something open? I don’t understand. I get a syntax error on  
> > > that assignment:
> > 
> > What I mean is that this assignment:
> > 
> > STDERR = blah
> > 
> > Generates a warning:
> > 
> > warning: already initialized constant STDERR
> > 
> > And that warning message is sent to - where else - $stderr.  
> > Which means if $stderr is still pointing to a closed File object  
> > at the time you try to assign to STDERR, Ruby tries to send the  
> > warning about the assignment, fails to do so because $stderr is  
> > closed, and aborts the assignment.
> > 
> > (It seems odd that failure to emit a warning would itself be fatal  
> > to the surrounding operation, but that’s the behavior I’m seeing  
> > on final 1.8.0)
> > 
> > > bin/ruglyctl:132:in `require’:  
> > > /usr/www/apache/rugly/lib/rdb\_rugly.rb:40: dynamic constant assignment  
> > > (SyntaxError)  
> > > STDERR = $stderr
> > 
> > Hm, I’m not sure what that means. Is this running in mod\_ruby?
> 
> No, not running this code in mod\_ruby. It seems that the problem is  
> that it’s run from within a method. I guess I’m going to have to figure  
> out a way around that.
> 
> Michael

---

<div class="post-metadata">

**Author:** ![Rudolf\_Polzer3](https://avatars.discourse-cdn.com/v4/letter/r/ecc23a/32.png) [@Rudolf\_Polzer3](https://rubytalk.org/u/Rudolf_Polzer3)\
**Post date:** [19 September 2003 11:17 UTC](https://rubytalk.org/t/closing-stderr/8132/12 "2003-09-19T11:17:26Z")

</div>

Scripsit illa aut ille »Robert Klemme« [bob.news@gmx.net](mailto:bob.news@gmx.net):

> “Rudolf Polzer” [denshimeiru-sapmctacher@durchnull.de](mailto:denshimeiru-sapmctacher@durchnull.de) schrieb im Newsbeitrag  
> news:slrnbmjng5.kqp.denshimeiru-sapmctacher@message-id.durchnull.ath.cx…
> 
> > Scripsit illa aut ille »Robert Klemme« [bob.news@gmx.net](mailto:bob.news@gmx.net):
> > 
> > > “Michael Garriss” [mgarriss@earthlink.net](mailto:mgarriss@earthlink.net) schrieb im Newsbeitrag [news:3F69D414.70008@earthlink.net](mailto:news:3F69D414.70008@earthlink.net)…
> > > 
> > > > I would like to prevent some output that is going to stderr during a  
> > > > call to a third party lib just during that call. My first guess was:
> > > > 
> > > > STDERR.close\_write  
> > > > ThirdPartyLib::call\_some\_annoying\_function  
> > > > STDERR.???
> > > > 
> > > > I guess you can see my problem. Can anyone give me a lead on this?  
> > > > […]  
> > > > $stderr = StringIO.new  
> > > > STDERR = $stderr
> > 
> > Are you sure it occupies file descriptor 2 (which external libraries  
> > normally use)?
> > 
> > def without\_stderr(&block)  
> > save = $stderr.dup()  
> > $stderr.close() # this will affect STDERR, too.  
> > begin  
> > yield  
> > ensure  
> > $stderr = save.dup()  
> > # SIDE EFFECT: the file descriptor STDERR points to will be valid again  
> > end  
> > end
> > 
> > However, this routine assumes that all file descriptors before  
> > $stderr are used. This is the case unless $stdin or $stdout have  
> > been closed. Is there something like dup2() in Ruby?
> 
> This routine has a totally different problem: closing $stderr make the lib  
> function abort because it will get an exception on writing to $stderr.  
> $stderr has to be something that is open.

Then use the StringIO trick from the other posting.

I thought about an external library which is an interface to an  
existing C library which writes to stderr (file descriptor 2).

> **···**
>
> –  
> The only thing that Babelfish is good at is proving that Vogons are  
> great poets.  
> Josef ‘Jupp’ Schugt in japan.anime.evangelion

---

<div class="post-metadata">

**Author:** ![Mark\_J\_Reed](https://avatars.discourse-cdn.com/v4/letter/m/f6c823/32.png) [@Mark\_J\_Reed](https://rubytalk.org/u/Mark_J_Reed)\
**Post date:** [18 September 2003 19:15 UTC](https://rubytalk.org/t/closing-stderr/8132/13 "2003-09-18T19:15:23Z")

</div>

Oh, right. You can fix that with eval.

```
eval "STDERR = $stderr"

```

But this is getting uglier all the time. Are you sure the  
$stderr reassignment doesn’t work for you?

-Mark

> **···**
>
> On Fri, Sep 19, 2003 at 03:40:04AM +0900, Michael Garriss wrote:
> 
> > > > bin/ruglyctl:132:in `require’:  
> > > > /usr/www/apache/rugly/lib/rdb\_rugly.rb:40: dynamic constant assignment  
> > > > (SyntaxError)  
> > > > STDERR = $stderr
> > 
> > No, not running this code in mod\_ruby. It seems that the problem is  
> > that it’s run from within a method.

---

<div class="post-metadata">

**Author:** ![Robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@Robert](https://rubytalk.org/u/Robert)\
**Post date:** [19 September 2003 11:57 UTC](https://rubytalk.org/t/closing-stderr/8132/14 "2003-09-19T11:57:30Z")

</div>

“Rudolf Polzer” [denshimeiru-sapmctacher@durchnull.de](mailto:denshimeiru-sapmctacher@durchnull.de) schrieb im  
Newsbeitrag  
news:slrnbmloi3.bll.denshimeiru-sapmctacher@message-id.durchnull.ath.cx…

> > This routine has a totally different problem: closing $stderr make the  
> > lib  
> > function abort because it will get an exception on writing to $stderr.  
> > $stderr has to be something that is open.
> 
> Then use the StringIO trick from the other posting.
> 
> I thought about an external library which is an interface to an  
> existing C library which writes to stderr (file descriptor 2).

Even then one shouldt ensure that fd 2 is opened to something unless you  
know that the external lib simply doesn’t write to stderr if that is  
closed.

Regards

```
robert

```

---

<div class="post-metadata">

**Author:** ![Rudolf\_Polzer3](https://avatars.discourse-cdn.com/v4/letter/r/ecc23a/32.png) [@Rudolf\_Polzer3](https://rubytalk.org/u/Rudolf_Polzer3)\
**Post date:** [19 September 2003 12:37 UTC](https://rubytalk.org/t/closing-stderr/8132/15 "2003-09-19T12:37:35Z")

</div>

Scripsit illa aut ille »Robert Klemme« [bob.news@gmx.net](mailto:bob.news@gmx.net):

> “Rudolf Polzer” [denshimeiru-sapmctacher@durchnull.de](mailto:denshimeiru-sapmctacher@durchnull.de) schrieb:
> 
> > I thought about an external library which is an interface to an  
> > existing C library which writes to stderr (file descriptor 2).
> 
> Even then one shouldt ensure that fd 2 is opened to something unless you  
> know that the external lib simply doesn’t write to stderr if that is  
> closed.

write() to a closed FD fails, but most libs ignore the error. If  
they don’t, however, it needs to be reopened to something like  
/dev/null which isn’t possible in a platform-independent manner.

> **···**
>
> –  
> The only thing that Babelfish is good at is proving that Vogons are  
> great poets.  
> Josef ‘Jupp’ Schugt in japan.anime.evangelion