-
-
Notifications
You must be signed in to change notification settings - Fork 979
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
Set default fallback path when XDG_DATA_DIRS is empty #4199
Conversation
… the specification
Thanks for the quick fix ! I'll test this when I get back to my PC (though it probably works) |
I'm worried that the two paths you're adding now don't exhaust the default locations (though then again, I haven't really tried to figure out what's going on in your code). From the xdg spec:
Indeed, I don't have |
We do not set XDG_DATA_HOME, so it is not affected. If the value is empty, it will remain empty afterwards as well. Depending on your situation, you might want to get your environment variables configured properly. Otherwise you may also run into problems elsewhere. :) It seems ridiculous to me to expect every GUI software to check and set the fallback path on its own before adding to XDG_DATA_DIRS. |
why are we not setting it on macOS. While xdg-open doesnt exists there, |
One problem with this solution is that the paths may be different on different Linux distributions, even on macOS. For some unusual Linux distributions, the default paths that do not use this fallback path will not take effect. For devices using Apple Silicon in combination with homebrew, it also does not work, as far as I know. So is it necessary to check every possible path and then add them? In fact, if there is a special need to use it, it is better to set it in config env by the user. |
On Sat, Nov 06, 2021 at 07:49:13AM -0700, page-down wrote:
> why are we not setting it on macOS. While xdg-open doesnt exists there,
> there is probably other software that uses it.
One problem with this solution is that the paths may be different on different Linux distributions, even on macOS.
Are they actually different? And if they are where are they defined? I
doubt every application on every OS defines these defaults for itself.
Check Qt to see where it gets the default values from.
For some unusual Linux distributions, the default paths that do not use this fallback path will not take effect.
For devices using Apple Silicon in combination with homebrew, it also does not work, as far as I know.
So is it necessary to check every possible path and then add them?
In fact, if there is a special need to use it, it is better to set it in config env by the user.
The problem is we cant have a default setup that breaks many users software
requiring them to change config.
|
https://docs.brew.sh/Installation
I am uncomfortable with adding a specific package manager path to kitty code, it means one more dependency and you have to track and maintain changes to this package manager. That's fine if you want.
Yes, that's for sure. It would solve the problem in the most common cases if the path above could also be added. |
Not sure I follow. Shouldn't brew be adding that value itself somewhere, |
From my understanding, the situation is like this:
In general, yes, what the packager really maintains is: the default fallback path when XDG_DATA_DIRS is empty. For distributions, all normal distributions, running X11/Wayland, comes with the default XDG_DATA_DIRS environment variable, which is also maintained by the packager. The root of the problem is that kitty is not maintained by these packagers, and if it is maintained by them, then it is definitely working properly with other software. My personal opinion is that everything that is not the default should be configured by the user. Because macOS itself does not come with any default xdg path specification. We have no way of knowing which package managers are installed and which custom paths are used. The problem mentioned today is also caused by the system not being properly configured with environment variables, as Linux systems are installed and configured by the user. Normally, this problem should be properly solved by the maintainer of the linux distribution. We cannot support all cases that are beyond normal. |
I dont think I like this approach. XDG_DATA_DIRS is too fragile. And I suggest either of the following approaches:
1.5) Delete XDG_DATA_DIRS and alias fish to a function that sets both
|
Yes, I didn't like it either. The final conclusion is that you can't leave an XDG_DATA_DIRS environment variable with only kitty data dir. Is it appropriate to remove it when there is only one kitty data dir left? This does not affect the majority of users on Linux who already have the correct XDG_DATA_DIRS, they can continue to run fish in fish once they have configured KITTY_SHELL_INTEGRATION. |
Well if you want to use the (1) approach above there are some subtleties to consider. a) check that after removing XDG_DATA_DIRS completion for the kitty command is still loaded from the correct place b) As for the actual removal, the simplest would be to set another env var called say KITTY_FISH_XDG that contains the value of the XDG_DATA_DIRS variable before kitty changes it. If there was no XDG_DATA_DIRS variable it should be unset. If it was empty it should be empty but set. And so on. Then the integration script can simply set/delete XDG_DATA_DIRS to that value and then delete KITTY_FISH_XDG |
It's really too bad. We can't have nice things because of this terrible environment. This approach doesn't look like it's going to work either. Launching any program will cause XDG_DATA_DIRS to be used. kitty -o 'map f1 launch sh -c "env|grep XDG;read"' This is a dead end. Never thought that a small fallback path would make such a general purpose environment variable totally unusable. |
I'm working on the second approach. Only users who have XDG_DATA_DIRS configured correctly will have the nice thing and won't need to clean up the XDG_DATA_DIRS environment variable. Those that don't have it configured fall back to XDG_CONFIG_HOME symlink by default. May I ask if this is acceptable to you? BTW: The second approach has a problem with loading mismatched integration scripts when running multiple versions of kitty at the same time, especially for kitty development. |
No need, I have applied approach 1 without polluting the evironment for |
Thank you very much. Also the environment variables need to be set with set --export XDG_DATA_DIRS "$KITTY_FISH_XDG_DATA_DIRS" |
The current implementation has a problem where the custom XDG_DATA_DIRS configured by the user in # ~/.config/fish/conf.d/user-xdg-conf.fish
# This should be the value that the user expects.
set -gx XDG_DATA_DIRS /tmp/from-user-conf-d:/usr/local/share:/usr/share XDG_DATA_DIRS=/tmp/from-parent-env kitty --config=NONE -o shell=fish -o 'env XDG_DATA_DIRS=/tmp/from-kitty-conf-env'
# after user config
XDG_DATA_DIRS=/tmp/from-user-conf-d:/usr/local/share:/usr/share
KITTY_FISH_XDG_DATA_DIRS=/tmp/from-kitty-conf-env
# first prompt, after integration script
XDG_DATA_DIRS=/tmp/from-kitty-conf-env Maybe you have a better solution for this. |
Should be fine now |
Actually, I was trying to define the correct XDG_DATA_DIRS in fish conf.d to enable shell integration for the command I want to enable shell integration for running kitty --config=NONE -o shell=fish set -gx KITTY_SHELL_INTEGRATION enabled
set -gx --path XDG_DATA_DIRS /path/to/kitty/shell-integration /path/to/others/dirs |
Alias fish to a function that sets the env vars and runs the real fish |
Unfortunately, this does not work. fish does not like being alias. unless renamed.
Is this feasible? KITTY_CHILD_FINAL_XDG_DATA_DIRS=/path/to/all/xdg/dirs
KITTY_FISH_XDG_DATA_DIR=/path/to/shell-integration
XDG_DATA_DIRS=/user/conf.d/defined
if test "$XDG_DATA_DIRS" != "$KITTY_CHILD_FINAL_XDG_DATA_DIRS"
# keep the user defined XDG_DATA_DIRS
end EDIT: It doesn't seem to work, the user can set it to the same path. The case is indistinguishable. |
You dont call fish inside fish you use \fish (at least that works to |
Thanks for the reminder, almost forgot about this. That looks like it's working fine. I'm not so sure if there will be problems elsewhere. I can't think of a better way. So I'll leave it for now. EDIT: Sorry for not being able to notice that the exit path is already there. set -g KITTY_SHELL_INTEGRATION enabled
set -gx XDG_DATA_DIRS $KITTY_FISH_XDG_DATA_DIR:/path/to/system/dirs
set -e KITTY_FISH_XDG_DATA_DIR |
When XDG_DATA_DIRS is empty, setting the path will cause the default fallback path to not take effect.
So append the default fallback path when it is empty.
Fixes:
#3948 (comment)