Arbitrary IO object

Hi,

How would I go about using IO.new such that it would automatically
grab the next available file descriptor? I don't know the fileno in
advance and I can't use StringIO.

What are my options?

Thanks,

Dan

How would I go about using IO.new such that it would automatically
grab the next available file descriptor?

Not sure what you mean: File.open uses a new file descriptor. Why would you care about the file descriptor numbering?

I don't know the fileno in
advance and I can't use StringIO.

Why would you want to use StringIO to read from files?

What are my options?

What are you trying to achieve?

Kind regards

  robert

···

On 20.05.2008 18:40, Daniel Berger wrote:

I'm tinkering with possibly reimplementing win32-open3 using the win32-
process library. You can redirect stdin, stdout and stderr like so:

info = Process.create(
   input = IO.new(x, 'w+') # Want next available fd
   output = IO.new(y, 'w+') # Want next available fd
   error = IO.new(z, 'w+') # Want next available fd

   :app_name => command,
   :creation_flags => Process::DETACHED_PROCESS,
   :startup_info => {
      :stdin => input,
      :stdout => output,
      :stderr => error
   }
)

pid = info.process_id

return [input, output, error, pid]

That's the general idea, anyway.

Regards,

Dan

···

On May 20, 11:25 am, Robert Klemme <shortcut...@googlemail.com> wrote:

On 20.05.2008 18:40, Daniel Berger wrote:

> How would I go about using IO.new such that it would automatically
> grab the next available file descriptor?

Not sure what you mean: File.open uses a new file descriptor. Why would
you care about the file descriptor numbering?

> I don't know the fileno in
> advance and I can't use StringIO.

Why would you want to use StringIO to read from files?

> What are my options?

What are you trying to achieve?

IO.new is for associating a Ruby IO object with
an already open OS file descriptor. So you've got
to acquire the file descriptor through some non-Ruby
mechanism in order to be useful via IO.new. You can
use IO#fileno to discover the underlying OS file
descriptor from a Ruby object but if you've already
got a Ruby IO object you don't need to use IO.new.

At the C/POSIX level I don't think there is really
any concept of specifying the 'next available fd'.
You just call open/create/pipe/dup and use the integer
file descriptors that are returned. The OS figures
out which integer descriptors are available.

Gary Wright

···

On May 20, 2008, at 1:34 PM, Daniel Berger wrote:

info = Process.create(
   input = IO.new(x, 'w+') # Want next available fd
   output = IO.new(y, 'w+') # Want next available fd
   error = IO.new(z, 'w+') # Want next available fd

   :app_name => command,
   :creation_flags => Process::DETACHED_PROCESS,
   :startup_info => {
      :stdin => input,
      :stdout => output,
      :stderr => error
   }
)

How would I go about using IO.new such that it would automatically
grab the next available file descriptor?

Not sure what you mean: File.open uses a new file descriptor. Why would
you care about the file descriptor numbering?

I don't know the fileno in
advance and I can't use StringIO.

Why would you want to use StringIO to read from files?

What are my options?

What are you trying to achieve?

I'm tinkering with possibly reimplementing win32-open3 using the win32-
process library. You can redirect stdin, stdout and stderr like so:

info = Process.create(
   input = IO.new(x, 'w+') # Want next available fd
   output = IO.new(y, 'w+') # Want next available fd
   error = IO.new(z, 'w+') # Want next available fd

It does not seem to make sense to open all these both for reading and writing.

   :app_name => command,
   :creation_flags => Process::DETACHED_PROCESS,
   :startup_info => {
      :stdin => input,
      :stdout => output,
      :stderr => error
   }
)

Not sure what this is supposed to do - this isn't even valid Ruby as far as I can see:

$ ruby -c <<EOF
> info = Process.create(
> input = IO.new(x, 'w+') # Want next available fd
> output = IO.new(y, 'w+') # Want next available fd
> error = IO.new(z, 'w+') # Want next available fd
>
> :app_name => command,
> :creation_flags => Process::DETACHED_PROCESS,
> :startup_info => {
> :stdin => input,
> :stdout => output,
> :stderr => error
> }
> )
> EOF
-:3: syntax error, unexpected tIDENTIFIER, expecting ')'
    output = IO.new(y, 'w+') # Want next available fd
          ^
-:6: syntax error, unexpected tASSOC, expecting $end
    :app_name => command,
                      ^

$

pid = info.process_id

return [input, output, error, pid]

That's the general idea, anyway.

You only have two options:

- you overlay a process, then it makes sense that the new process inherits all standard file descriptors (0,1,2 - stdin, stdout, stderr). Usually nothing needs to be done for this (at least on POSIX systems)

- you copy the process (fork on POSIX) and want to be in control of the child' IO, in that case you need to establish pipes to feed stdin and read from stdout and stderr.

Kind regards

  robert

···

On 20.05.2008 19:34, Daniel Berger wrote:

On May 20, 11:25 am, Robert Klemme <shortcut...@googlemail.com> wrote:

On 20.05.2008 18:40, Daniel Berger wrote:

Yep, looks like I should just use IO.pipe.

Thanks,

Dan

···

On May 20, 12:36 pm, Gary Wright <gwtm...@mac.com> wrote:

On May 20, 2008, at 1:34 PM, Daniel Berger wrote:

> info = Process.create(
> input = IO.new(x, 'w+') # Want next available fd
> output = IO.new(y, 'w+') # Want next available fd
> error = IO.new(z, 'w+') # Want next available fd

> :app_name => command,
> :creation_flags => Process::DETACHED_PROCESS,
> :startup_info => {
> :stdin => input,
> :stdout => output,
> :stderr => error
> }
> )

IO.new is for associating a Ruby IO object with
an already open OS file descriptor. So you've got
to acquire the file descriptor through some non-Ruby
mechanism in order to be useful via IO.new. You can
use IO#fileno to discover the underlying OS file
descriptor from a Ruby object but if you've already
got a Ruby IO object you don't need to use IO.new.

At the C/POSIX level I don't think there is really
any concept of specifying the 'next available fd'.
You just call open/create/pipe/dup and use the integer
file descriptors that are returned. The OS figures
out which integer descriptors are available.