Re: Code for :"Re: HERE document failed && Re: /dev/fd/62: No such file or directory"

[Linda Walsh]

Greg Wooledge wrote:
> On Fri, Jul 25, 2014 at 04:44:27PM -0700, Linda Walsh wrote:
> > FWIW, this script DOES work interactively in normal operation.
> >
> > Just when the system is in pre-single-user state and not
> > much in the way of resources is available that it blows.
>
> Then you are attempting to use operating system features that haven't
> been initialized yet.  Stop doing that.
----
        Except that in-line HERE docs don't need to be implemented
through a tmp file unless you want to slow things down.
        They should be read out of memory and NOT transfered to
to non-existent, external storage.

        Maybe POSIX says differently, but I doubt it differentiates
when you are allowed to use features based on when you run the shell.


> Here documents create temporary files, possibly in /tmp, or possibly in
> whatever directory $TMPDIR points to.  So, /tmp (or /var/tmp or whatever)
> must be mounted and writable.
----
Is that part of a standard somewhere?   The point is to similate
an input stream.  Wouldn't it be more portable to do that from memory?


> Process substitutions **ON LINUX** use /dev/fd/* entries, which are
> in a special file system that must be mounted.  Process substitutions
> on other operating systems may use that, or named pipes, or even
> temporary files.
----
        I'll allow those as they are too new to really be relying on,
but HERE docs are basic, and shouldn't need external run-time support for
the type of stuff I'm doing.


> In any case, the problem is clearly that your script is trying to use
> features that aren't available yet, at that point in the boot process.
---
        Like reading another process's output so I can alter
variables that are in the main thread.

        The other methods for reading in data reverse the reader/writer
and put the reader into a child such that it can't modify variables
in the running script.


> Rewrite the script to avoid using those features, or run it at a
> different point in the boot process.
----
        I have rewritten it to avoid the process substitutions and fell
back to HERE docs for that.  There is no standard or documentation about
what parts of a POSIX shell are not available at boot time or how to
work around the deficiencies.

Also it isn't easy to run things elsewhere in the boot script, as I'll
likely have to run systemd at soem point and it will just take over and
I'll have no control of when things run, so I'm doing some early initialization
so I can then turn over the control thread to something else.

For example, I also have to mount "/usr" and "/usr/share" before
I can "boot", or systemd won't be happy.



> Too large.  Trim it down to the smallest possible case that still
> exhibits the problem.  But even then, I'm sure you already know what
> the problem is.
----
        That's not easy, since by definition, it only works when there
is no environment to support trimming it.
> (P.S. I despise that "let me figure out the order for you" crap that
> Debian has started doing.  What a disaster.  How in the hell is a
> sysadmin supposed to add a boot script now, and make sure it runs at
> the right point....)
----
You aren't supposed to be adding boot scripts...

Wait till they get the walled garden up around PC's w/secure boot
and only allowing signed apps.

GRRRR.