some color fails in command.

some color fails in command.

[Ray Andrews]

Gentlemen:

     echo -e "$fg[red]foo"
     echo -e "\e[36;1mbar\e[0m"

Sourced, both work, but if I make the script executable the top one 
fails (stays B&W) but the second line continues to work as expected.  
How should I understand that?

Re: some color fails in command.

[Peter Stephenson]

On Tue, 08 Aug 2017 12:39:40 -0700
Ray Andrews <rayandrews@eastlink.ca> wrote:
> Gentlemen:
> 
>      echo -e "$fg[red]foo"
>      echo -e "\e[36;1mbar\e[0m"
> 
> Sourced, both work, but if I make the script executable the top one 
> fails (stays B&W) but the second line continues to work as expected.  
> How should I understand that?

The executable file does not pick up whichever start-up file it is in
which you are doing something like

autoload colors
colors

so $fg is not defined.  I'm guessing it's .zshrc.  If you move this to
.zshenv it should work (unless you are explicitly suppressing that with
the -f option).

The second set, being raw escape sequences, are always interpreted by
the terminal.

pws

Re: some color fails in command.

[Dupéron Georges]

[-- Attachment #1: Type: text/plain, Size: 2579 bytes --]

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

Re: some color fails in command.

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

On 08/08/17 01:51 PM, Dupéron Georges wrote:
>
> 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.

Too bad there wasn't a PATH for runable scripts that aren't functions 
and don't need to involve a fresh shell.    The miser in me dislikes 
.zshrc loading of stuff that's not often used so I don't bother creating 
functions, still it would be nice to have quick access to the thing w.o. 
having to change to the directory or give a full path.  Probably 
autoload would be the right compromise.

Thanks Georges, very fine and detailed answers.

Re: some color fails in command.

[Bart Schaefer]

On Tue, Aug 8, 2017 at 8:09 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Too bad there wasn't a PATH for runable scripts that aren't functions and
> don't need to involve a fresh shell.

That's why the PATH_DIRS option exists and the "." command is a single
character.

Re: some color fails in command.

[Ray Andrews]

On 08/08/17 08:58 PM, Bart Schaefer wrote:
> On Tue, Aug 8, 2017 at 8:09 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>> Too bad there wasn't a PATH for runable scripts that aren't functions and
>> don't need to involve a fresh shell.
> That's why the PATH_DIRS option exists and the "." command is a single
> character.
>
Bloody marvellous, couldn't ask for better.   Ah, for that 50 page 
essay:  "100 very cool things that zsh can do that you've never even 
heard of because no one bothered to tell you".   That just about 
completes the list of possible ways and methods to create/execute/find a 
command, nothing left to desire.