Aliases with functions in .zshrc not working

I am writing from a fresh install of Manjaro sway.
It appears that the aliases defined in the file /usr/share/zsh/manjaro-zsh-config (lines 58-61) are somehow broken.

Example when I type cp:

> cp
zsh: defining function based on alias `f'
zsh: parse error near `()'

Is there a way to fix this?

Looks more like some function somewhere is broken. Are you sure it’s a fresh install, without a single change on your side?

If you suspect that something causes something else, then you can test it yourself. In this case commenting out those aliases. But as I said, this probably won’t make any difference, since problem is somewhere else.

What’s in your .zshrc?


Also show:

print -l ${(ok)functions[(I)[^_]*]} 
1 Like

Could you post the exact lines you mentioned?
The alias definition im using at moment is:

alias cp='f(){fo=${1:--i}; shift; cp $fo $*};f'

I’m sorry, it was my mistake.
After double-checking everything I found out that I had defined my own alias for f which conflicted with the alias definitions from manjaro-zsh-config.

Is it not possible to have my own alias for f, as it is not really used by manjaro-zsh-config? I don’t understand everything what these lines are exactly doing. @TriMoon these are the lines in my file:

## Alias section 
alias cp='f(){fo=${1:--i}; shift; cp $fo $*};f'                                           # Confirm before overwriting something
alias df='f(){if test $# -eq 0;then opts=(-h);else opts=("$@");fi; df "$opts[@]"};f'      # Human-readable sizes
alias free='f(){if test $# -eq 0;then opts=(-m);else opts=("$@");fi; free "$opts[@]"};f'  # Show sizes in MB
alias gitu='git add . && git commit && git push'

I’m glad you found your own error :wink:

It should be ok if you define yours after the imported ones from manjaro-zsh-config, because it shouldn’t be used in those definitions then i guess…
If they still clash, just rename your f to f1 or something :woman_shrugging:

Unless you know a way to use anonymous function definition and use at same time in one line in shell-script, like they do in javascript, which i don’t know of

The problem seems to be because of the zsh-syntax-highlighting plugin which is installed and active by default in my installation.

In the file /usr/share/zsh/plugins/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh on line 443 it somehow redefines all previously defined aliases by doing this:

eval "$zsh_highlight__aliases"

When I define my own alias for f in .zshrc it will somehow interfere in a bad way with what this plugin is doing. This is all I can investigate with my linux knowledge.

I’m using the defaults also and i don’t have any problems, maybe because i don’t create my own f() anywhere as a standalone function :woman_shrugging:

The solution can only be found when you post your actual .zshrc then i guess :woman_shrugging:

Please rename the topic title, because it is not the manjaro-zsh-config that is broken but more your definition in .zshrc as it seems…
(Otherwise that file would be broken for everyone)

FYI: I still had the definitions for the modified cp/df/free in my .zshrc because i hadn’t noticed the changes were already present in the updated package, so i removed them again in mine. Thx for reminding me :+1: :wink:

I don’t understand why are you two putting a function into an aliases. Just define it as a function.

Because the way i did it, which i found on stack-exchange or similar, is only an inline function that only persists for the duration of that alias…
Hence why i can re-define the same function in another alias…

Defining a function outside an alias would make it a global function, which would need different logic per caller of it.

What different logic? It works the same way. It makes zero sense to me to put one thing into another, but hey, it’s free world. :stuck_out_tongue:

[I changed OP’s title]

The logic inside the function, which changes per alias :wink:


Name them properly then:

df() {
    if test $# -eq 0; then
    /usr/bin/df "$opts[@]"

Or for more complicated things, create a bash script and put it in .local/bin.
Looks more sane to me at least, instead of abusing aliases.

May i remind you that this was done in /usr/share/zsh/manjaro-zsh-config which defined the default aliases i “fixed” with my MR?

Sure the maintainers of that package could use a function definitions instead of those aliases they use now, but then it wouldn’t be an alias anymore.
(Which undoubtedly would render them unfit for that file)

Feel free to improve it even more (that way) like i did with a MR :wink:

To get back to the topic again:


I’m just speaking in general, my opinion. Also when I check that file I don’t see any hacky aliases defined.

If you are used to sit on a table and then buy a chair, sure, that chair isn’t a table. But does it need to be? :smiley:

Eh, like shells care where you put stuff. :smiley: If you want to neatly organize things, then you should put aliases into its own file.

I totally agree with that, but i’m just a user like all of us…

In my .zshrc when I have this line:

alias f='find'

it will lead to the issues described above.
But for now it is fine for me to not have this alias, I will use others instead.

Yes. Probably because in previous aliases, with hacky functions inside, you are defining function “f” and then running it at the end. But in reality when zsh tries to run that last “f” it first looks into aliases that have precedence before functions where it finds a match.

Anyway, it’s not exactly like that, since it already errors at function definition, but I’m just thinking loudly how things can go quickly south.

If you have to use functions inside aliases why not do something like this then:

alias df='(){if test $# -eq 0;then opts=(-h);else opts=("$@");fi; df "$opts[@]"}'
1 Like

Does that work?
I never tried that way, but it is ofcourse better to use anonymous functions ala Javascript if zsh allows stuff like that.

Try it out and if it work, please create a MR to fix the way “i tried to fix it”, we’re all humans and users of each others codes :wink:
The solution i used worked for my use-case, and i never thought about the possibility of the problem mentioned here could even happen :smiling_face:

PS: As said i found my solution via the internet on a site like stack-exchange, where they discussed things like this.

Looks like it.

I’m not registered, so feel free to upgrade your code yourself. :smiley:

I would need to make time and test with the ones i use, before i do that, plus i don’t like to take credit for other peoples work :wink:

Its free to create an account there, and fork the repo tobe able to create a MR with your changes…
Don’t be shy :smiley_cat:

That change was also my first and only contribution to that file/package…