bug: strange output after creating fish_prompt function

[ghost]

Are you following the right branch?

• [X] My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

• [X] I have searched the existing issues

Issue description

After I create the fish_prompt function as follows:

programs.fish.functions.body =  ''
                        set -l last_pipestatus $pipestatus:
                        set -lx __fish_last_status $status;

                        if not set -q VIRTUAL_ENV_DISABLE_PROMPT
                            set -g VIRTUAL_ENV_DISABLE_PROMPT true
                        end

                        set colorScheme (gsettings get org.gnome.desktop.interface color-scheme | sed "s/'//g")

                        # colorScheme has the value 'prefer-dark', had to escape the first ' to make this work. Dang.
                        # However, this caused another issue, with VScode syntax highlight. So I just used sed (as seen above) to cut out the godforsaken quotations.

                        if test $colorScheme = prefer-dark
                            switchColorschemes --prompt adwaita-dark
                        else
                            switchColorschemes --prompt adwaita-light
                        end

                        if test $USER = root
                            set_color red
                            printf '%s' $USER
                            set_color normal
                        else
                            set_color yellow
                            printf '%s' $USER
                            set_color normal
                        end

                        printf ' at '

                        set_color magenta
                        echo -n (prompt_hostname)
                        set_color normal
                        printf ' in '

                        set_color $fish_color_cwd
                        printf '%s' (prompt_pwd)
                        set_color normal

                        if test $__fish_last_status -ne 0
                            set_color red
                            printf ' [%s]' $__fish_last_status
                            set_color normal
                        end

                        if test -n "$VIRTUAL_ENV"
                            printf "(%s) " (set_color blue)(basename $VIRTUAL_ENV)(set_color normal)
                        end
                        printf ' %% '
                        set_color normal
                    '';

I get the following output when switching to a new h-m derivation

warning-path: Unable to locate data directory derived from $HOME: '/homeless-shelter/.local/share/fish'.
warning-path: The error was 'Permission denied'.
warning-path: Please set $HOME to a directory where you have write access.

error: can not save universal variables or functions
warning-path: Unable to locate config directory derived from $HOME: '/homeless-shelter/.config/fish'.
warning-path: The error was 'Permission denied'.
warning-path: Please set $HOME to a directory where you have write access.

I don't notice anything weird with my system afterwards, but it still seems like a weird output.

Maintainer CC

@matthewess

System information

- system: `"x86_64-linux"`
 - host os: `Linux 6.0.12-zen1, NixOS, 23.05 (Stoat), 23.05pre434584.1710ed1f6f8`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.12.0`
 - channels(root): `"nixos"`
 - channels(m911t): `"home-manager"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[ghost]

It doesn't seem to happen in future derivations

[sloane-shark]

@rycee I remember seeing the /homeless-shelter/ path mentioned in test output, but I imagine this isn't related to test code? Is there some "guard" I need to introduce in the fish formatting code?

[rycee]

While building a Nix derivation inside a sandbox the HOME directory will be set to a read-only directory /homeless-shelter. So something is trying to write to the home directory during a Nix build, which is not allowed. If it is absolutely necessary to have a writable home then you can set HOME=$(mktemp -d).

[sloane-shark]

Digging into this more now. I have tracked down the code path in fish_indent that causes this: fish_indent.cpp => env.cpp => path.cpp.

Running nix-shell --pure tests -A run.fish-format-scripts seems to be a good test case for this, as it produces the errors on stderr when it runs fresh. To get a new rerun, I've been adding echo <random char> at the beginning of the body of the fishIndent script body to get it to rebuild.

My first attempt to fix was hoping that invoking fish_indent via fish as

fish -c "fish_indent" < $textPath > $out

would perform some necessary setup, but it seemingly produced even more errors due to fish trying to access things in my system's /etc

Fish includes a --no-config option, so I also tried

fish --no-config -c "fish_indent" < $textPath > $out

This cleared up the errors from fish trying to read /etc, but didn't resolve the initial errors. My guess is that the flag only applies to the fish binary's config lookups, and doesn't propagate to fish_indent.

Following @rycee's advice, I replaced that with

env HOME=$(mktemp -d) fish_indent < $textPath > $out

Which does run with no errors. As far as I can tell, fish_indent itself provides no option to prevent it from checking for files in $HOME, so this seems like a passable stopgap solution to me. I'm happy to open a PR with this change.

edit: I asked in the fish-shell gitter, and it seems like this is our best bet for now:

fish_indent reads user configuration (like universal variables in ~/.config/fish) to respect feature flags that change syntax and hence formatting (see status features). Your workaround seems good. Maybe we should add the --no-config here as well, or even suppress the error if it's just about the ampersand syntax change

[sloane-shark]

I wonder if we can get a minimal reproduction for this on a commit prior to #3513 being merged in order to confirm that the bug is absent on master before closing this.

[ghost]

well now i can confirm that it doesnt print out the thing in the op

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[D3vil0p3r]

@matthewess @rycee why the user was using programs.fish.functions.body? If the user would like to change its fish_prompt function to change FISH PROMPT, the correct syntax should not be programs.fish.functions.fish_prompt.body and inside it the fish code?

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.