From: "Brian F. Feldman" <green@...>
Date: 2000-11-12T13:27:14+09:00
Subject: [ruby-talk:6288] lchown()/etc. and Unix syscall completeness

Ruby as it is now isn't very consistent with the system calls it provides.  
Many system call wrappers are provided, indeed most of the ones that I need.
For example, I need File.stat, and I also need File.lstat; they're both 
there.  But other useful ones are missing.  File.chmod and File.chown are 
there, but the l-prefixed syscalls like File.lchmod and File.lchown are
missing.

This makes Ruby more inconvenient when it comes to doing certain things.  In 
a recent script, I needed to do a mapping of one machine's uids and gids to 
those of anothers.  Duplicating files was done by an external program 
(cpdup) to preserve everything possible, then the proper transformations of 
uids gids had to be done.  The problem is that it would break on a File.chown
of a symlink; the obvious thing to do would to be use lchown(), but this
isn't provided now in Ruby so I had to use system("chown", "-h", file) :(

These cases will probably come up more and more as Ruby gets more users, so 
I'd like to know what everyone thinks at this point about filling out the 
Ruby syscall provisions more.  The l*() syscalls are important, in this 
example, and could be implemented so as to only be an alias for the non-l
syscalls on a system which doesn't support them.

I'd like to move forward in this, and I wonder what the best way would be.  
Some of the more esoteric system calls really are necessary but not on every 
platform that Ruby is on.  On those platforms, should a Errno::ENOSYS 
possibly be raised?  This would be the same as what a C program would do in 
that case.  Fallbacks should be provided when obvious, then.  Is it 
desirable to provide all useful system calls this way and conditionalize 
either the methods' presence or error return (depending?) on whether the 
current OS supports them?

I'm sorry if this is confusing.  It seems like there are several possible 
courses of action, and the worst (to me) would be to have to provide 
external libraries for common system calls or OS-dependent libraries (like 
doing "require 'freebsd'" if I want FreeBSD's extra system-dependent
syscalls).

--
 Brian Fundakowski Feldman           \  FreeBSD: The Power to Serve!  /
 green@FreeBSD.org                    `------------------------------'