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

Changing hostnames can lose "universal" variable values #183

Closed
kballard opened this Issue Jun 26, 2012 · 15 comments

Comments

Projects
None yet
5 participants
@kballard
Contributor

kballard commented Jun 26, 2012

I just put my laptop to sleep on one network, moved over to another, and woke it up, and this caused me to lose 2 of my "universal" variables. If I look at my ~/.config/fish/fishd.originalhostname file it lists the variables but my ~/.config/fish/fishd.newhostname file is missing them.

Why are the fishd files specified on a per-host basis anyway? My only guess is so you can synchronize your ~/.config/fish folder between machines and keep separate fishd variable sets, but that would be far better served using some permanent hardware identifier instead of the hostname which is prone to changing.

@kballard

This comment has been minimized.

Show comment
Hide comment
@kballard

kballard Jun 26, 2012

Contributor

My assumption here is that if I don't have any instances of fish running when I switch networks, and therefore no instances of fishd, when fishd relaunches it won't know what file to pull settings from so it effectively resets. If true, this is pretty bad.

Contributor

kballard commented Jun 26, 2012

My assumption here is that if I don't have any instances of fish running when I switch networks, and therefore no instances of fishd, when fishd relaunches it won't know what file to pull settings from so it effectively resets. If true, this is pretty bad.

@kballard

This comment has been minimized.

Show comment
Hide comment
@kballard

kballard Jun 28, 2012

Contributor

This bug hit me again twice today. It's extremely frustrating when it occurs. I'm starting to think I should give up on the idea of universal variables persisting and start recording everything I care about in config.fish.

Contributor

kballard commented Jun 28, 2012

This bug hit me again twice today. It's extremely frustrating when it occurs. I'm starting to think I should give up on the idea of universal variables persisting and start recording everything I care about in config.fish.

@kballard

This comment has been minimized.

Show comment
Hide comment
@kballard

kballard Jul 2, 2012

Contributor

I would really appreciate some explanation for why fishd cares about the current hostname. This is currently my biggest problem with fish, because it keeps resetting all my universal variables on my laptop.

Contributor

kballard commented Jul 2, 2012

I would really appreciate some explanation for why fishd cares about the current hostname. This is currently my biggest problem with fish, because it keeps resetting all my universal variables on my laptop.

@maxfl

This comment has been minimized.

Show comment
Hide comment
@maxfl

maxfl Jul 3, 2012

Contributor

I completely agree with you, this behaviour is rather annoying.
I would appreciate Universal variables be more Universal.
And host specific variables can be set in the config.fish.

Contributor

maxfl commented Jul 3, 2012

I completely agree with you, this behaviour is rather annoying.
I would appreciate Universal variables be more Universal.
And host specific variables can be set in the config.fish.

@kballard

This comment has been minimized.

Show comment
Hide comment
@kballard

kballard Jul 3, 2012

Contributor

I don't mind per-machine "universal" variables, that makes sense. But I do mind that the hostname is being used as a proxy for the machine, when there are actual hardware-specific values that would make a lot more sense and wouldn't change every time I leave work with my laptop.

Contributor

kballard commented Jul 3, 2012

I don't mind per-machine "universal" variables, that makes sense. But I do mind that the hostname is being used as a proxy for the machine, when there are actual hardware-specific values that would make a lot more sense and wouldn't change every time I leave work with my laptop.

@maxfl

This comment has been minimized.

Show comment
Hide comment
@maxfl

maxfl Jul 3, 2012

Contributor

