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
Contents of $argv for source'd script (AKA ".") are weird #139
Comments
. is the builtin_source function. |
Thanks, on line 2853 I changed it to either: parse_util_set_argv( argv+1, wcstring_list_t()); to include the filename that will be sourced or to: parse_util_set_argv( argv+2, wcstring_list_t()); if not. |
I re-titled this to try to make it a bit more discoverable. |
This behavior is wrong. I've confirmed the current git head fish still behaves this way. Also, sh, bash, and zsh do not behave like fish. If you don't pass any args to the sourced script then their equivalent of |
How would you advertise the change? Would it be a release note? Would it be possible to warn for a release if $argv is accessed when no arguments are passed? |
Yes
Yes, it's just a "small matter" of writing a bunch of code then tracking the change to remove it and implement the correct behavior. And merely emitting a warning can itself cause problems. I think we just need to bite the bullet. It's a shame no one fixed this four years ago when you brought it to our attention. |
Hello,
When using . with no arguments, $argv contains the name of the file being sourced. If any arguments are supplied, then the name of the file being sourced is not in $argv. e.g.;
. FILENAME -> $argv = FILENAME
. FILENAME arg1 -> $argv = arg1
. FILENAME arg1 arg2 -> $argv = arg1 arg2
Is this the desired default behaviour? I'm not sure where to find the . function in the git repository.
Thanks!
The text was updated successfully, but these errors were encountered: