Re: Question about enable-absolute-paths option

[Shengjing Zhu]

On Mon, Sep 10, 2018 at 4:17 AM Laurent Bercot  wrote:
>   Red Hat distributions provided a /usr/bin/cd program for some time,
> that did exactly that. Maybe it's still around on Fedora/CentOS.
>

They still have /usr/bin/{cd, umask, wait}, which are just

#!/bin/sh
builtin cd/umask/wait "$@"


-- 
Shengjing Zhu

Re: Question about enable-absolute-paths option

[Laurent Bercot]

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906250#22

 That's an incredibly disingenuous argument. Debian isn't POSIX-
compliant by any stretch of the imagination, and they currently
don't provide POSIX-compliant cd/umask/wait binaries because they
have correctly identified that those binaries are useless and
never called by other programs, *ever*. Using that argument to
deny getting binaries that actually implement the same functionality
in a useful way is nothing short of dishonest.

 No shell will ever defer to external commands to implement cd, umask
or wait, because those commands cannot work as external programs. It
simply makes no sense to have them in external programs - unless they
exec into the rest of their command line, which is exactly what
the execline versions of these programs do.

 If writing POSIX-compatible versions of cd and umask (as in,
accept the POSIX-defined options), that *additionally* exec into
the rest of their command line when one is provided (and exit 0
otherwise), which is not forbidden by POSIX, would appease Debian
developers, I can do it: it's not that much bloat.

 Unfortunately, the same approach isn't possible for wait, because
there has to be a way to separate the list of pids from the rest of
the command line. execline uses a block for this; POSIX just assumes
the wait command isn't followed by a command line and only takes a
list of pids. This *forces* the wait command to be a shell intrinsic.
Such a "wait" *cannot* be implemented as an external program: it
would simply not be able to wait for the given lists of pids, except
in a very specific case, "exec wait", where it's run as the last
command in a shell script. So, the POSIX requirement to have "wait"
available as an external command is entirely nonsensical.

 Maybe the Debian developers would be okay with a different name: what
if the command were named "waitpid" instead? I don't like the idea
of changing names (that's a major version bump, and then script porting
busywork for all users) but I could make an exception to avoid treading
on POSIX, even if that part of POSIX is utterly idiotic.



This bug is closed, and there is now an execline package in Debian
Sid, so it seems that some resolution has been settled on. However,
I'd still like to understand what's the interpretation of the
'exec-ability' requirement raised in message #22, and its connection
with the placement of execline binaries. The wording used in the
contained links to POSIX confuses me. If someone feels like
explaining, to be concrete, what should a compliant 'execution
environment' do when presented a C program that contains an
execlp("cd", "cd" "blahblah", (char *)0) or execlp("umask", "umask",
"022", (char *)0) call?


 The execution environment will exec into cd, which will chdir() to
blahblah, then exit. Or it will exec into umask, which will
umask(022), then exit. Most useful programs ever.
 Red Hat distributions provided a /usr/bin/cd program for some time,
that did exactly that. Maybe it's still around on Fedora/CentOS.

 It would not be difficult to make execline's cd and umask
POSIX-compliant. But that solution doesn't apply to wait.

--
 Laurent

Re: Question about enable-absolute-paths option

[Laurent Bercot]

However the binaries(cd, umask, wait) that cause problem are not
dependency of s6.


 Those binaries are not causing problems.
 What *is* causing problems is fellow developers who *think* those
binaries are problematic, for reasons that all come from ignorance
of how Unix (and the shell) works.

 This is, as you have stated, a political issue. It is not a technical
issue, and in particular, it is not a technical issue with execline.
So, please avoid framing it as if it was.

 I totally understand your predicament, but I unfortunately have no
good solution for you, except "educate your peers". Political problems
are not solved with technical fixes, and when you try to do so, not
only do you not entirely fix the political problems, but you also add
technical problems on top. This never ends well.

--
 Laurent

Re: Question about enable-absolute-paths option

[Colin Booth]

On Mon, Sep 03, 2018 at 12:46:10PM +0800, Shengjing Zhu wrote:
> On Mon, Sep 3, 2018 at 5:36 AM Guillermo  wrote:
> > You don't need to do that. You *can* install the full set of execline
> > binaries in /usr/lib/execline using --enable-absolute-paths, (and you
> > should add --shebangdir=\$${prefix}/lib/execline too), just like in
> > your OP. Both s6 and s6-rc should work fine with it.
> >
> > I think currently only fdmove, fdclose and execlineb are called by s6
> > binaries, but you should't rely on a list of execline binaries that s6
> > uses. This list can change from release to release as the author
> > pleases.
> >
> 
> Got it.
> 
Another option is to pass an alternate --with-default-path to the
skalibs compilation that includes /usr/lib/execline. It isn't perfect
because you'll need to call emptyenv in order to flush the default
environment in stand-alone execline scripts, but it will work in a pinch
since all execline utilities will fail back to the compiled-in defaults
if $PATH is unavailable.

-- 
Colin Booth

Re: Question about enable-absolute-paths option

[Shengjing Zhu]

On Mon, Sep 3, 2018 at 5:36 AM Guillermo  wrote:
> You don't need to do that. You *can* install the full set of execline
> binaries in /usr/lib/execline using --enable-absolute-paths, (and you
> should add --shebangdir=\$${prefix}/lib/execline too), just like in
> your OP. Both s6 and s6-rc should work fine with it.
>
> I think currently only fdmove, fdclose and execlineb are called by s6
> binaries, but you should't rely on a list of execline binaries that s6
> uses. This list can change from release to release as the author
> pleases.
>

Got it.

> Your setup sort of did this already. You can't easily write or use
> execline scripts with it other than those generated automatically by
> skarnet.org packages like s6-rc. It is better than packaging half or
> less of execline, or not packaging it at all, I suppose, but
> relegating execline to being some kind of s6 backend, and not being
> able to directly use it without some PATH management contortions
> greatly diminishes the usefulness of such a Debian package, I think.
>

The main difference is whether users get a "broken" package or can't get at all.

Maybe I could just name the package like libexecline(which has
binaries as helper programs). Then users will think they can't get an
execline pacakge.

-- 
Shengjing Zhu 
GPG Key: 0xCF0E265B7DFBB2F2
Homepage: https://zhsj.me

Re: Question about enable-absolute-paths option

[Guillermo]

El dom., 2 sept. 2018 a las 13:48, Shengjing Zhu escribió:
>
> From your previous comment, s6 not only uses execline library, but
> also its binaries. Can I get a list of binaries that s6 will use? So I
> can only package these.

You don't need to do that. You *can* install the full set of execline
binaries in /usr/lib/execline using --enable-absolute-paths, (and you
should add --shebangdir=\$${prefix}/lib/execline too), just like in
your OP. Both s6 and s6-rc should work fine with it.

I think currently only fdmove, fdclose and execlineb are called by s6
binaries, but you should't rely on a list of execline binaries that s6
uses. This list can change from release to release as the author
pleases.

> As a result, users won't get execline from Debian, but just s6 […]

Your setup sort of did this already. You can't easily write or use
execline scripts with it other than those generated automatically by
skarnet.org packages like s6-rc. It is better than packaging half or
less of execline, or not packaging it at all, I suppose, but
relegating execline to being some kind of s6 backend, and not being
able to directly use it without some PATH management contortions
greatly diminishes the usefulness of such a Debian package, I think.

G.

Re: Question about enable-absolute-paths option

[Laurent Bercot]

But I probably will not install binaries like `if, exec, wait` to
default PATH(like /usr/bin). Although I understand this is possible
technically(and currently no other programs claim these names).

The actual reason is that I can't afford time to argue with other
developers. When I ask on debian-devel list, at least someone is
object to this[1].


 I will then suggest that you refrain from packaging execline for
Debian until your fellow developers stop forcing you to "fix" things
that are only a problem in their imaginations - causing very real
breakage with the "fixes".

 Users deserve packages done the right way. They do not deserve