I guess that having the file fishd.HW7DF876HGJHD7JJ is not very friendly. The user will also need to update the variables when changing the computer (:
the hostname is more persistent in this sense. But not in your case, of course.

Contributor

maxfl commented Jul 3, 2012

I guess that having the file fishd.HW7DF876HGJHD7JJ is not very friendly. The user will also need to update the variables when changing the computer (:
the hostname is more persistent in this sense. But not in your case, of course.

@kballard

This comment has been minimized.

Show comment
Hide comment
@kballard

kballard Jul 3, 2012

Contributor

I don't know about other systems, but on OS X each user has a UUID. This is stored in Directory Services under the key 'GeneratedUID'. So in theory fishd could use this, and it would persist if I restored my user account to another computer, but would be different for every user. But of course it would be pretty ugly, with fishd.66666619-E037-4093-9140-E16CD7A1B6CA

Contributor

kballard commented Jul 3, 2012

I don't know about other systems, but on OS X each user has a UUID. This is stored in Directory Services under the key 'GeneratedUID'. So in theory fishd could use this, and it would persist if I restored my user account to another computer, but would be different for every user. But of course it would be pretty ugly, with fishd.66666619-E037-4093-9140-E16CD7A1B6CA

@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Jul 9, 2012

Member

Let's get rid of the dumb per-hostname behavior for fish 2.0.

Member

ridiculousfish commented Jul 9, 2012

Let's get rid of the dumb per-hostname behavior for fish 2.0.

@zanchey

This comment has been minimized.

Show comment
Hide comment
@zanchey

zanchey Nov 2, 2012

Member

Some of us run fish on more than one host at the same time with the same underlying filesystem (i.e. /home on NFS). It would be nice if fish didn't create hilarious race conditions by writing to the same config file on exit.

Member

zanchey commented Nov 2, 2012

Some of us run fish on more than one host at the same time with the same underlying filesystem (i.e. /home on NFS). It would be nice if fish didn't create hilarious race conditions by writing to the same config file on exit.

@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Nov 2, 2012

Member

zanchey, would you be unhappy if per-host behavior were lost?

Member

ridiculousfish commented Nov 2, 2012

zanchey, would you be unhappy if per-host behavior were lost?

@zanchey

This comment has been minimized.

Show comment
Hide comment
@zanchey

zanchey Nov 5, 2012

Member

Not terribly. I think the much-more-common desire is the same configuration on multiple systems, though if there was a way to override the configuration file then that could be used to emulate per-host behaviour.

The only issue I can see is with tools like ssh-agent, which would be great candidates for universal variables but for which the contents of the variable will differ on a host-to-host basis.

Would fishd try and communicate with other hosts by watching the configuration file for changes or similar? The problem I am forseeing is something like
host1~$ set -U myhostname host1 host2~$ set -U myhostname host2 host1~$ echo $myhostname host1 host2~$ echo $myhostname host2 << exit both processes, restart both machines, whatever >> host1~$ echo $myhostname look you got yourself into this mess

Member

zanchey commented Nov 5, 2012

Not terribly. I think the much-more-common desire is the same configuration on multiple systems, though if there was a way to override the configuration file then that could be used to emulate per-host behaviour.

The only issue I can see is with tools like ssh-agent, which would be great candidates for universal variables but for which the contents of the variable will differ on a host-to-host basis.

Would fishd try and communicate with other hosts by watching the configuration file for changes or similar? The problem I am forseeing is something like
host1~$ set -U myhostname host1 host2~$ set -U myhostname host2 host1~$ echo $myhostname host1 host2~$ echo $myhostname host2 << exit both processes, restart both machines, whatever >> host1~$ echo $myhostname look you got yourself into this mess

@kballard

This comment has been minimized.

Show comment
Hide comment
@kballard

kballard Nov 5, 2012

Contributor

Could we introduce a separate per-machine variable that acts like universal but is machine-specific? I would suggest not using hostname for this, but some other machine identifier (en0 MAC, or a serial number if that can be retrieved for the given OS).

-Kevin Ballard

On Nov 4, 2012, at 5:00 PM, David Adam notifications@github.com wrote:

Not terribly. I think the much-more-common desire is the same configuration on multiple systems, though if there was a way to override the configuration file then that could be used to emulate per-host behaviour.

The only issue I can see is with tools like ssh-agent, which would be great candidates for universal variables but for which the contents of the variable will differ on a host-to-host basis.

Would fishd try and communicate with other hosts by watching the configuration file for changes or similar? The problem I am forseeing is something like

host1~$ set -U myhostname host1
host2~$ set -U myhostname host2
host1~$ echo $myhostname
host1
host2~$ echo $myhostname
host2
<< exit both processes, restart both machines, whatever >>
host1~$ echo $myhostname
look you got yourself into this mess


Reply to this email directly or view it on GitHub.

Contributor

kballard commented Nov 5, 2012

Could we introduce a separate per-machine variable that acts like universal but is machine-specific? I would suggest not using hostname for this, but some other machine identifier (en0 MAC, or a serial number if that can be retrieved for the given OS).

-Kevin Ballard

On Nov 4, 2012, at 5:00 PM, David Adam notifications@github.com wrote:

Not terribly. I think the much-more-common desire is the same configuration on multiple systems, though if there was a way to override the configuration file then that could be used to emulate per-host behaviour.

The only issue I can see is with tools like ssh-agent, which would be great candidates for universal variables but for which the contents of the variable will differ on a host-to-host basis.

Would fishd try and communicate with other hosts by watching the configuration file for changes or similar? The problem I am forseeing is something like

host1~$ set -U myhostname host1
host2~$ set -U myhostname host2
host1~$ echo $myhostname
host1
host2~$ echo $myhostname
host2
<< exit both processes, restart both machines, whatever >>
host1~$ echo $myhostname
look you got yourself into this mess


Reply to this email directly or view it on GitHub.

@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Jan 8, 2013

Member

552d8f3 makes fishd prefer to use the MAC address instead of hostname when persisting its variables. If the MAC address cannot be fetched, it reverts to using the hostname.

It also correctly migrates the hostname data to the MAC address data.

Member

ridiculousfish commented Jan 8, 2013

552d8f3 makes fishd prefer to use the MAC address instead of hostname when persisting its variables. If the MAC address cannot be fetched, it reverts to using the hostname.

It also correctly migrates the hostname data to the MAC address data.

@szhu

This comment has been minimized.

Show comment
Hide comment
@szhu

szhu Jun 12, 2015

I am using fish on a computer system (the Berkeley CS department) where I can access my home directory through one of many login nodes. Because the MAC address of each of these login nodes is different, I am not able to rely on universal variables unless I use the same login node each time, which ideally I don't want to do.

I understand that having only one universal variable file can cause race conditions, and this could happen because sometimes I'm using multiple login nodes at once. How does fish's persistent function storage (~/.config/fish/functions) not run into the same issue?

szhu commented Jun 12, 2015

I am using fish on a computer system (the Berkeley CS department) where I can access my home directory through one of many login nodes. Because the MAC address of each of these login nodes is different, I am not able to rely on universal variables unless I use the same login node each time, which ideally I don't want to do.

I understand that having only one universal variable file can cause race conditions, and this could happen because sometimes I'm using multiple login nodes at once. How does fish's persistent function storage (~/.config/fish/functions) not run into the same issue?

@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Jun 12, 2015

Member

We have a PR to make the uvars filename settable, which ought to address your case. Functions are tracked as separate files so there's fewer synchronization concerns, and we don't make any attempt to have per-machine or per-host files.

Member

ridiculousfish commented Jun 12, 2015

We have a PR to make the uvars filename settable, which ought to address your case. Functions are tracked as separate files so there's fewer synchronization concerns, and we don't make any attempt to have per-machine or per-host files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment