The "." command should be called "source"

[jonclayden]

Slightly controversial, perhaps, but with all of fish's commands having nice user-friendly names, "." stands out like a sore thumb. Heck, it's even indexed as "source" in the help page (i.e. after "set_color" and before "status"). I realise issue #211 sort of raised this, but I've never seen a good explanation of why the command is called ".". I therefore suggest changing the name.

[ridiculousfish]

"." is a terrible name whose sole virtue is compatibility with other shells.

[ncraike]

Would it be terrible to make "source" an alias for "." (or vice-versa)? I just had trouble finding the command in the docs (to figure out its argv behaviour) because it's really hard to search a web page for ".".

[dag]

I think it should be renamed to source, with . not used at all.

[ghost]

Honestly, we've broken compatibility anyway; source should be used instead.

[jonclayden]

I agree (FWIW).

[dag]

However, it might be prudent to have . display an error message that points at source, similar to fish's errors when trying some other bashisms.

Also, it doesn't necessarily have to be source, although that might be the best option since it's familiar and unlikely to be used as the name of any program given it's stolen in other shells. But some other ideas anyway:

• eval [--file or -f] or some other flag
• eval <file
• load, import, include, use... Not require though as it implies only loading a file once. Arguably they all also imply having some sort of load path so are probably all bad.
• execute. Too similar to the existing exec though.

Reasons to even consider another name than source:

1. We can! fish already isn't, and shouldn't be only for the sake of it, compatible with other shells. However, there's no reason to be different just for the sake of it, either.
2. I'm not sure source has the right meaning as a verb, and noun commands seem odd. I'm no English professor though. ;-)

I like source and eval <file myself.

[dag]

In fact I would argue that, unless eval is somehow doing something different from source, eval <file is the only option compatible with the orthogonality law.

[xfix]

eval works with ARGV, source works with files. That is the difference. And no, eval < file doesn't work.

[dag]

I was suggesting making it work, not saying it already does. Or are you saying there's a reason it couldn't work?

[ghost]

eval < file shouldn't work because the standard input of eval should equal the standard input of whatever script is run. eval bash script < file would be equivalent to bash script < file.

That being said, source < file SHOULD work, I think. source < file would probably be roughly equivalent to eval (cat file).

[dag]

Ah, that's a good point. What about eval -f?

[ghost]

I don't think that adding a flag would be a good idea. Makes more sense as a separate function.

[dag]

Well arguably flags is the preferred way in fish, for example set -x rather than export, set -l rather than local, and the proposed list {--split,--join}, though I've argued against that last one myself.

[gustafj]

source along with a helpful error message for . is my preference, but that might just be because I'm accustomed to csh like shells.
eval < file, eval -f file are both valid options and I don't see the problem with eval < file colliding with eval bash < file to me they are very distinct.
But I wouldn't want to require redirects for a function like this, and I'm not very fond of "one command to rule them all" that's why I vote for source.

[ghost]

I think that this feature should be implemented soon because it can be very confusing. Because of the implicit cd, I often use .. to go to the previous directory, but if I accidentally make a typo and say ., it'll wait for input from stdin, not respond to ctrl-C, and hang ultil I press ctrl-D to send an EOF. This could potentially be very confusing to people that don't know what's going on.

[xfix]

I think fish simply shouldn't ever have ., considering it's confusing (with auto-cd), non-discoverable, and cryptic (if I would see it in code, without knowing about it, I simply couldn't say anything about it). But considering changing . to source would break lots of scripts, I decided to go with soft deprecation - the . command still works, but using it directly without arguments (and without piping input to it) causes it to redirect you to new source command, without needing to press CTRL+D (to make @Undeterminant case less confusing).

In fish 3, I guess "." command could be removed, but not sure about that.

[zanchey]

I'm leaving this open as a reminder to update the documentation.

[zanchey]

Also needs completions updated.