-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
functions --details
does not return source file path after initial funcsave
#10063
Comments
functions --details
does not return source file path after initial funcsave
.functions --details
does not return source file path after initial funcsave
The easiest thing to do is probably to funcsave foo; and source ~/.config/fish/functions/foo.fish That will redefine "foo" and thereby reset the filename. An alternative is to see if you get "stdin", and then check if an autoload file exists: set -l path (functions --details $name)
if test "$path" = stdin
set -l p (path filter -rf $fish_function_path/$name.fish)[1]
and set path $p
end
This is really the important point - it wasn't defined in that file, that's not where it comes from. In particular if you get the function from somewhere else and then decide to I think that what we have now is consistent and not wrong, so I'm not inclined to change it. I would be up for adding a |
I write a lot of custom fish scripts to help me edit/test fish functions, so I rely pretty heavily on
functions --details <function-name>
to tell me where a function is defined. I understand that a return string ofstdin
is expected when you freshly define a function at the command line, as there's no file path yet. But I was a little surprised that's still the case after runningfuncsave
.It's possible this is the behavior we want, because technically that function was defined though stdin, not by reading a source file. But in script pipelines like mine, where I like to automate creation/editing of fish functions, it means that I can't always have a consistent way to get a function's filepath.
A workaround for this is to run
function --details
in a subshell, which returns the correct filepath because the subshell loads the newly-saved function from its source file. But I'm not sure this is particularly intuitive. With my workaround, the proper filepath could be retrieved like this:Here's a short session demonstrating the behavior I see. My system info is at the top if it's helpful to anyone.
The text was updated successfully, but these errors were encountered: