Skip to content
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

Cannot set _ alias #8342

Closed
r67018 opened this issue Oct 11, 2021 · 7 comments
Closed

Cannot set _ alias #8342

r67018 opened this issue Oct 11, 2021 · 7 comments
Assignees
Milestone

Comments

@r67018
Copy link

r67018 commented Oct 11, 2021

In fish, _ is defined as a function.
So when you set the alias, commands such as "type" don't work properly.

e. g.

$ alias _=ls
$ type ls
ls: cannot access '%s is a function': No such file or directory
lsls: cannot access ' with definition': No such file or directory

# Defined in /usr/share/fish/functions/ls.fish @ line 13
function ls --description 'List contents of directory'
    set -l opt --color=auto
            isatty stdout
            and set -a opt -F
            command ls $opt $argv
end

Is there a workaround for this?

$ fish --version
fish, version 3.1.0
$ uname -a
Linux sleepcat 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ echo $TERM
screen-256color
@floam floam self-assigned this Oct 11, 2021
@floam floam added this to the fish 3.4.0 milestone Oct 11, 2021
@floam floam added the bug Something that's not working as intended label Oct 11, 2021
@floam
Copy link
Member

floam commented Oct 11, 2021

In fish, _ is defined as a function.

Well, it's actually a builtin. The problem is it is used everywhere and a function overwriting it is pretty problematic. We have a mechanism to reserve some function names. _ should fit.

@faho
Copy link
Member

faho commented Oct 11, 2021

Well, it's actually a builtin.

It's a builtin since 3.2.0 - #7036. type is one as well since #7342, so this won't be happening with that anymore.

I'd call this an enhancement, if there's anything to do at all - if you override _, you'll cause things to call that, so you simply shouldn't do that (unless it's e.g. to make it a no-op!).

It's the old problem that things have names that mean things. If you call something rm it should remove files. If you call something _ it should translate, or at least print the string.

@floam floam closed this as completed in 1726012 Oct 11, 2021
@faho faho added enhancement and removed bug Something that's not working as intended labels Oct 11, 2021
@floam
Copy link
Member

floam commented Oct 11, 2021

Well, I decided to reserve it. I guess my thinking was that like test, people may assume _ is a safe throwaway thing or a short convenient alias they may want to use without realizing it actually has meaning. Unlike rm, nobody really knows about _.

@floam
Copy link
Member

floam commented Oct 11, 2021

And right call on the enhancement label. Oops.

@faho
Copy link
Member

faho commented Oct 11, 2021

Well, I decided to reserve it. I guess my thinking was that like test, people may assume _ is a safe throwaway thing

That's okay. I guess you could override it to disable translations, but the $LC_MESSAGES is probably the right avenue for that (or rebuild fish and disable gettext).

@floam
Copy link
Member

floam commented Oct 11, 2021

Okay cool. Having been AWOL 2020, I actually was caught by surprise (pleasantly) @faho had promoted this to a builtin, but I had long wondered why the heck it wasn't prior. It'd have made sense to reserve it since introducing it, but really before it was a builtin we couldn't even prevent overriding at all. We can only do that now because of that change.

I wonder how we'd have approached this issue a few years ago?

Perhaps defining any function that exists on-disk, if done "manually" while interactive, ought to give some friendly output indicating an autoloaded function has been successfully overwritten?

@faho
Copy link
Member

faho commented Oct 11, 2021

I had long wondered why the heck it wasn't prior

It was part of fish's minimalist bent - we used to have that "Law Of Minimalism" that forbade anything from being a builtin if it could be a command. This even included echo, which would then add milliseconds of delay to any time you wanted to print a string.

I wonder how we'd have approached this issue a few years ago?

Probably not at all - "if it hurts, don't do that". Which I would still find acceptable - you could also override e.g. rm to do cp instead, and it would break a bunch of scripts. So that's a bad idea, and I would recommend against it.

The reason we made builtin names reserved was, for the most part, because they can't be overridden without breaking functionality - set can't be a function because that breaks set -l (and since it imports variables, string also can't be overridden anymore).

We did it for test because people tried to call test runners and stuff that, so it was a common issue. For _ it technically can be safely overridden (like I said, make it printf %s $argv), but because the name isn't all that well-known and there's little use in overriding it (what else are you gonna do except make it a no-op?) it's okay to reserve it as well.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 17, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants