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

The "." command should be called "source" #310

Closed
jonclayden opened this Issue Sep 6, 2012 · 18 comments

Comments

Projects
None yet
7 participants
@jonclayden

jonclayden commented Sep 6, 2012

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

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Sep 7, 2012

Member

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

Member

ridiculousfish commented Sep 7, 2012

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

@ncraike

This comment has been minimized.

Show comment
Hide comment
@ncraike

ncraike Dec 18, 2012

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 ".".

ncraike commented Dec 18, 2012

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

This comment has been minimized.

Show comment
Hide comment
@dag

dag May 11, 2013

Contributor

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

Contributor

dag commented May 11, 2013

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 11, 2013

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

ghost commented May 11, 2013

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

@jonclayden

This comment has been minimized.

Show comment
Hide comment
@jonclayden

jonclayden May 11, 2013

I agree (FWIW).

jonclayden commented May 11, 2013

I agree (FWIW).

@dag

This comment has been minimized.

Show comment
Hide comment
@dag

dag May 11, 2013

Contributor

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.

Contributor

dag commented May 11, 2013

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

This comment has been minimized.

Show comment
Hide comment
@dag

dag May 11, 2013

Contributor

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.

Contributor

dag commented May 11, 2013

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

This comment has been minimized.

Show comment
Hide comment
@xfix

xfix May 11, 2013

Member

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

Member

xfix commented May 11, 2013

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

@dag

This comment has been minimized.

Show comment
Hide comment
@dag

dag May 11, 2013

Contributor

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

Contributor

dag commented May 11, 2013

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 11, 2013

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).

ghost commented May 11, 2013

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

This comment has been minimized.

Show comment
Hide comment
@dag

dag May 11, 2013

Contributor

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

Contributor

dag commented May 11, 2013

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 11, 2013

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

ghost commented May 11, 2013

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

@dag

This comment has been minimized.

Show comment
Hide comment
@dag

dag May 12, 2013

Contributor

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.

Contributor

dag commented May 12, 2013

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

This comment has been minimized.

Show comment
Hide comment
@gustafj

gustafj May 12, 2013

Contributor

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.

Contributor

gustafj commented May 12, 2013

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jul 3, 2013

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.

ghost commented Jul 3, 2013

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 xfix closed this in 5818289 Aug 14, 2013

@xfix

This comment has been minimized.

Show comment
Hide comment
@xfix

xfix Aug 14, 2013

Member

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.

Member

xfix commented Aug 14, 2013

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

This comment has been minimized.

Show comment
Hide comment
@zanchey

zanchey Aug 15, 2013

Member

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

Member

zanchey commented Aug 15, 2013

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

@zanchey zanchey reopened this Aug 15, 2013

@zanchey

This comment has been minimized.

Show comment
Hide comment
@zanchey

zanchey Aug 15, 2013

Member

Also needs completions updated.

Member

zanchey commented Aug 15, 2013

Also needs completions updated.

@zanchey zanchey closed this Oct 28, 2013

@jimeh jimeh referenced this issue Jan 14, 2015

Closed

Update init.fish #56

tchajed added a commit to tchajed/homebrew-core that referenced this issue May 10, 2016

autojump: Change . to source for fish shell
The . command has been deprecated and source is now preferred
(fish-shell/fish-shell#310).

MikeMcQuaid added a commit to Homebrew/homebrew-core that referenced this issue May 10, 2016

autojump: change . to source for fish shell.
The . command has been deprecated and source is now preferred
(fish-shell/fish-shell#310).

yyuu added a commit to pyenv/pyenv-virtualenv that referenced this issue May 30, 2016

simnalamburt added a commit to simnalamburt/.dotfiles that referenced this issue Oct 28, 2016

Support fish 2.0.0
Even though the usage of the `.` is deprecated in favour of `source`,
there is no other way to support fish 2.0.0 without it.

See also:
  fish-shell/fish-shell#310
  fish-shell/fish-shell@edc4614
  http://fish.sh/docs/current/commands.html#source-description

daenney added a commit to daenney/rbenv that referenced this issue Jan 1, 2018

Change . to source
Same issue as daenney/pyenv#10. Fish 3.x is removing the `.` function/alias, only `source` remains.

Relates to fish-shell/fish-shell#310
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment