* some color fails in command. @ 2017-08-08 19:39 Ray Andrews 2017-08-08 20:16 ` Peter Stephenson 2017-08-08 20:51 ` Dupéron Georges 0 siblings, 2 replies; 6+ messages in thread From: Ray Andrews @ 2017-08-08 19:39 UTC (permalink / raw) To: Zsh Users 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? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: some color fails in command. 2017-08-08 19:39 some color fails in command Ray Andrews @ 2017-08-08 20:16 ` Peter Stephenson 2017-08-08 20:51 ` Dupéron Georges 1 sibling, 0 replies; 6+ messages in thread From: Peter Stephenson @ 2017-08-08 20:16 UTC (permalink / raw) To: Zsh Users 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: some color fails in command. 2017-08-08 19:39 some color fails in command Ray Andrews 2017-08-08 20:16 ` Peter Stephenson @ 2017-08-08 20:51 ` Dupéron Georges 2017-08-09 3:09 ` Ray Andrews 1 sibling, 1 reply; 6+ messages in thread From: Dupéron Georges @ 2017-08-08 20:51 UTC (permalink / raw) To: Ray Andrews; +Cc: Zsh Users [-- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: some color fails in command. 2017-08-08 20:51 ` Dupéron Georges @ 2017-08-09 3:09 ` Ray Andrews 2017-08-09 3:58 ` Bart Schaefer 0 siblings, 1 reply; 6+ messages in thread From: Ray Andrews @ 2017-08-09 3:09 UTC (permalink / raw) To: Dupéron Georges, Zsh Users [-- 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: some color fails in command. 2017-08-09 3:09 ` Ray Andrews @ 2017-08-09 3:58 ` Bart Schaefer 2017-08-09 14:09 ` Ray Andrews 0 siblings, 1 reply; 6+ messages in thread From: Bart Schaefer @ 2017-08-09 3:58 UTC (permalink / raw) To: Ray Andrews; +Cc: Dupéron Georges, Zsh Users 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: some color fails in command. 2017-08-09 3:58 ` Bart Schaefer @ 2017-08-09 14:09 ` Ray Andrews 0 siblings, 0 replies; 6+ messages in thread From: Ray Andrews @ 2017-08-09 14:09 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-08-09 14:39 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-08-08 19:39 some color fails in command Ray Andrews 2017-08-08 20:16 ` Peter Stephenson 2017-08-08 20:51 ` Dupéron Georges 2017-08-09 3:09 ` Ray Andrews 2017-08-09 3:58 ` Bart Schaefer 2017-08-09 14:09 ` Ray Andrews
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).