Re: "here strings" and tmpfiles

[Greg Wooledge]

On Sun, Apr 07, 2019 at 01:06:21PM -0700, L A Walsh wrote:
> On 3/20/2019 5:19 AM, Greg Wooledge wrote:
> > Just like that one time L. Walsh tried to write a bash boot script that
> > used <() to populate an array, and it failed because she was running
> > it too early in the boot sequence, and /dev/fd/ wasn't available yet.

>     /dev/fd was available, and so was /proc that it symlinked to.
> What wasn't available was "/tmp" being mounted as a writeable
> file system. I.e. -- exactly the case we are talking about being
> a problem *AGAIN*.

Sorry, I didn't remember it correctly.

The original thread appears to be here:
https://lists.gnu.org/archive/html/bug-bash/2014-10/msg00056.html

And you started a second thread here:
https://lists.gnu.org/archive/html/bug-bash/2014-10/msg00064.html

>     Various boot processes use /dev and /proc before any file systems
> are mounted.  Requiring a mounted, writeable file system to run a shell
> script during boot was the reason I had problems.

As I said back then, and as I said more recently, if you're writing a
boot script (which is a fundamental piece of an operating system), you
really need to know what you're doing.  That includes knowing which
shell syntax features rely on which operating system features, and which
operating system features are (un)available at which times during the
boot sequence.

Either move your script so that it runs after /tmp becomes writable,
or use $TMPDIR to tell it to use a different place that IS writable for
its temp files, or write it to not use temp files.

> > 2) Don't use bash for scripts that run early in the boot sequence.
> ---
>     unacceptable as bash is used as *THE* defacto linux shell.

That's incorrect in this context.  We're talking about boot scripts here,
not interactive user shells.  In boot scripts, on every operating system
I've ever used, the shell being used is either POSIX sh or Bourne sh.

Everyone who writes boot scripts knows this.  Except, apparently, you.

> > 3) Whatever features you *do* use in boot scripts, make sure they're
> >    available at the point in the boot sequence when the script runs.
> ----
>     Pipes are available in the OS before any user scripts are run.

We keep talking past each other and I don't know how to fix that.

You're advocating a fundamental change in a shell that is not even being
used in boot scripts (other than, apparently, by YOU).  The changes you
propose would potentially break many shell scripts that other people use,
just to make it possible for you (and nobody else) to do something unique.

I am advocating that you use the tools you already have, which are the
same tools that everyone else has been using for the same job you're
doing, for the last several decades.

> > 4) Whatever features you use in scripts *in general*, make sure you
> >    understand how they work.
> ----
>     No... Do you understand how your TV works to watch it?   Or
> your microwave, in order to heat food.

For the microwave: I know that it has to be plugged in.  I know that
the circuit breakers have to be not-tripped.  I know that it emits
heat and possibly radiation and therefore I should not stack a bunch of
flammable things on top of it, or block the ventilation, or sit on it,
or do anything else that would expose myself to said radiation.

I know that it has a specific wattage (1200 W), which may be higher
or lower than the wattage specified on the box that the food came in
(typically higher), and therefore I may have to adjust the cooking time
(typically downward).  I know how to set the cooking intensity to less
than 100%.  I know that with my particular microwave, this setting means
the radiation is toggled on and off intermittently, not actually reduced.

For the television: I know that it has to be plugged in, and the circuit
breakers not-tripped.  I know that it has multiple inputs which are fed
by cables of various kinds.  I know which kinds of cables go in which
holes, and what devices those cables are attached to, and how to operate
those devices.  I know how to use the remote control, or the OTHER remote
control in an emergency, to switch among the various input sources.
I know how to change the batteries in the remote(s), and how to program
the secondary (universal) remote to talk to this particular television.

And so on, and so on.

I have the knowledge that is appropriate to what I am doing.

You're conflating PROGRAMMING and BEING A USER.  Each role has specific
knowledge requirements.  Those requirements are different.

> This attitude is why so
> many people have resisted using computers -- because programmers who
> made "friendly user interfaces", were outnumbered in the 1990's by
> those who got liberal arts degrees [...]

You are writing BOOT SCRIPTS.  These are low-level pieces of
infrastructure.  You are acting in the role of a SYSTEM PROGRAMMER.

That role is entirely different from end user.

Comparing your struggles to write boot scripts with anyone else's struggle
to understand the user interface of an application is meaningless.