Sorry I went off-list by accident there. I'm putting back the list in CC.

2017-08-08 22:37 GMT+02:00 Ray Andrews <rayandrews@eastlink.ca>:
>
> Right, the 'fg' stuff isn't native to echo.  I've asked this before, but
> how do I get a command to pick up any and all settings?   Is it simply a
> case of sourcing .zshrc?  That sounds simplest and best.  Mind, I find that
> when I create a command file it is usually because I want a clean slate, so
> .... Or I want it on the path and sourced scripts aren't searched for the
> same way, or are they?  Can it be done?
>

Sourcing ~/.zshrc seems like a big hammer for a small issue, a lot of
people have huge ~/.zshrc configurations.

If you want to simply add a small utility command to your own shell, write
it as a function in a separate file, and source that small file from your
~/.zshrc.

If you want to write a standalone command (e.g. that can be used by other
people which may have a different config) then as you say, it's better to
start with a blank slate, and load what you need. I bet most of the
contents of ~/.zshrc will be related to the prompt, auto-completion and
other interactive behaviour, so the amount of things that you have to load
manually will likely be small.

fg is simply an array containing the escape sequences for the various
colours, and is indeed not specific to echo. Since it is a variable (well,
an array) changing the PATH won't affect the presence or absence of fg.
When you write autoload colors && colors, it has a similar effect to
sourcing (not just running) a script which would populate the fg array and
a few others.

This probably doesn't matter, but is there some intuitive reason why $PATH
> would be imported but $fg not?
>

PATH is normally explicitly exported with:

export PATH

or

export PATH="/home/me/bin:$PATH"

which explicitly tells the shell to make that variable available to child
processes.

I don't know a way to export an array (hopefully someone more knowledgeable
here will chime in about that), only simple scalar variables. But relying
on too much things being present in the environment is usually a bad thing,
as it makes your script more fragile and less likely to work on different
configurations. relying on PATH, HOME and similar universal env vars is
okay, and so is the use of env vars as switches which alter the behaviour
of your script (they effectively become part of the "normal" way of calling
your script, if you document them properly), but relying on the environment
to contain utilities does not seem like a good idea to me.

Cheers,
Georges