You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 of stdin 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 running funcsave.
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.
~/Desktop ❯❯❯ echo $TERM
alacritty
~/Desktop ❯❯❯ uname -a
Darwin Neils-MacBook-Air.local 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul 5 22:22:52 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T8103 arm64
~/Desktop ❯❯❯
~/Desktop ❯❯❯
~/Desktop ❯❯❯
~/Desktop ❯❯❯ fish --version
fish, version 3.6.1
~/Desktop ❯❯❯ function deleteme
end
~/Desktop ❯❯❯ functions --details deleteme
stdin
~/Desktop ❯❯❯ funcsave deleteme
funcsave: wrote ~/.config/fish/functions/deleteme.fish
~/Desktop ❯❯❯ functions --details deleteme
stdin
The text was updated successfully, but these errors were encountered:
neilyio
changed the title
functions --details does not return source file path after initial funcsave.functions --details does not return source file path after initial funcsaveOct 19, 2023
It's possible this is the behavior we want, because technically that function was defined though stdin, not by reading a source file.
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 funcsave... which location wins? If you have a function in config.fish, and you funcsave it, was it defined in config.fish or is it now defined in the autoload file?
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 --reload option to funcsave to automate that source part - the path that funcsave uses won't always be in ~/.config/fish/functions.
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: