Initial PATH contains /usr/bin/X11 on debian even though it doesn't exist.

[songgao]

On a debian "squeeze" base system, a custom compiled fish-shell sets its initial PATH to contain /usr/bin/X11, which does not exist in the system. This prevents "set" command from appending more entries into PATH variable because it will look for each entry in the provided PATH list, including the ones already in PATH, but "/usr/bin/X11" does not exist.
"mkdir /usr/bin/X11" makes it work.

Could this be a bug? Probably somewhere for looking up X11 path.

[Sean-Der]

Hey songgao I am running Debian Sid and had a similar issue, but not the exact same dir.

fish complained about '/usr/X11R6/bin' not existing. Check out share/fish/config.fish
and you will see everything being set, we should probably check that these dirs exist first.
Would you mind double checking and seeing if this was the issue? If so I will work on this
and make a pull request for it if you don't want to / don't have time

If not I have some more digging to do

[songgao]

Hi Sean-Der,

My share/fish/config.fish also has /usr/X11R6/bin set, but not /usr/bin/X11. Also my ~/.config/fish/config.fish doesn't seem to have anything for X11. The weird thing is that, although share/fish/config.fish has /usr/X11R6/bin set in PATH, the actually $PATH has /usr/bin/X11 instead of /usr/X11R6/bin.

Just for records, I changed the PREFIX using "./configure" when building fish-shell.

[Sean-Der]

We probably should pull out the X11R6 by default, that may be in a OSX thing though?

I will wait for maxfl or ridiculousfish to comment on this also, BUT it would seem to me a good compromise would
be test -d before adding any non-standard directories to your path having these verbose failures is not very
friendly. Thanks!

[songgao]

It seems that, when changing $PATH value, the set command is already designed to check if the directory exists. Try adding a non-exist directory into $PATH, it complains:

~> man test
~> set PATH /tmp/aaaa $PATH
set: Could not add component /tmp/aaaa to PATH.
set: No such file or directory

In share/fish/config.fish, the entries also seem to be tested before actually inserting into $PATH :

#
# Add a few common directories to path, if they exists. Note that pure
# console programs like makedep sometimes live in /usr/X11R6/bin, so we
# want this even for text-only terminals.
#

set -l path_list /bin /usr/bin /usr/X11R6/bin /usr/local/bin /usr/local/Cellar/fishfish/OpenBeta_r2/bin 

# Root should also have the sbin directories in the path
switch $USER
    case root
    set path_list $path_list /sbin /usr/sbin /usr/local/sbin /usr/local/Cellar/fishfish/OpenBeta_r2/sbin
        set path_list $path_list /sbin /usr/sbin /usr/local/sbin /nfs/usr/local/sbin
end

for i in $path_list
        if not contains $i $PATH
                if test -d $i
                        set PATH $PATH $i
                end
        end
end

I'm confused...

[Sean-Der]

Thanks for pointing out that file! I don't know why /usr/X11R6/bin is slipping by the directory test, but I will do my best to mess with that right now and figure it out.

I just am finishing up some man pages and I will be ready to check this out real quick

[ridiculousfish]

I'll do you one better: my PATH is being set with a universal variable (which skips the directory checking), and it contains an invalid directory, so even code like set PATH $PATH fails!

[ridiculousfish]

Fixed with this commit:

To git@github.com:fish-shell/fish-shell.git
60ef790..c1a23bf master -> master

Now fish warns you if you try to set a path containing an invalid directory, but only refuses to set it if every directory is invalid (and there's at least one entry).

[songgao]

That's awesome. Thanks ridiculousfish!

[anddam]

I see this has been fixed but I'm experiencing the same as the ticket reporter.

Where is /usr/bin/X11 being added to PATH?
Grepping the whole debian package didn't show any relevant match.

[ridiculousfish]

fish does add /usr/X11R6/bin to PATH, in share/config.fish, but /usr/bin/X11 is a mystery.

Perhaps it's part of a Universal variable? Do you see it set if you do cat ~/.config/fish/fisd.*?

[anddam]

Yep, that's kinda misterious, I recursively run grep on /etc and the fish package contents, whose only 'crypted' files are the man pages (they are gzipped) and I had no match for bin/X11. I guess even the ELF would match the string "X11" but they didn't.

There's no X11 in cat '~/.config/fish/fishd.*' either

This is happening on a Debian 6.0.6 just installed and then upgraded. How weird.

[ridiculousfish]

Another possibility is that it's coming from the login environment, e.g. .cshrc or .login

[anddam]

If in /etc then the grep should have matched those, in userdir I've got no .login (and I grepped home dir as well). The default shell in Squeeze is bash so cshrc is unlikely to affect this behavior (and I don't have .cshrc in home).
As said this is curious but I've already spent the time available for tracking down curious stuff, therefore I came here asking. I just created an /usr/bin/X11 directory and will live with that.
edit: I mean, while waiting fishfish going stable.

[JeanMertz]

@ridiculousfish is there any way to completely disable the warnings when adding non-existing paths? I have use cases where I want paths to be added for a future reference when the path is created. This now works correctly, but seeing those errors every time I add a non-existing path (especially when TDD'ing Fish scripts) can become quite annoying.

[ridiculousfish]

It might be sensible to disable those warnings in non-interactive sessions.

[JeanMertz]

@ridiculousfish even in interactive sessions I'd like to see a way to silence the output.

I have several paths in my PATH that might exist at one point or another, and I'd rather not be warned, as not having the paths exist is not harmful to the functioning of my system, so telling fish not to warn me about non-existing paths in PATH (as I can tell fish not to show a "welcome" message) would cut down the noise in my day-to-day output of Fish.

[ridiculousfish]

fish stopped complaining about invalid path entries (unless they contain a colon) in de8ccf1.