-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Fish 2.6.0 broke setenv? #4103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Can you show us the output of It was broken briefly (about 3 weeks) by the fix for issue #3897. The fix for that regression can be found in issue #3937 and is definitely in fish 2.6.0. Are you sure you're running 2.6.0? What does |
I'm seeing this as well, with fish 2.6.0 and rbenv 1.1.0. The output of setenv PATH '/Users/mistydemeo/.rbenv/shims' $PATH
setenv RBENV_SHELL fish
source '/usr/local/Cellar/rbenv/1.1.0/libexec/../completions/rbenv.fish'
command rbenv rehash 2>/dev/null
function rbenv
set command $argv[1]
set -e argv[1]
switch "$command"
case rehash shell
source (rbenv "sh-$command" $argv|psub)
case '*'
command rbenv "$command" $argv
end
end I'm guessing the first line is the culprit. |
It looks like this was fixed upstream in rbenv: rbenv/rbenv@be2e606 and rbenv/rbenv@a81da8d I appreciate that rbenv was probably using |
Then
It's possible that the old fish implementation of |
It was, yeah. I think it's true rbenv shouldn't have relied on it, though the function's documentation explicitly described it as a
|
Sorry, but it is completely irrelevant that our docs said it was "a set -gx wrapper". That is both an implementation detail and a hint that you should use the fish native |
Can the change at least be documented? Right now the documentation only says this:
It doesn't mention that |
Well, strictly speaking the CHANGELOG only documents what was changed and the current statement is correct. We don't actually document the Having said all that I'll go ahead and augment the CHANGELOG entry for the |
I think it should be in the release notes - @krader1961 if you don't have time to write something up I can. |
Well... but it was documented. It just isn't any more.
Yes, but if a function behavior is documented, you can expect others to use it in that way.
You mean apart from users that read the issue tracker and/or changelog? If it was documented I obviously wouldn't have looked into this and opened a ticket. |
Excuse me? Please point me to where this was ever documented, @x4121. There is exactly one mention of it in the tutorial. It is incidentally included in the list of function names you might see if you type @zanchey, I added commit b361c29fe to the master branch to add more verbiage to the CHANGELOG about this. |
The description included "Alias for set -g"
setenv over set -gx as it conveys the intention (setting an environment variable) more clearly.
The csh implementation of setenv uses a single value, but it also uses colons to separate items. Since fish separates by spaces in general, it would have made sense for a fish-implementation of setenv to allow multiple values (instead of colon separated items). |
For the benefit of everyone else, @x4121 is referring to this description that used to be attached to the It's also a bit of a stretch to call a function description "documentation". Especially since the only way to see it means you are also looking at the, trivial, implementation and can clearly see that if you are supporting fish, rather than csh, you should simply use |
It also included "made for csh compatibility" - something which it now adheres to, and it previously didn't (in particular it didn't accept the colon-separated version for $PATH).
Obviously, that actually happened.
I disagree that it does, but that doesn't really matter. So, this was unfortunate - it's annoying that we didn't catch this prior to release, in which case I'd have argued that we should at most have issued a warning. However, it's happened now so the question is: How do we deal with this?
And since I think that should still be discussed, I'm reopening this. |
@krader1961 Well yes, I would call the description "documentation". I guess that's the purpose of having this description. But apart from that I guess it's useless to argue about this topic anymore due to vastly different viewpoints. @faho The change is already implemented in rbenv's master. In the meantime it's easily fixed with a workaround. I don't think it would be good to change setenv back from it's intended behavior (unless there a lot of other programs popping out with this issue). |
This is the only option I support. The only changes to our |
Yeah, but there's the problem of getting that to users. Now, a user can install fish and rbenv, and they'll get an error. Then they'll google and maybe they'll find this thread and figure out they need to install rbenv from git instead. That's not great. And as I've stated above, it's unlikely to change soon from the rbenv side.
On its own, it might not. But together with #4104 and some other issues, maybe it will. I'm not saying this is emergency-release material, just that it's something to keep in mind. If we have a couple more issues of this magnitude in the next month, I'd argue for a 2.6.1.
Yes, it's correct in that it behaves like csh. But it could be a bit more lenient in accepting things that it did previously. Okay, since the consensus seems to be to leave it alone for now, I'm closing this again. |
So question, as I read through this but couldn't discern what I need to do to fix this problem. I'm on a Mac, recently upgraded Fish via HomeBrew and now I'm getting this error. Is the easiest thing to do to simply remove the latest Fish and reinstall the previous version? Would I be better off attempting to remove rbenv and install that from Github? It was also installed via Homebrew. Thanks! |
@blimey85: Either install the fixed
|
@krader1961: that did the trick. Thank you! Unfortunately, I had nuked my install so have lost my configuration but I'll get that set back up tomorrow. Supposedly everything on my system is backed up so time to test that theory. Haha. Thanks again! |
This affected pyenv as well, and @krader1961's work around fixes it. Thank you. |
When 2.6.0 was released some people reported that the third-party `rbenv` and `pyenv` commands were incorrectly depending on our `setenv` function not behaving exactly like the csh command of the same name. Specifically, our version had a bug. It allowed more than one value. It no longer does so after it was rewritten so that the three auto-split vars were correctly handled. See issue #4103
Just to add my 2 cents here: I was tearing my hair over this issue for quite some time, and at least a temporary (but apparently robust) fix which seems to work is literally making a custom init script to replace config.fish:
functions/rbenv_init_patched.fish (literally just execute
This works now quite nicely for me so far, and requires no real modifications to the fish source code. If you guys notice any flaws with this method I'm eager to hear them, and sorry in advance if this is the wrong place to post this fix! |
@chilledfrogs If you're able to, a simpler way to skirt the issue is to install the --HEAD versions of For me, fixing the issue for my own use case was as simple as |
@lewisinc I see, stupid question incoming though: why |
@chilledfrogs not stupid question at all. The solution above is a fix someone else suggested that worked for me. |
@lewisinc Ok, thanks a lot, seems to work :) |
And if installed with git:
|
Since 2.6.0 release rbenv stopped working and echos
setenv: Too many arguments
during init. This is caused from the first line in the init scriptsetenv PATH '/home/adg/.rbenv/shims' $PATH
and setenv not working with multiple values anymore. Is this intended behavior? The release notes state that setenv was changed, but this doesn't seem to be correct 😕fish 2.6.0
Ubuntu 17.04
Tested on clean Ubuntu docker container with just fish and rbenv installed.
config.fish
just containingstatus --is-interactive; and . (rbenv init -|psub)
The text was updated successfully, but these errors were encountered: