Dmitry Bogatov:
I believe I already wrote in init-d-script(5) correct invocation:
#!/usr/bin/env /lib/init/init-d-script
That's not what was in the skeleton that you just got rid of; which had
more attention paid to it than the example in the manual page had, I
suspect.
The next portabilit
Michael Biebl:
fwiw, this is why I suggested to provide a C implementation of
init-d-script which can be used as an interpreter
That's how it was addressed in 2007.
*
https://github.com/OpenRC/openrc/commit/5af58b45146ab5253ca964738f4e45287bf963d4
*
http://www.chiark.greenend.org.uk/piperm
[2018-11-20 21:25] Michael Biebl
> fwiw, this is why I suggested to provide a C implementation of
> init-d-script which can be used as an interpreter
>
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913247
>
> I consider the usage of /usr/bin/env only a kludge and hope the
> maintaine
Michael Biebl writes ("Bug#822753: /lib/init/init-d-script: exit 0 at end of
script prevents all other exit codes"):
> I consider the usage of /usr/bin/env only a kludge
Are there practical problems with use of /usr/bin/env this way ? This
is a very traditional technique for solvi
[2018-11-20 10:15] Jonathan de Boyne Pollard
>
> part text/plain1073
> Dmitry Bogatov:
>
> > Can you please elaborate, what exactly would break?
>
> Look at the way that the init-d-script script is used. It isn't used as
> the interpreter of an rc script. (Your manual ne
On Tue, 20 Nov 2018 10:15:33 + Jonathan de Boyne Pollard
wrote:
> Dmitry Bogatov:
>
> > Can you please elaborate, what exactly would break?
> >
>
> Look at the way that the init-d-script script is used. It isn't used as
> the interpreter of an rc script. (Your manual needs fixing to show
Dmitry Bogatov:
Can you please elaborate, what exactly would break?
Look at the way that the init-d-script script is used. It isn't used as
the interpreter of an rc script. (Your manual needs fixing to show the
correct way to invoke it, by the way.) It is invoked as:
#!/bin/sh
if [ tr
[Dmitry Bogatov]
> Can you please elaborate, what exactly would break? Probably there is
> better solution for those issues that just swallowing error codes.
I do not remember the details any more, but after reading the git
history I have vague memories of having to add the exit calls to ensure
sc
(re-sending with un-mangled bug address)
Dmitry Bogatov writes ("Re: /lib/init/init-d-script: exit 0 at end of script
prevents all other exit codes"):
> Wait, no. There is. See #427889 and policy 9.3.2. By the way, seems
> #427889 could be closed...
>
> Also, by just common sence, program that r
control: reopen -1
[2018-11-15 18:02] Benda Xu
> Petter Reinholdtsen writes:
>
> > [Benda Xu]
> >> Do you think init-d-script unconditionally returning 0 is a typo?
> >> Should it be `exit $?` instead?
> >
> > Not quite sure, but as far as I know, the init.d scripts do not have a
> > standard
Hi Brenda,
[Benda Xu]
> Do you think init-d-script unconditionally returning 0 is a typo?
> Should it be `exit $?` instead?
Not quite sure, but as far as I know, the init.d scripts do not have a
standard for exit codes. There is no use of exit codes from init.d
scripts in /etc/init.d/rc. Erro
Hi Petter,
Dmitry Bogatov writes:
> I do agree, that this line looks strange. It was introduced at commit
> `f611a05d16b3094139c2ea540817c00bdf93347a' with following comment:
>
> Make sure init-d-script exit at the end, to make sure init.d
> script is only sourced once.
>
> at 20 Feb
[2016-04-26 23:41] J Mo
> Package: sysvinit-utils
> Version: 2.88dsf-59.3
> Severity: important
>
> The last line of /lib/init/init-d-script is "exit 0".
> That can't be right, can it? This overrides all other valid return
> codes which could be provid ed by the script. In almost all cases,
>
Package: sysvinit-utils
Version: 2.88dsf-59.3
Severity: important
The last line of /lib/init/init-d-script is "exit 0".
That can't be right, can it? This overrides all other valid return codes which
could be provided by the script. In almost all cases, even errors, $? is going
to be 0.
-- S
14 matches
Mail list logo