Thanks Skip and Anthony for the scripts!
Okay, that makes sense. What is the reason for performing namespace
inheritance by copy as opposed to namespace inheritance by reference?
Is it just to simplify the implementation?
It seems like it might be useful. For example, if you had a daemon
that automatically reacted to devices, like USB drives and CDs being
attached and mounted them in the namespace, then you might want
processes to inherit from it so they would see new mounts.
Also, a totally random question: It seems like poor ergonomics that
one must create empty directories in order to serve as mount points.
Why not just allow mounting to names that don't exist yet?
On Sat, May 21, 2016 at 5:06 AM, Anthony Martin <al...@pbrane.org> wrote:
> Anthony Martin <al...@pbrane.org> once said:
>> Casey Rodarmor <ca...@rodarmor.com> once said:
>> > Also, whatever the answer is, how can I test this for myself? I was
>> > struggling to come up with a combination of commands, short of writing
>> > some C programs, which would let me have two interactive rc shells
>> > that inherit from one another, since rc doesn't have job control and
>> > new rio windows are in a new process group.
>>
>> In one rio window, do the following:
>>
>> % mkdir -p /tmp/wsys
>> % mount $wsys /tmp/wsys 'new -r 0 0 512 512 -pid '$pid
>> % { rc -i <>/tmp/wsys/cons >[1=0] >[2=0] } &
>>
>> Any further changes to the namespace will be reflected in both windows.
>
> I was playing around with this a bit more and I came
> up with something a bit cleaner. The following command
> will create an interactive shell in a new window that
> shares the namespace of it's parent and acts like a
> normal rio window (as much as possible).
>
> Cheers,
> Anthony
>
> #!/bin/rc
>
> rfork e
>
> mkdir -p /tmp/wsys
> mount $wsys /tmp/wsys 'new -r 0 0 640 480 -pid -1'
> {
> rc -i /tmp/wsys/cons >[2=1] &
> rcpid = $apid
> echo set -pid $rcpid >/tmp/wsys/wctl
> echo -n rc $rcpid >/tmp/wsys/label
> wait $rcpid
> echo delete >/tmp/wsys/wctl
> } &
>
