[sf-lug] ENVVAR1=set_it_to [...] command [args ...]; rc, ...

[Michael Paoli]

That goes way back to at least Bournce shell in
Unix 7th edition, 1979, and remains there in
POSIX and reasonably POSIX-like/Bourne-like shells.

 From ye olde sh(1) man page, Unix 7th edition, 1979:

The environment for any simple-command may be augmented by prefixing  
it with one or more assign-
ments to parameters. Thus these two lines are equivalent
TERM=450 cmd args
(export TERM; TERM=450; cmd args)

Whole lot 'o highly useful information crammed into that mere
6 pages of ye olde sh(1) manual pages - most of which is still
highly applicable today (and still which is most of what's used
and important in the shells).  When I do shell trainings/presentations,
I generally still start wit that mere 6 pages to begin with - not so
overwhelming - and a whole lot of good useful material packed in there
(and most of the important stuff).  I think bash(1) now weighs in at
something around or over 80 pages or so.  It probably documents that
behavior in there *somewhere*.
I'll leave that as an exercise for someone who wants to find and
point it out.
Pretty easy to find in much more reasonably sized dash(1):
            1.   Leading words of the form ``name=value'' are stripped off and
                 assigned to the environment of the simple command.

(Reminds me ... bash bloat ... and bugs ... I think I recently found yet
another bug in bash :-/ ... but maybe some other posting some other time,
I've got some other bashing of GNU bloat to "attack".)

I also mentioned that mechanism for setting environment
variable(s) for a specific command invocation in my earlier post:

> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> To: SF-LUG <sf-lug at linuxmafia.com>
> Subject: Re: dpkg -l & COLUMNS, & shell and environment ...
> Date: Wed, 02 Aug 2017 07:18:25 -0700

> And, actually, just to point it out, in bash/POSIX/bourne/etc. shells,
> if one does something like:
> $ FOO=whatever some_command
> That sets environment variable FOO to whatever for that invocation of
> some_command, and without otherwise changing the shell's
> environment.  One could, alternatively, use the env(1) command,
> but by not using the env(1) command we save the overhead of an
> entirely separate external command execution ... not to mention also
> saving some keystrokes.
> One can also set multiple environment variables at the same time:
> $ TERM=linux-m EXINIT='se ...' vi ...
> e.g. on a host where vi is vim (ugh), and I don't want no seenkin' colors.

and ... rc ...

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] NEED INFO ABOUT BOOT SECTOR, SPACE LIMITS
> Date: Wed, 2 Aug 2017 14:20:37 -0700

> Quoting Alex Kleider (akleider at sonic.net):
>
>> The problem I was trying to solve is that the long lines get carried
>> over to the next line so the ability to scan down columns is
>> disrupted by 'spilled' lines.  Your
>> COLUMNS=$COLUMNS dpkg -l | less
>> command fixes that...
>
> Glad it helped!  It's a tip I picked up somewhere that makes the rounds,
> so the problem appears to be common.
>
> As Michael P. points out, and as I did in one of the command-line strings
> we use at www.svlug.org to purge unneeded 'rc' (run-control, which is to
> say configuration) files from removed packages, the output of 'dpkg -l'
> can be usefully fed through filtering, awk, etc. to do useful package
> reporting and other operations.

Ah, context, context.  I could see where the confusion could easily arise.
rc, as in .bashrc, .initrc, etc. that old "rc" convention came from
"run command" (and I don't remember the origins of "run command" and
how that made it to the "rc" in those initialization files).

The "rc" seen in dpkg -l means something rather different, actually.

$ COLUMNS=80 dpkg -l | sed -ne '1,5p;6,${/^rc /{p;q;}}'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
rc  libgd2-xpm:amd 2.0.36~rc1~d amd64        GD Graphics Library version 2
$

In the rc above, the r indicates the desired state: Remove - we want the
package to be removed.
And the c indicates status - Conf-files - configuration file(s) still
present.
So, it shows we want it removed but still have configuration files present.
This is generally what happens if a remove is done without the --purge or
equivalent option, or we don't do a purge operation.  By default the
configuration files are left behind.