Re: s6 usability
On Sun, 22 Dec 2019 23:20:03 + "Laurent Bercot" wrote: > >That being said, is having your stuff on the executable path such an > >advantage? > > I don't know, why does Unix like to have its binaries in /bin? Why > does PATH exist? What is the nature of an executable? You have two > hours. > > > >December 2019 featured book: Rapid Learning for the 21st Century > > Ah, so that's your secret. Rapid learning and rapid forgetting. You can sling all the insults you want, but the fact is, putting all your stuff for a single software group into one tree, outside of the path, and accessing it with a prepath script that perhaps does a cd and sets other environment variables that you'll need makes a tidy little package, with no name conflicts. You can "uninstall" it with a simple tree delete. Depending on dependencies and architecture and the way your software's written, you might be able to copy it to another computer with cp -Rp or rsync -va. It's very easy to examine. The UNIX way, with /usr/bin and /usr/local/bin and the rest, is just fine with me, as long as the distro cooperates. But if the distro fails to carry out the intent of your software, there are worse things than putting it all in one directory or tree, prepathing their location, and running it that way. SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: s6 usability
On Sun, 22 Dec 2019 23:20:03 + "Laurent Bercot" wrote: > I don't know, why does Unix like to have its binaries in /bin? Why > does PATH exist? What is the nature of an executable? You have two > hours. Sorry, this discussion is crazy: Laurent provides a basic booting tools with his toolchain. A booting tools should be in /bin - full stop! However - what is the concrete suggestion from the Debian guys what Laurent should do? On top, it makes sense to start a community integration program to fullfill distro requirements. So that would include public test and build infrastructure and pre-packaging stuff. I can support that with free hosting for building and testing, i.e. I can provide a public gitlab with build and test pipelines. Best Regards Oli -- Automatic-Server AG • Oliver Schad Geschäftsführer Turnerstrasse 2 9000 St. Gallen | Schweiz www.automatic-server.com | oliver.sc...@automatic-server.com Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47 pgprAyE0rdVxz.pgp Description: OpenPGP digital signature
Re: s6 usability
On the question of PATH for BSD land (FreeBSD, TrueOS, HardenedBSD et al), binaries installed from packages (ports) live under /usr/local, with the exception of /var and /tmp. The wars were fought and /usr/local can easily be mounted read-only. Of the 1446 packages I have installed (no desktop stuff), the breakdown is # ls /usr/local/bin/ | wc -l 2857 # ls /usr/local/sbin/ | wc -l 349 # find /usr/local/bin/ -type d -depth 1 /usr/local/bin/db5; # No directories under /usr/local/sbin # ls /usr/local/libexec|wc -l 72 The placement of files, is more a "distribution" decision that I'm sure is already settled. On the documentation front, Laurent's work is very good, but I did find the examples from the gentoo docset for s6 & s6-rc, a life saver for someone with no prior process or service management background. (I'd only used monit previously, and still do to reload application configs and some other system state change events over s6 tools).
Re: s6 usability
That being said, is having your stuff on the executable path such an advantage? I don't know, why does Unix like to have its binaries in /bin? Why does PATH exist? What is the nature of an executable? You have two hours. December 2019 featured book: Rapid Learning for the 21st Century Ah, so that's your secret. Rapid learning and rapid forgetting. -- Laurent
Re: s6 usability
On Sat, 21 Dec 2019 23:46:34 + "Laurent Bercot" wrote: > No, you're falling for the pretext - because this is only the current > pretext they're using. Debian *does not provide* a POSIX-compliant cd > binary, so their claims at POSIX compliance are just lies. > The current version of execline includes POSIX-compliant cd and wait > binaries, and the next one will also include a POSIX-compliant umask > binary. Then we shall see what new excuse they find not to put > execline binaries in the default PATH. My finding in the past is that Debian will do harm to any software just so they can comply with their arcane rules. One such rule caused them to change the prepend key-sequence in VimOutliner from the incredibly quick and easy double comma (,,) to the wrist-twisting, error prone, slow, and keyboard dependent double backslash (\\), even though VimOutliner's manifesto listed authoring speed as the top priority. That being said, is having your stuff on the executable path such an advantage? A lot of times I put all the executables for a system in a directory off the path, and then create a shellscript like this: #!/bin/sh export PATH=/path/to/s6:$PATH $@ Or this: #!/bin/execlineb -s1 importas OLDPATH PATH export PATH "/path/to/s6:$OLDPATH" $1 $@ Symlink the shellscript from a directory on the path, and whatever is in $@ is as good as being on the path. By doing this I avoid any program name conflicts, I can easily delete my whole program or copy it to another computer. And of course slashpackage is another way. I'm not saying this is perfect. I'm just saying it could be as simple a opening a tarball in an arbitrary directory and typing make; make install. That's basically how we distributed VimOutliner for a long time. Earlier in this thread somebody suggested a method of Debian packaging that was both breathtaking in its convolution and preventing of other software from being installed at the same time. With Debian's propensity to break things doing them their way, perhaps it's time to consider the possibility of doing an end run around the Debian Developers. SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: s6 usability
On Sun, Dec 22, 2019 at 02:05:14AM +0100, Jan Braun wrote:
> > It doesn't help that neither Adam nor Jakub read the documentation for
> > the execline equivalents for cd, umask, or wait.
>
> Why would you say that? They effectively only claim that execline's
> cd/umask/wait binaries don't conform to the POSIX specification for
> cd/umask/wait. And I think that's uncontroversally true.
>
> > That or they don't know what 'execs into' means.
>
> POSIX requires:
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_06
> | However, all of the standard utilities, including the regular built-ins
> | in the table, [...] shall be implemented in a manner so that they can be
> | accessed via the exec family of functions as defined in the System
> | Interfaces volume of POSIX.1-2008 and can be invoked directly by those
> | standard utilities that require it (env, find, nice, nohup, time,
> | xargs).
>
> i.e, if you call
> execvp("cd", "cd", /* any other args, */ NULL);
> , POSIX says you MUST get the behaviour documented at
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cd.html
> . And if /bin/cd is execline's cd, then you don't.
>
Fair enough. Pedantic as it was I had mostly taken issue with the
statement that:
Regular "cd" changes the directory for the calling process (thus it
even can't possibly be a separate process), this "cd" takes two
arguments and runs a _child_ with the changed directory.
Which is a false statement unless you consider a program execve'd into
another to be "running a child".
>
> There's also the imho sensible rationale of e.g.
> | find . -type d -exec cd {} \; -exec foo {} \;
> | (which invokes "foo" on accessible directories)
> for that requirement, even if these are admittedly rare cases.
>
Not sure if this is a legitimate counter but:
find . -type d -exec cd "{}" pwd \;
does what is expected with execline's binary. In fact, I'm not sure if
your hypothetical is valid since I believe each exec is given its own
execution context and cd is not allowed to modify the callers
environment. Of course, I don't think there are any true stand-alone cd
utilities that we can test this with. If you know of one please tell me.
Similarly:
$ nohup /command/cd / pwd ; cat nohup.out
nohup: ignoring input and appending output to 'nohup.out'
/
On third thought, you're specifically talking about the case where you
fail to give a follow-on program to cd. As of v2.5.3.0, the configure
script in execline has grown the --enable-pedantic-posix option which,
when given, will generate a cd that knows how to handle the NULL case.
>
> > [placing binaries]
> > Have you ever considered slashpackage ;)
> >
> > In all seriousness though this, with the exception of dropping the s6-
> > prefix (and the prefix-appender binary I guess), is what slashpackage
> > does. /bin stays uncluttered, commands end up in a PATH-able place, and
> > if you want to surprise any systemic shell scripts you have you can
> > symlink in replacements to the default PATH.
>
> Yes, I'm aware of that. Unfortunately, I'm not aware of a unix distro
> usable for my general needs implementing /package as their packaging
> scheme.
> Nix/NixOS does something similar, and is on the short list of distros
> I'll consider if Debian goes ahead with the systemd madness.
>
> And FWIW, if I were to create my own distro/OS, I'd do away with $PATH
> entirely and have people union-mount stuff into /bin .
>
And yet NixOS is also primarily a systemd based distro, unless we have
different definitions of "systemd madness."
>
>
> > > P.S: I stumbled over this execline oddity:
> > > | dollarat -0 -d a # separates by \0
> > > | forbacktickx -0 -d a var {gen...} loop... # splits on a
> > > IMHO, both should be an error, but at least treat them the same.
> > >
> > As per the docs for forbacktickx:
> > -0 : accept null characters from gen's output, using them as delimiters.
> > If this option and a -d option are used simultaneously, the rightmost
> > one wins.
>
> Yes, and as per the docs for dollarat:
> -0 : use the null character as separator. Any -d argument will be
> ignored.
>
> They're both working as advertised. But they have *different* rules for
> resolving the case where both -0 and -d are given.
> I think that's a lack of UI consistency, and would consider it a bug in
> my software.
> (And, as I said, I think the best response to getting both -0 and -d
> would be erroring out, but that's just an aside.)
>
Fair enough. For some reason I was thinking you were talking about a
documentation error, not a functional inconsistency. I was assuming that
this leaked in when forbacktickx became a wrapper but that isn't the
case, the inconsistency exists as far back as the 2.0.0.0 rewrite.
--
Colin Booth
