Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: --init-file option

I meant keeping it in a codebase independent of Zsh's.

You are right, bash's --init-file does replace bashrc, so I have to source that too in my activation script. For my use case I just want to start a new shell that works the same to the user as when they start a vanilla shell, with the exception that the virtual environment activation file is sourced. The activation file sets/modifies a bunch of environment variables (e.g. PATH, PYTHONHOME and PS1) and changes the working directory. To me fish shell's --init-command is the most elegant approach, but I can also live with the same approach as what bash does – in which case I only would need to source .zshrc in my activation script and not meddle with ZDOTDIR (which might have unintended side-effects, like what Roman mentioned regarding the startup files seeing the modified ZDOTDIR instead of what the user potentially sets it to be).

On Mon, Feb 13, 2023 at 10:46 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
On Mon, Feb 13, 2023 at 12:59 PM Kalmár Gergely <kgregory89@xxxxxxxxx> wrote:
> Yes, I could do something similar as what zshi does, but that seems like a suboptimal solution, because it would require a duplication (and indefinite maintenance) of the startup file processing logic in an independent codebase.

I don't follow that at all.  You're keeping the file for --init-file
somewhere now (I presume), so why would pointing ZDOTDIR at it require
a new codebase?

Anyway "bash --init-file" replaces (both global and user) bashrc
rather than run the file after them, which doesn't match what you
originally asked for.  Does it  in fact do what you want?

Does your file need to create internal variables or functions, or is
it just populating the environment?

Messages sorted by: Reverse Date, Date, Thread, Author