[9fans] rc: $* != '/env/*'

[9fans] rc: $* != '/env/*'

[Giacomo Tesio]

I have been a bit surprised to see that $* does not always contains
the same as '/env/*':

% echo $*

% cat '/env/*'
% lc
bin/ lib/ tmp/
% echo $*

% cat '/env/*'
/bin/lc%

Not really an issue, but why this happens?


Giacomo

Re: [9fans] rc: $* != '/env/*'

[Antons Suspans]

On Wed, Oct 18, 2017 at 05:31:28PM +0200, Giacomo Tesio wrote:
> I have been a bit surprised to see that $* does not always contains
> the same as '/env/*':
>
> % echo $*
>
> % cat '/env/*'
> % lc
> bin/ lib/ tmp/
> % echo $*
>
> % cat '/env/*'
> /bin/lc%
>
> Not really an issue, but why this happens?

I guess...

When starting a command from rc, execforkexec() does fork(), which
is an equivalent of rfork(RFFDG|RFREND|RFPROC) and does not imply RFENVG.

As lc(1) is a shell script, its shell instance sets /env/'*'.

Hope this helps.

--
Antons

Re: [9fans] rc: $* != '/env/*'

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]

yes. lc -- an rc script -- shares the environment with the rc that starts
it; so env is updated with arglist of lc. $* is the arglist that parent
(interactive) rc was started with. rc(1) says:

        $*       Set to rc's argument list during initialization.
                   Whenever a . command or a function is executed, the
                   current value is saved and $* receives the new
                   argument list.  The saved value is restored on com-
                   pletion of the . or function.

if lc was a function, there would be no surprises:

% cat /bin/lc
#!/bin/rc
ls -p $* | mc
% fn LC { ls -p $* | mc }
% echo $*

% cat '/env/*'
% LC >/dev/null
% echo $*

% cat '/env/*'
%

On Wed, Oct 18, 2017 at 9:02 AM Antons Suspans <antox@ml.lv> wrote:

> On Wed, Oct 18, 2017 at 05:31:28PM +0200, Giacomo Tesio wrote:
> > I have been a bit surprised to see that $* does not always contains
> > the same as '/env/*':
> >
> > % echo $*
> >
> > % cat '/env/*'
> > % lc
> > bin/ lib/ tmp/
> > % echo $*
> >
> > % cat '/env/*'
> > /bin/lc%
> >
> > Not really an issue, but why this happens?
>
> I guess...
>
> When starting a command from rc, execforkexec() does fork(), which
> is an equivalent of rfork(RFFDG|RFREND|RFPROC) and does not imply RFENVG.
>
> As lc(1) is a shell script, its shell instance sets /env/'*'.
>
> Hope this helps.
>
> --
> Antons
>
>

[-- Attachment #2: Type: text/html, Size: 2193 bytes --]

[9fans] rc: $* != '/env/*'

[Giacomo Tesio]

Pretty clear, thanks! :-)

So, to "fix" this rc would need an option to know to rfork(RFENVG)
before doing anything else.
Something like:

   -f [nNeEsfFm]   Start as a new process group using rfork(flags)

This way lc would produce not surprises by simply adding "-f e" to the
first line.

It shouldn't be an hard fix, but I wonder if it's actually worth the effort.


Also, probably -f is not the best flag here as it usually mean "file"...
-r would be a better choice, but it's taken for debugging output.
I might use -d for debugging output since -d is a no-op (why?) and -r
for this early rfork, but I have no idea of what it would broke.



Giacomo


2017-10-18 19:25 GMT+02:00 Skip Tavakkolian <skip.tavakkolian at gmail.com>:
> yes. lc -- an rc script -- shares the environment with the rc that starts
> it; so env is updated with arglist of lc. $* is the arglist that parent
> (interactive) rc was started with. rc(1) says:
>
>         $*       Set to rc's argument list during initialization.
>                    Whenever a . command or a function is executed, the
>                    current value is saved and $* receives the new
>                    argument list.  The saved value is restored on com-
>                    pletion of the . or function.
>
> if lc was a function, there would be no surprises:
>
> % cat /bin/lc
> #!/bin/rc
> ls -p $* | mc
> % fn LC { ls -p $* | mc }
> % echo $*
>
> % cat '/env/*'
> % LC >/dev/null
> % echo $*
>
> % cat '/env/*'
> %
>
> On Wed, Oct 18, 2017 at 9:02 AM Antons Suspans <antox at ml.lv> wrote:
>>
>> On Wed, Oct 18, 2017 at 05:31:28PM +0200, Giacomo Tesio wrote:
>> > I have been a bit surprised to see that $* does not always contains
>> > the same as '/env/*':
>> >
>> > % echo $*
>> >
>> > % cat '/env/*'
>> > % lc
>> > bin/ lib/ tmp/
>> > % echo $*
>> >
>> > % cat '/env/*'
>> > /bin/lc%
>> >
>> > Not really an issue, but why this happens?
>>
>> I guess...
>>
>> When starting a command from rc, execforkexec() does fork(), which
>> is an equivalent of rfork(RFFDG|RFREND|RFPROC) and does not imply RFENVG.
>>
>> As lc(1) is a shell script, its shell instance sets /env/'*'.
>>
>> Hope this helps.
>>
>> --
>> Antons
>>
>

Re: [9fans] rc: $* != '/env/*'

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]

i think 'rfork e' in lc will fix this; i'm not sure if it breaks anything
else.
i can't tell if this was an oversight or done on purpose. lc itself doesn't
seem all that useful or necessary.

On Wed, Oct 18, 2017 at 12:48 PM Giacomo Tesio <giacomo@tesio.it> wrote:

> Pretty clear, thanks! :-)
>
> So, to "fix" this rc would need an option to know to rfork(RFENVG)
> before doing anything else.
> Something like:
>
>    -f [nNeEsfFm]   Start as a new process group using rfork(flags)
>
> This way lc would produce not surprises by simply adding "-f e" to the
> first line.
>
> It shouldn't be an hard fix, but I wonder if it's actually worth the
> effort.
>
>
> Also, probably -f is not the best flag here as it usually mean "file"...
> -r would be a better choice, but it's taken for debugging output.
> I might use -d for debugging output since -d is a no-op (why?) and -r
> for this early rfork, but I have no idea of what it would broke.
>
>
>
> Giacomo
>
>
> 2017-10-18 19:25 GMT+02:00 Skip Tavakkolian <skip.tavakkolian@gmail.com>:
> > yes. lc -- an rc script -- shares the environment with the rc that starts
> > it; so env is updated with arglist of lc. $* is the arglist that parent
> > (interactive) rc was started with. rc(1) says:
> >
> >         $*       Set to rc's argument list during initialization.
> >                    Whenever a . command or a function is executed, the
> >                    current value is saved and $* receives the new
> >                    argument list.  The saved value is restored on com-
> >                    pletion of the . or function.
> >
> > if lc was a function, there would be no surprises:
> >
> > % cat /bin/lc
> > #!/bin/rc
> > ls -p $* | mc
> > % fn LC { ls -p $* | mc }
> > % echo $*
> >
> > % cat '/env/*'
> > % LC >/dev/null
> > % echo $*
> >
> > % cat '/env/*'
> > %
> >
> > On Wed, Oct 18, 2017 at 9:02 AM Antons Suspans <antox@ml.lv> wrote:
> >>
> >> On Wed, Oct 18, 2017 at 05:31:28PM +0200, Giacomo Tesio wrote:
> >> > I have been a bit surprised to see that $* does not always contains
> >> > the same as '/env/*':
> >> >
> >> > % echo $*
> >> >
> >> > % cat '/env/*'
> >> > % lc
> >> > bin/ lib/ tmp/
> >> > % echo $*
> >> >
> >> > % cat '/env/*'
> >> > /bin/lc%
> >> >
> >> > Not really an issue, but why this happens?
> >>
> >> I guess...
> >>
> >> When starting a command from rc, execforkexec() does fork(), which
> >> is an equivalent of rfork(RFFDG|RFREND|RFPROC) and does not imply
> RFENVG.
> >>
> >> As lc(1) is a shell script, its shell instance sets /env/'*'.
> >>
> >> Hope this helps.
> >>
> >> --
> >> Antons
> >>
> >
>
>

[-- Attachment #2: Type: text/html, Size: 3701 bytes --]

[9fans] rc: $* != '/env/*'

[Giacomo Tesio]

2017-10-19 6:48 GMT+02:00 Skip Tavakkolian <skip.tavakkolian at gmail.com>:
> i think 'rfork e' in lc will fix this; i'm not sure if it breaks anything
> else.

Actually 'rfork e' in lc fixes this.
I did not even tried because I assumed that /env/* was written at rc
startup, before reading the input script.
I was wrong, actually, but now I wonder when it's written... probably
just before the first exec.

> i can't tell if this was an oversight or done on purpose. lc itself doesn't
> seem all that useful or necessary.

As for lc, I use it pretty often :-)

But actually I asked about the "dirty" /env/* because I thought it
could have had a purpose I was missing.


Giacomo