System() shouldn't throw exceptions, should it?

ruby-talk
1

While building a Rubyx distro (the build script is written in ruby) a user has
reported this error:

Making 'whatis' database...

Unmounting proc
/mnt/rubyx/rubyx-76/rubyx:946:in `system': No such file or directory -
makewhatis /man (Errno::ENOENT)
        from /mnt/rubyx/rubyx-76/rubyx:946:in `install'
        from /mnt/rubyx/rubyx-76/rubyx:800:in `each'
        from /mnt/rubyx/rubyx-76/rubyx:800:in `install'
        from /mnt/rubyx/rubyx-76/rubyx:1492
        from /mnt/rubyx/rubyx-76/rubyx:1087:in `catch'
        from /mnt/rubyx/rubyx-76/rubyx:1087
root@aydindril:/mnt/rubyx/linux-2.6.7/linux-2.6.7#

The bit of code running here looks like this:

if $root=='/'
        puts("Making 'whatis' database...")
        system("makewhatis /man")
end

Now makewhatis is not available, but the system() command has thrown an
exception, which shouldn't happen (should it?).

According to ri system,

--------------------------------------------------------- Kernel::system
     system( aCmd [, args]* ) -> true or false

···

------------------------------------------------------------------------
     Executes aCmd in a subshell, returning true if the command was
     found and ran successfully, false otherwise. A detailed error code
     is available in $?. The arguments are processed in the same way as
     for Kernel::exec on page 419.

So on failure it should just return false?

Am I reading this correctly? Could this be ruby version specific?

Andrew Walrond

2

The user reports this was a nightly snapshot:

"ruby 1.9.0 (2004-06-25) [i686-linux]"

3

Hi,

At Tue, 29 Jun 2004 04:22:27 +0900,
Andrew Walrond wrote in [ruby-talk:104791]:

Am I reading this correctly? Could this be ruby version specific?

Yes, it was changed in the February.

···

--
Nobu Nakada

4

Just so I've got this clear in my mind...

This is an intentional change, and I should expect this new behaviour in
future releases of ruby?

Will it appear in the current series of stable snapshots? Or is it slated for
1.9 onwards?

I don't think I overstate the case if I say that this change is going to bust
a whole lot of ruby code; system() is fairly fundamental...

Shouldn't this new functionality be moved to 'system2()' or something?

Andrew Walrond

···

On Tuesday 29 Jun 2004 02:20, nobu.nokada@softhome.net wrote:

Yes, it was changed in the February.

5

I think that throwing an exception is a much more appropriate and
idiomatic way to handle errors than just silently failing. If it's
going to break a lot of your code, though, why not use something like
the following at the top of your top-level library code (or, include
it in another library called something like 'old-system.rb'):

major, minor, release = VERSION.split('.').collect {|s| s.to_i}
if (major == 1 and minor > 8) or (major > 1)
  alias new_system system
  def system(*args)
    begin
      new_system(*args)
    rescue Errno::ENOENT
      return false
    end
  end
end

...or something similar.

Lennon

6

I agree. It would have been better to throw exceptions, and I can easily
change my code to handle either case, as you suggest.

But...

I guess I was a bit suprised that this fundamental behaviour was changed; It
obviously breaks backwards compatibility with previous versions; It broke at
least one of my apps and I'll have to audit the rest. Many existing apps
_will_be_broken_ by this change.

Hence my question: Assuming the change is intentional, when will it appear in
a release (this cropped up with somebody using a nightly snapshot)

Andrew Walrond

···

On Tuesday 29 Jun 2004 17:18, Lennon Day-Reynolds wrote:

I think that throwing an exception is a much more appropriate and
idiomatic way to handle errors than just silently failing. If it's
going to break a lot of your code, though, why not use something like

7

see my RCR/BUG? thread - i think it's even worse than you are already pointing
out...

-a

···

On Wed, 30 Jun 2004, Andrew Walrond wrote:

On Tuesday 29 Jun 2004 17:18, Lennon Day-Reynolds wrote:

I think that throwing an exception is a much more appropriate and
idiomatic way to handle errors than just silently failing. If it's
going to break a lot of your code, though, why not use something like

I agree. It would have been better to throw exceptions, and I can easily
change my code to handle either case, as you suggest.

But...

I guess I was a bit suprised that this fundamental behaviour was changed; It
obviously breaks backwards compatibility with previous versions; It broke at
least one of my apps and I'll have to audit the rest. Many existing apps
_will_be_broken_ by this change.

Hence my question: Assuming the change is intentional, when will it appear in
a release (this cropped up with somebody using a nightly snapshot)

Andrew Walrond

--

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
A flower falls, even though we love it;
and a weed grows, even though we do not love it. --Dogen

===============================================================================