Contents of $argv for source'd script (AKA ".") are weird

[lrm29]

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!

[ridiculousfish]

. is the builtin_source function.

[lrm29]

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.

[faho]

I re-titled this to try to make it a bit more discoverable.

[krader1961]

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 $argv is empty. Fixing this will break anything depending on the bug but I think this is a case where breaking backward compatibility is worth it.

[lrm29]

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?

[krader1961]

How would you advertise the change? Would it be a release note?

Yes

Would it be possible to warn for a release if $argv is accessed when no arguments are passed?

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.