software that is broken by distribution bigotry.

--
 Laurent

Re: Question about enable-absolute-paths option

[Casper Ti. Vector]

On Sun, Sep 02, 2018 at 11:17:20PM +0800, Shengjing Zhu wrote:
> The actual reason is that I can't afford time to argue with other
> developers. When I ask on debian-devel list, at least someone is
> object to this[1]. I'd to admit that I'm not good at argument. The
> simple solution I see is to put notes in the debian package.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906250

Actually, there can be a compromised plan: implement the chainloading
functionalities in Scheme, and the execlineb interpreter as well as the
commands like `if' and `background' would no longer be necessary [1].
This plan still requires the presence of commands like `cd' and `wait'
$PATH, but the number of commands which the Debian people consider
"confusing" is greatly reduced.  (Disclaimer: this is my own suggestion,
and will probably not be endorsed by Laurent.)

[1] .

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Question about enable-absolute-paths option

[Laurent Bercot]

Thanks for this note, I haven't looked at these packages. At first I
thought execline binaries will only be called inside execlinep
scripts. Could you give some examples that s6 calls these binaries
directly except exelinep?


 In addition to what Casper said: for instance, some of the
s6-fdholder-* utilities in the s6 package assume that the "fdclose"
and "fdmove" programs are accessible via a PATH search.

 The point of execline is to allow the user to embed control commands
into a single argv. This is useful regardless of the execlineb
binary, whose sole purpose is to convert a text file into an argv.



I try this because I find document(INSTALL) says there's
--enable-absolute-paths option. And

 This will ensure that programs calling binaries from
 this package will call them with their full installation path (in 
bindir)

 without relying on a PATH search.

So either I misunderstand the document or this feature hasn't been 
implemented.


 This option ensures compiled binaries embeds absolute paths, yes,
so by using it you would make sure, for instance, that the
s6-fdholder-* utilities mentioned above can actually find the fdclose
and fdmove commands they rely on. But this does not say anything
about scripts you write - execlineb cannot tell whether you are
executing a binary provided by execline or any other binary.

 When you write 'execlineb -c "if { foo } blah"', the execlineb binary
will execute into an argv starting with "if". If the "if" command
isn't in its PATH, then it won't find it.
 --enable-absolute-paths cannot rewrite it into "/usr/lib/execline/if"
in your scripts for you.

--
 Laurent

Re: Question about enable-absolute-paths option

[Casper Ti. Vector]

On Sun, Sep 02, 2018 at 02:12:47PM +0800, Shengjing Zhu wrote:
> Thanks for this note, I haven't looked at these packages. At first I
> thought execline binaries will only be called inside execlinep
> scripts. Could you give some examples that s6 calls these binaries
> directly except exelinep?

My init/rc framework, slew [1], although base on s6/s6-rc, uses the
rc(1) shell as its main scripting language, and still often makes use of
the `emptyenv' command from execline.  Also, some complex `./run'
scripts like [2] can be readily rewritten in a shell [3], and these
translated versions will use more commands from execline.

[1] .
[2] 
.
[3] .

BTW, greetings from a compatriot :)

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Question about enable-absolute-paths option

[Laurent Bercot]

I intend to package skarnet softwares in Debian. When packaging
execline, I find it produces a lot of binaries with common names. Thus
I want to put them in path like /usr/lib/execline/.


 Do not do this.
 Several programs, including s6 and s6-rc, rely on execline binaries
to be in their PATH. They will not work if you segregate execline
binaries.
 If you insist on doing so, you'll have to make sure that
/usr/lib/execline is in everyone's PATH, so there will be no benefit
for you and more runtime overhead for everyone.

 There is no reason why execline binaries can't be first-class
citizens on your system. The existence of an "if" program does not
conflict with the "if" reserved word in the shell. Having lots of
files in /bin hasn't been an issue since the ext2 filesystem.
There was a command ("import") with a conflicting name, but it has
been removed.
 The presence of "lots of binaries with common names" is simply
not a problem.

--
 Laurent