search

zdharma-continuum / zinit

🌻 Flexible and fast ZSH plugin manager
MIT License
2.9k stars 125 forks source link

PATH items are added at the start #154

Open hoshsadiq opened 2 years ago

hoshsadiq commented 2 years ago

This was previously raised already, and so below is just a copy/paste from issueexplorer:

Is your feature request related to a problem? Please describe. When the PATH variable is updated by zinit, items are added at the beginning, which isn't ideal in many scenarios. For me for example, I've added a directory at the start of my PATH so that I can wrap overload some binaries to do custom stuff. Because of zinit I'm unable to do so.

Describe the solution you'd like Ideally we should be able to force zinit to always update PATH by adding the new directories at the end of the $PATH.

Describe alternatives you've considered I haven't. I don't see any other way.

vladdoster commented 2 years ago

Have a few clarifying questions..

Have you tried using the z-a-bin-gem-node annex?

If you haven't, I feel that it is for this exact situation.

If you have, could you elaborate on your usecase a bit more? I'm not grokking the crux of the issue.

Why can't you update the path and prepend after zinit starts? Or maybe use zinit-continuums/null and run it last via a wait ice?

hoshsadiq commented 2 years ago

I have not tried z-a-bin-gem-node, and although I can sympathise with having too many directories in my path because of zinit, I'm not entirely sure creating functions is good enough for me. Many of my binaries need to be accessible outside the shell through executed programs, which will not work with functions. Perhaps the shims will work, but again, seems unnecessary when all that needs to be done is ensure items are appended to the $PATH instead of prepended.

Why can't you update the path and prepend after zinit starts? Or maybe use zinit-continuums/null and run it last via a wait ice?

Updating the paths after zinit starts won't work because of the wait, but using null and the wait ice might work, I'll have to try it. The only issue I see with that is that it's unclear what the order of the wait is so I'm not sure.

I guess outside all of that, I still think the default should be to add the paths at the end as opposed to at the beginning. Would it be possible to make this an option?

vladdoster commented 2 years ago

Can you expand on your use case with a real || hypothetical example?

There is something similar already.

Go here and scroll up to the 2nd to the last item in the table.

hoshsadiq commented 2 years ago

fpath is not PATH. fpath is only used by zinit, not other applications.

For example, I'm using saml2aws, and some other tooling uses it too with a specific set of arguments, but I can't make changes to those arguments. I'd like to overload it and pass in custom additional arguments. This would allow those tools to run my script, which then runs the real saml2aws with the arguments my script would change.

seivan commented 2 years ago

fpath is not PATH. fpath is only used by zinit, not other applications.

Not sure that's true, but I could be wrong. That being said, I agree with you, zinit should not touch $PATH or allow opt out.

vladdoster commented 2 years ago

@hoshsadiq

The assertion fpath is exclusive to zinit is incorrect. It is used by Ksh and Zsh.

Zsh documentation regarding fpath

hoshsadiq commented 2 years ago

I guess I was talking in the context of zsh and running commands that run other commands that aren't shells. The issue is that when programs attempts to run a command or script, they usually only look in $PATH. To have it listen to fpath, you'd need to a) export fpath (which usually doesn't happen), and the programs would need to invoke the sub command (or script) using zsh or ksh.