alias broken on paths with spaces

[mqudsi]

mkdir "test dir"
echo -e "#!/bin/sh\necho hello world!" > "test dir/test"
alias test "test dir/test" #or alias test2 test\ dir/test
test2 #nothing is printed

Looking at the output of type test2 reveals the problem:

~> type test2
test2 is a function with definition
# Defined in - @ line 0
function test2 --description 'alias test2 test dir/test'
    test dir/test $argv

end

[faho]

Unfortunately, this is working as expected. Alias exists for compatibility with bash, and that's what bash does here.

This is so things like alias gc="git checkout" work.

We could obviously change it, but

• That breaks anything like the above. Which I'd assume is about 90% of aliases.

• It would require allowing something like alias gc git checkout, which currently isn't, so it's a hard break.

I'd assume you are hit more with this because you're on WSL. On unix, spaces in command paths are even rarer than vowels (they've even cut the trailing e in "create").

This is one more reason why I'm constantly telling people to just define the function instead.

[faho]

The workaround is to double-escape spaces. I.e.

alias test "test\ dir/test"

[mqudsi]

I presumed the workaround would work (without trying it though, tbh), but was wondering just what the actual semantics here are. Fish already hard breaks away from posix/bash compatibility when it comes to spaces and escaping everywhere else; I'm not sure preserving the compatibility with bash is the right thing to do here, IMHO.

There's an out, though. The official fish syntax is alias ALIAS ARG. Using the bash syntax alias ALIAS=ARG could trigger the existing mode, while not supplying the = could use the default fish argument expansion mode.

i.e.

alias gc="git checkout" would be parsed as a bash compatibility hack translated to alias gc git checkout, while alias git checkout would be translated to alias git checkout (no change there), but alias gc "git checkout" would end up calling a non-existent file named git checkout.

(and, yes, WSL is to blame here)

[mqudsi]

I should point out that my concern here isn't getting alias to work in this case or making it friendlier for WSL users, etc. but rather a function of design and principle as I feel it's in keeping with the fish manifesto for the same argument parsing behavior to be used for alias as elsewhere in the shell (i.e. list vs string variables).

[faho]

Fish already hard breaks away from posix/bash compatibility when it comes to spaces and escaping everywhere else; I'm not sure preserving the compatibility with bash is the right thing to do here, IMHO.

For a couple of functions, compatibility is explicitly the reason why they exist. This applies not just to alias, but also setenv and export. Now, the latter two are actually useful because of that (so you can do somecommand | source, maybe after explicitly enabling a csh-compatible mode), which doesn't quite apply to alias.

I think you might have noticed that I'm not a massive fan of alias. It's an awkward second way to define functions that confuses users. I wouldn't have added it to begin with. Even the bash man page says:

For almost every purpose, aliases are superseded by shell functions.

Anyway, we have it, and removing it is probably unreasonable.

The official fish syntax is alias ALIAS ARG

Note that that currently does not work, probably because of f156bea.

However, the syntax is stated in the documentation, so it should work, and since we haven't had any complaints about it not working, that probably means that nobody is using it. Which means we're probably not going to inconvenience anyone by changing it, but on the other hand, nobody'll use the improved version.

If you want to add it, feel free to do so.

[mqudsi]

Ah, I wouldn't have run into that issue. I normally use functions but will use aliases to literally provide an alias for a command, e.g. on Linux gmake is aliased to make and if I don't have neovim installed, nvim is aliased to vim and for shortcuts (pd for prevd and nd for nextd).

[faho]

This is probably not happening.

I recommend using functions instead of alias.

[floam]

For a couple of functions, compatibility is explicitly the reason why they exist. This applies not just to alias, but also setenv and export.

setenv and export are actually used to execute the output of commands that set up environments. alias is a little different, it's a handy utility function that can be used interactively, or in config files, which works as expected for those with familiarity with Bourne alias, but it can also be used by Fish users wanting a succinct way to create simple wrapper functions. (I'm one of them!). So we've extended it with more fishy supported syntax without =. I'll look into improving this.

[faho]

Okay, no, closing this again.

I don't think we want to break alias compatibility here, and the current semantics are arguably correct - you need to distinguish calling the test command with the argument dir from the test dir directory, and you do that via escaping or quoting.