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

Unknown command 'string' after updating fish in CentOS 7 from yum #3057

Closed
HongPong opened this Issue May 23, 2016 · 9 comments

Comments

Projects
None yet
5 participants
@HongPong

HongPong commented May 23, 2016

Updating fish shell package on CentOS 7 kicked off a ton of errors with "Unknown command 'string'".

Reproduction Steps:

  1. yum update
  2. install package fish-2.3.0-2.1.x86_64.rpm from repo shells_fish_release_2
  3. Errors spewed.

Expected behavior:

Did not expect lots of errors, just a regular update

Observed behavior:

71 errors generally like:
fish: Unknown command 'string'
/usr/share/fish/functions/prompt_pwd.fish (line 1): string replace -r '^'"$realhome"'($|/)' '~$1' $PWD

It seems to be affecting most shell commands now, generating the same type of errors.

Additional information:

The gist log is here:
https://gist.github.com/HongPong/338bc98dc5a97dc827c3b9ad349f6231
Sorry if this should be filed in some packaging-related repo, but did seem severe enough to have something entered in the main fish issues.


Fish version: [from the output of fish --version]
This version info request kicks off similar errors. Is version 2.3.0 .

Operating system: Centos 7 with Yum

Terminal or terminal emulator: iTerm2 over ssh.


Tasks for 2.3.1:

  • Release notes updated
@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho May 23, 2016

Member

string was added in 2.3.0, so it seems like your old (2.2.0) running fish sessions are picking up newer functions that make use of it. Just close those and start new sessions and all should be fine.

I'm not sure there's anything we can do here.

Member

faho commented May 23, 2016

string was added in 2.3.0, so it seems like your old (2.2.0) running fish sessions are picking up newer functions that make use of it. Just close those and start new sessions and all should be fine.

I'm not sure there's anything we can do here.

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 May 23, 2016

Contributor

What @faho said although you should be able to just exec fish to replace the current fish 2.2.0 process with a 2.3.0 process that's compatible with the new scripts. The only way to keep this from happening is to add a version number to the various directories that contain fish files and that solution is worse than the problem it's solving.

Contributor

krader1961 commented May 23, 2016

What @faho said although you should be able to just exec fish to replace the current fish 2.2.0 process with a 2.3.0 process that's compatible with the new scripts. The only way to keep this from happening is to add a version number to the various directories that contain fish files and that solution is worse than the problem it's solving.

@HongPong

This comment has been minimized.

Show comment
Hide comment
@HongPong

HongPong May 23, 2016

Fantastic, thank you. Might be good to put some kind of warning on the next package version about this. Best regards!

HongPong commented May 23, 2016

Fantastic, thank you. Might be good to put some kind of warning on the next package version about this. Best regards!

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Jun 15, 2016

Contributor

There have been several issues opened about this problem. I'm going to reopen this to track a fix for inclusion in the 2.3.1 release. See issue #3141 and PR #3142 for some ideas. See also the discussion starting at this Gitter.im link.

We should also think about how to solve this in a more generic fashion but that should happen in a separate issue. At a minimum we need to add something to the 2.3.1 release branch to make it obvious to users they need to replace instances of their pre-2.3.x shell with a 2.3.x shell.

Contributor

krader1961 commented Jun 15, 2016

There have been several issues opened about this problem. I'm going to reopen this to track a fix for inclusion in the 2.3.1 release. See issue #3141 and PR #3142 for some ideas. See also the discussion starting at this Gitter.im link.

We should also think about how to solve this in a more generic fashion but that should happen in a separate issue. At a minimum we need to add something to the 2.3.1 release branch to make it obvious to users they need to replace instances of their pre-2.3.x shell with a 2.3.x shell.

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Jun 15, 2016

Contributor

Assigning to you, @floam, since you've already created a proof of concept fix.

Contributor

krader1961 commented Jun 15, 2016

Assigning to you, @floam, since you've already created a proof of concept fix.

floam added a commit to floam/fish-shell that referenced this issue Jun 26, 2016

Work around absent `string' in old fishies upgrading.
Improves experience during upgrades, accidentally running
an old fish with a new environment. No errors just from
printing a prompt. Fixes #3057.

Print helpful notice also when launching mismatched fish.

Autoloadable string.fish -- only create function if not builtin.

floam added a commit to floam/fish-shell that referenced this issue Jun 26, 2016

Work around absent `string' in old fishies upgrading.
Improves experience during upgrades, accidentally running
an old fish with a new environment. No errors just from
printing a prompt. Fixes #3057.

Print helpful notice also when launching mismatched fish.

Autoloadable string.fish -- only create function if not builtin.
@zanchey

This comment has been minimized.

Show comment
Hide comment
@zanchey

zanchey Jul 1, 2016

Member

@floam, is this in a state to merge into Integration_2.3.1 and are you happy to do so?

Member

zanchey commented Jul 1, 2016

@floam, is this in a state to merge into Integration_2.3.1 and are you happy to do so?

@floam

This comment has been minimized.

Show comment
Hide comment
@floam

floam Jul 1, 2016

Member

Already did.

Member

floam commented Jul 1, 2016

Already did.

@zanchey

This comment has been minimized.

Show comment
Hide comment
@zanchey

zanchey Jul 1, 2016

Member

D'oh! I needed to scroll up! Can this be closed?

Member

zanchey commented Jul 1, 2016

D'oh! I needed to scroll up! Can this be closed?

@floam floam closed this Jul 1, 2016

@floam

This comment has been minimized.

Show comment
Hide comment
@floam

floam Jul 1, 2016

Member

Yeah. I figured it had already but since that wasn't master, it must be done manually.

Member

floam commented Jul 1, 2016

Yeah. I figured it had already but since that wasn't master, it must be done manually.

zanchey added a commit that referenced this issue Jul 3, 2016

Merge branch 'Integration_2.3.1'
Includes the `string` fallbacks for upgrades from 2.3.1 (as discussed in
issue #3057).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment