"set_color: Expected an argument" appearing each time Fish loads

[VioletHynes]

Hi, I've used Fish on my system since I installed it, but for some reason I keep getting an error message when Fish loads (via tty or from a terminal emulator within X).

"set_color: Expected an argument"
Appears, and the colours are different from what they used to be - e.g. the completions are white, rather than green, now.

I haven't changed anything in particular, and it was working last time my laptop was on, though the time before that, I updated Fish to the latest version available on my system, 2.1.

The version is the latest -
andrew@haru ~> fish --version
fish, version 2.1.0

You can see my config.fish here - I do not attempt to use set_color, and it hasn't been changed since when it /was/ working.

https://github.com/AndrewHynes/dotfiles/blob/master/config.fish

I run Arch Linux.

Thanks.

[zanchey]

It might be worth checking the output of set | grep fish_color.

For reference, mine is:

fish_color_autosuggestion '666'  'green'
fish_color_command afffff
fish_color_comment red
fish_color_cwd green
fish_color_cwd_root red
fish_color_error 'red'  '--bold'
fish_color_escape cyan
fish_color_history_current cyan
fish_color_host '-o'  'cyan'
fish_color_match cyan
fish_color_normal normal
fish_color_operator cyan
fish_color_param '00afff'  'cyan'
fish_color_quote brown
fish_color_redirection normal
fish_color_search_match --background=purple
fish_color_status red
fish_color_user '-o'  'green'
fish_color_valid_path --underline

set_color isn't supposed to complain when passed no arguments (fixed in 469743c) but I think that might have been lost in the transition to making it a builtin (8d95d08).

[zanchey]

See also #337.

[VioletHynes]

Alright, so this seems to happen arbitrarily on some restarts, on the ones where it works, my set | grep fish_color seems to be standard, but otherwise, when it's not working, it's like this -

andrew@haru ~> set | grep fish_color
andrew@haru ~>

I've seen that thread above, and I've done some googling, but yeah, I can't really find any apparent fix.

[deifyed]

Started getting this message a couple of weeks ago. I'm running fish version 2.1.0 on Arch Linux.

EDIT: It got sorted when I re-ran fish_config and rechose my prompt theme.

[VioletHynes]

Thanks for the command - I'm currently looking into some easy way to get the defaults back...

[cjxgm]

Same here, on archlinux. I backup my fish_prompt, re-ran fish_config and choose anything, then restore my fish_prompt, it got fixed. I wonder why.

[cjxgm]

I don't think this really fix anything, it just ignores the potential bug.

The problem is why the variable fish_user_whatever is not set. It is set by fish_config, so it is supposed to be there and it was, but it would suddenly disappear now and then.

[denji]

set_color: Expected an argument
set_color: Expected an argument

osx 10.9 + ohh-my-fish

$ brew info fish
fish: stable 2.1.0

[cjxgm]

That's because sometimes fishd.MACHINE_ID will lose some contents.

I backed up my fishd.cjprods as fishd.cjprods.bak, then wait this bug to appear.
When it finally appeared:

$ diff fishd.cjprods.bak fishd.cjprods 
5d4
< SET __prompt_initialized_2:\x1d
14d12
< SET fish_color_host:\x2do\x1ecyan
22,23d19
< SET fish_color_status:red
< SET fish_color_user:\x2do\x1egreen

So, you see that universal variables are all lost.

[VioletHynes]

Note (as the one who originally opened the issue) - mine has been completely fixed at this point, probably from one of the latest updates.

Version 2.1.0-3

[ghost]

This happened to me after using OSX' Migration Assistant to move my user to new Mac.

[ghost]

Fixed by re-running fish_config and choosing a prompt.

[pwr22]

Is there anyway to fix this without fish_config? I'm thinking about headless machines here

[ridiculousfish]

It looks like set_color doesn't complain now, so this ought to no longer reproduce on ToT.

We can leave this open to track actually repairing cases of unset colors.

[cjxgm]

There is a workaround (a.k.a. dirty hack).

When everything works as expected, open your fishd.MACHINE_ID (in linux, it's ~/.config/fish/fishd.***), you will see things like this:

...
SET fish_color_error:red\x1e\x2d\x2dbold
SET fish_color_escape:cyan
SET fish_color_history_current:cyan
SET fish_color_host:\x2do\x1ecyan
...

copy and paste them into config.fish (in linux, it's ~/.config/fish/config.fish), then edit it to make it looks like this:

...
set -U fish_color_error red\x1e\x2d\x2dbold
set -U fish_color_escape cyan
set -U fish_color_history_current cyan
set -U fish_color_host \x2do\x1ecyan
...

i.e. replace SET by set -U, replace the colon : by a space .
Or, if you don't like those\x1e\x2d things, you can replace them too:

...
set -U fish_color_error red --bold
set -U fish_color_escape cyan
set -U fish_color_history_current cyan
set -U fish_color_host -o cyan
...

i.e. replace \x1e by a space , replace\x2dby a dash-.

So then, the universal variables will be set every time you launch fish.
Though I don't like to set them every time I launch fish, so I did something like this:

set -l name "any-string-will-do"
if [ "$fish_user_environment" != "$name" ]
    ...
    set -U fish_color_error     red --bold
    set -U fish_color_escape    cyan
    set -U fish_color_history_current    cyan
    set -U fish_color_host      -o cyan
    ...
    set -U fish_user_environment    $name
end

In this way, it will only set those universal variables when they got lost together with $fish_user_environment.

[suuuehgi]

The problem still persists for me. And it appears since the last update.
Fixed by re-running fish_config and choosing a prompt.

[caioalonso]

I am having this issue with fish 2.1.1 on an Arch Linux system.

Re-running fish_config and choosing any prompt does not solve the problem. @cjxgm's hack did not work either.

Opening functions/fish_prompt.fish and commenting out the part that says:

if not set -q __fish_prompt_cwd
    set -g __fish_prompt_cwd (set_color $fish_color_cwd)
end

suppresses the error message, but probably some color definition will stay broken.

Of course, choosing a prompt that does not have a similar code as this one will not cause the error message to show up, such as the Nim prompt or the Just a Dollar prompt.

[pwr22]

What was the exact error you got? It looks like you probably need to set
fish_color_cwd to something

Peter
On 24 Jan 2015 12:06, "Caio Alonso" notifications@github.com wrote:

I am having this issue with fish 2.1.1 on an Arch Linux system.

Re-running fish_config and choosing any prompt does not solve the
problem. @cjxgm https://github.com/cjxgm's hack did not work either.

Opening functions/fish_prompt.fish and commenting out the part that says:

if not set -q __fish_prompt_cwd
set -g __fish_prompt_cwd (set_color $fish_color_cwd)
end

suppresses the error message, but probably some color definition will stay
broken.

—
Reply to this email directly or view it on GitHub
#1335 (comment)
.

[caioalonso]

@pwr22 the exact error is:

set_color: Expected an argument

Yes, that was the case, my fish_color_cwd was unset and after setting it the problem was solved. The thing is, I hadn't messed with my fish config in months and I have no idea why this happened.

[JamesMcMahon]

Having the same issue.

Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
set_color: Expected an argument
set_color: Expected an argument

It happened for me when I did a clone from one Macbook to another, though that most likely is just coincidence.

EDIT:

As @bobef mentioned, this can be fixed be rerunning fish_config and going into the prompt section. Note: I did not select a new prompt and when I previously ran fish_config without going in prompt the issue was not fixed.

[mirco]

Same issue for me. It keeps reoccuring every other reboot or so. For no reason obvious to me fish_color_user and fish_color_host don't get set anymore and I have to reselect the 'Classic + Git' prompt to fix it.

[zanchey]

My suspicion is that your MAC address or other system identifier is changing, leading fishd to create new universal variable stores. Do you have any other universal variables set? Do they persist across the reboots?

[mirco]

No they do not persist (I did 'set -e -U fish_greeting' and now it is set to the default value again).

MAC address doesn't change on reboot. This is just a normal laptop with wifi and ethernet. What other mechanisms does fish use as system identifier?

[gdelugre]

Same problem here.

My config is fish 2.1.2 on ArchLinux.
The strange thing is that it's not happening all the time, but pretty often across reboots.

[zanchey]

Could you post the contents of ls -l ~/.config/fish/ when this happens?

[mirco]

$ ls -l .config/fish
total 564
-rw-r--r-- 1 mirco mirco 551972 Mar 16 00:02 fish_history
-rw-r--r-- 1 mirco mirco  18178 Mar 14 20:36 fish_read_history
-rw------- 1 mirco mirco   1157 Mar 16 00:01 fishd.frangipani
drwx------ 1 mirco mirco    288 Mar 14 20:31 functions

where frangipani is my hostname

By the way, why don't you use the content of /etc/machine-id if it exists (it does on most modern linux distributions)? It was created exactly for the purpose of uniquely identifying a machine and is stable for the lifetime of the installation unless manually changed and independent from hardware changes.
See http://www.freedesktop.org/software/systemd/man/machine-id.html for more info

[pwr22]

Never heard of that before but I'm +1 for that too

[zanchey]

OK, it doesn't look like your hostname is changing, so that's that idea out.

The reason fish doesn't use the machine-id, I suspect, is that it's relatively new. It would be good to use that on systems where it's available, although the migration path might be a bit interesting.

Has anyone been able to reproduce this with a recent HEAD/master build?

[pwr22]

I used to have this issue back on the very old release in the ubuntu repos. Nothing like this since later versions though and for me the fishd files were all based on my MAC last I checked

[smokku]

Here's how I just fixed it (when these values somehow disappeared from my fishd.hostname):

$ function set_default; set -U -- $argv; end
$ grep 'set_default' /usr/share/fish/functions/__fish_config_interactive.fish | grep -v function | source

[mirco]

I've installed a git build now for a couple of months and the issue hasn't come up since, so it seems to be resolved in the next release. The release it occured on was 2.1.2.

[zanchey]

We can leave this open to track actually repairing cases of unset colors.

I think it would be a good idea to have a fish_reset function to reset e.g. colors, but as the proximate issue is solved I'm going to bump this out of the 2.2.0 milestone.

[dolohow]

I have the same issue, after unexpected restart when something is going on in a console under fish I have

set_color: Expected an argument

and I need to manually chose prompt again in fish_config, because it's different.

[krader1961]

@AndrewHynes I'd like to propose closing this issue and continuing the discussion in issue #1912. Normally I would propose the inverse (closing the newer issue as a duplicate of the older one) but in this case I think the newer issue more clearly captures the core problem.

[faho]

Closing as duplicate.

[dolohow]

For the record with new version of fish shell the issue no longer happens on my machines.