Re: bash < execline > bash

[Eric Vidal]

On Sun, 1 May 2016 12:34:07 +0200
Laurent Bercot  wrote:

> On 01/05/2016 12:26, Eric Vidal wrote:
> > One more question, my knowledge is not sufficient to understand this 
> > following command :
> > unexport ?
> > i'm not understand the ? here
> 
>   ? is the environment variable set by the "foreground" command. It holds
> the exit code of the command run in the foreground block. In other words:
> "foreground { A } B" will run A, then it will run B with A's exit code
> contained in the ? environment variable.
> 
>   If no program in the rest of the chain is going to use this variable,
> it's best to unexport it - especially if the chain is going to fork a lot
> (as is the case with init).
> 
> 
> > unexport !
> 
>   Same thing. The ! environment variable is set by utilities like
> "background" or "pipeline", and contains the pid of the forked process.
> If nothing is going to use the value, better clean up the environment.
> 
> -- 
>   Laurent
> 
understood
Many Thank

-- 
Eric Vidal 

Re: bash < execline > bash

[Laurent Bercot]

On 01/05/2016 12:26, Eric Vidal wrote:

One more question, my knowledge is not sufficient to understand this following 
command :
unexport ?
i'm not understand the ? here


 ? is the environment variable set by the "foreground" command. It holds
the exit code of the command run in the foreground block. In other words:
"foreground { A } B" will run A, then it will run B with A's exit code
contained in the ? environment variable.

 If no program in the rest of the chain is going to use this variable,
it's best to unexport it - especially if the chain is going to fork a lot
(as is the case with init).



unexport !


 Same thing. The ! environment variable is set by utilities like
"background" or "pipeline", and contains the pid of the forked process.
If nothing is going to use the value, better clean up the environment.

--
 Laurent

Re: bash < execline > bash

[Eric Vidal]

On Sun, 1 May 2016 01:00:11 -0700
Colin Booth  wrote:

> On Sat, Apr 30, 2016 at 10:45 PM, Eric Vidal  wrote:
> > It is possible to have a zsh/bash and execlineb syntax on the same file?
> With some work yes. By default any execline script plays nice with
> interstitial programs that only do chain loading. So programs like
> nice, time, etc are all fine. It does not play nice with programs that
> terminate, however it provides the foreground and background programs
> to handle that.

understood

> > For example :
> > #!/bin/execlineb -P
> >
> > if [ -d /run/example ]; then
> > s6-mkdir -m 0755 /run/example
> > fi
> Not an execline script, this is pure shell with an alternate mkdir
> implementation. Using the execline interpreter is wrong here.
> >
> > or
> >
> > #!/bin/execlineb -P
> >
> > if { s6-test -d /run/example }
> > mkdir -m 0755 /run/example
> This is fine. The execline if program chain loads into the next
> program if its test passes, and while mkdir (and s6-mkdir) are not
> chain loading programs, as long as it is the last program in the
> script it doesn't matter. If you wanted to have the script do more
> work after the mkdir, you would need to rewrite your script as
> follows:
> #!/bin/execlineb -P
> if {s6-test -d /run/example }
> foreground { mkdir -m 0755 /run/example }
> rest_of_program
> 
> foreground is used to wrap a normal, terminating program with one that
> understands how to exec and is commonly used when a discrete one-shot
> program is needed within an execline program.

great thank for your explanation

One more question, my knowledge is not sufficient to understand this following 
command :
unexport ?
i'm not understand the ? here
or 
unexport !
the last one unexport the shebang/interpreter variable or my thought is on 
totally wrong way?
Can you explain me please?

Regards


-- 
Eric Vidal 

Re: rc-init misunderstanding dependencies files

[Eric Vidal]

> Within the examples, 00 is the root service that all other services
> depend on. Either through an explicit dependency call (like
> mount-proc) or through a bundle dependency (anything depending on
> ok-local will transitively depend on 00 since an explicit dependency
> on a bundle is an implicit dependency on every member of that bundle)

shame on me, i didn't seen the directory 00, i thought it was a special 
definition
This is clear now in theory ... i need a practice :) to understand 
correctly.

> A slight correction, rc-init doesn't run anything, it handles
> preparing the service tree. s6-rc change $SERVICE does the actual
> work. When s6-rc-compile packs the compiled form of the service
> directory it creates a stable ordering based on the dependency
> callouts. In the case of two services with equal weight (like if
> longrunA depends on oneshot1 and oneshot2, and both oneshots have no
> dependencies), s6-rc will run both nominally in parallel when it comes
> time to bring up the supervision tree. The only way to get the
> ordering that you describe, where s6-rc launches one service and then
> waits for the exit code before launching the second, is to have an
> explicit dependency called out in the second service.

understood

> > With this principle i can decide what service need to start first an 
> > another or after an another, right?
> For the most part yes. You can't have a service that says that it
> needs to run before another, but a dependency callout will guarantee
> that the listed services are started before the service defining those
> dependencies.

ok, i think the dependencies tree can be grow in complexity but with a practice 
it can be made.
Many thank

Regards

-- 
Eric Vidal