kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Wed, Sep 03, 2014 at 03:36:24PM -0500, Moses McKnight wrote:
> this.  AFAIK env vars set that way are only valid for that process (and
> maybe the instance of the shell it was called from?).

OK, POSIX env vars 101 (AFAIK these rules are good for windows too; in
DOS you could change your parent env, too BTW)

- One gets a *copy* of the env from the parent process (i.e. all your
  children take a snapshot of your environment at fork time);
- You can change *your* variables at your leisure;
- You can't change variables in other processes, neither parent nor
  children.

In short you set them for your use (setenv) and before forking, after
that you have no more control. Please note that env variables live at
a *process* level (which is important for the kiway modules).

>From the shell a variable becomes environment only when export-ed;
otherwise it's just a shell variable (common error for beginners)

> I'm particularly thinking of the variables used in the fp-lib-table.  The
> user may want to create multiple new ones for footprint libraries in
> different places.  And the main goal is better usability.

I don't think the original plan was for that, but that could be done,
yes. The main reason AFAIK is for relocability when moving to another
computer.

> I don't think those articles were against *all* env vars either, although
> the first one doesn't make that real clear.  They are basically arguing
> against using environment variables for application settings.

Good luck doing compiles without CFLAGS/CXXFLAGS and friends, then :D

Please note that Debian policy only forbid *mandatory* env vars; if you
can compute a good default value (like python does) when the variable is
unset then there is no problem with that. Xilinx ISE would never pass
Debian guidelines: it lives off environment variables :D

-- 
Lorenzo Marcantonio
Logos Srl