Skip to content
This repository has been archived by the owner on Jul 4, 2023. It is now read-only.

zsh: make the disabling of /etc optional #11056

Closed
wants to merge 1 commit into from

Conversation

sorin-ionescu
Copy link
Contributor

@adamv
Copy link
Contributor

adamv commented Mar 19, 2012

Should this be on or off by default?

@sorin-ionescu
Copy link
Contributor Author

Right now, it's off by default. Personally, i'd rather have it on. Let's hear @indrajitr's opinion.

@indrajitr
Copy link
Contributor

I agree with @sorin-ionescu. etcdir should be on by default.

The patch (along with the great writeup on caveats) makes sense to me. This way, there would be least surprise to people upgrading from previous version. And they would be consistent with zsh manpages and all the docs that talk about /etc/zprofile, /etc/zshenv etc.

While having the default enabled has it's own effect, it is abundantly clear from the caveats section. This is something a zsh power user on Mac should take care of anyway (homebrewed or otherwise).

OT: @sorin-ionescu, your OMZ fork shaping up very well!

@indrajitr
Copy link
Contributor

Would be nice to have this in please.

@jacknagel
Copy link
Contributor

Pulled.

@jacknagel jacknagel closed this in fdd721f Apr 25, 2012
@indrajitr
Copy link
Contributor

Thanks!

@cdlm
Copy link
Contributor

cdlm commented May 4, 2012

Are the caveat instructions about renaming /etc/zshenv to /etc/zprofile correct ? I did that and with the zsh formula available now, I got /usr/bin etc in front of my custom $PATH entries.

@sorin-ionescu
Copy link
Contributor Author

@cdlm Yes, the instructions are right.

@cdlm
Copy link
Contributor

cdlm commented May 4, 2012

@sorin-ionescu What I don't get is that path_helper seems to prepend everything including the basic paths like /usr/bin, so if it runs from /etc/zprofile it takes precedence over custom paths set from ~/.zshenv… and I don't want to move my setup to ~/.zprofile, since I want my scripts to inherit it. Am I missing something?

@sorin-ionescu
Copy link
Contributor Author

If you move /etc/zshenv to /etc/zprofile, you avoid path_helper.

@cdlm
Copy link
Contributor

cdlm commented May 4, 2012

For me it still runs, but after my own .zshenv (right, maybe just in interactive shells, but that's still a pain).

I don't really care about the couple paths that it sets, so I recompiled zsh with /etc disabled, but I'd still like to understand what the proper setup is for user-specific paths that should take precedence on system ones.

@sorin-ionescu
Copy link
Contributor Author

It's best to avoid using /etc.

@jacknagel
Copy link
Contributor

Should we be setting etcdir to HOMEBREW_PREFIX/etc? Would that be useful and/or beneficial?

@sorin-ionescu
Copy link
Contributor Author

No, no other package messes with /etc, AFAIK.

rohansingh pushed a commit to rohansingh/homebrew that referenced this pull request May 7, 2012
Sharpie pushed a commit to Sharpie/homebrew that referenced this pull request Sep 12, 2012
snakeyroc3 pushed a commit to snakeyroc3/homebrew that referenced this pull request Dec 17, 2012
@eatnumber1
Copy link

What's the argument for moving /etc/zshenv to /etc/zprofile? As far as I'm aware, the only thing it does is make the paths produced by path_helper take precedence over changes to PATH made by ~/.zshenv, which is not desirable.

@samuelcole
Copy link

I just noticed the same thing, and I don't understand why you wouldn't want path_helper to run for scripts as well?

@dwlf
Copy link

dwlf commented Mar 25, 2013

I'm in the same boat as @samuelcole @eatnumber1 @cdlm.

@sorin-ionescu @indrajitr under what use case does one not want --disable-etcdir? Why is it not the default behavior? Default --disable-etcdir would seem to minimize hard to debug problems. The caveat is a distraction.

@sorin-ionescu
Copy link
Contributor Author

@lloydde You would not want to disable /etc if the configuration files in there are useful to you, such as setting the path.

@Homebrew Homebrew locked and limited conversation to collaborators Feb 16, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants