Richard Guenther wrote:
> > - Open fd 3, pass /proc/self/fd/3 as the script name.
>
> And rewrite each program to _not_ open("/proc/self/fd/3") as
> this is just a symlink to the real file, i.e. I could have passed
> the filename right away.
No, /proc/self/fd/3 is not an ordinary symlink although it looks like
one to `ls'. It always reopens the correct file. Programs do not have
to be changed, and it doesn't have the same race condition as passing
the filename.
> stdin replacement seems the only way to deal with this _without_
> rewriting the interpreters to know about /proc/self/script.
Why would the interpreters need rewriting?
> [I could just add an option to interpreter to take a fd as argument
> anyway]
>
> > - Pass /proc/self/script as the script name and add code to proc
> > to support this -- this provides the interpreter with fds 0,1 & 2
> > as the only open ones which it may be expecting.
>
> see above. of course, with appropriate /proc/self/script that handles
> open() just fine (in fact ignores the open and just returns the fd)
> this would be fine.
> Implementation would be ugly though. How (where)
> do you pass the information to /proc? (that 3 is the script fd)
> Probably you have to add this to struct task?
The point of /proc/self/script is that no fd is allocated until it is
opened -- for interpreters that expect the next free fd to be number 3.
Yes I would add it to struct task.
> or just reserve fd number 3 for this and nothing else (would this
> break any userspace semantics? i.e. open() never returns fd 3, fd 3
> is reserved for script passing only).
If you're going to reserve fd number 3, /proc/self/fd/3 is exactly the
right way to refer to this. Of course opening it returns fd 4, but
that's not so bad is it?
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/