syntax: zsh support

Congratz for the great tool!

Would be nice to have zsh support.

@d630

Zsh is a massively complex shell - even more so than Bash - so let me ask a few questions first.

Why? Is there much Zsh code in the wild? From what I can tell, Bash, POSIX Shell and mksh already cover pretty much everything.

Is there a language spec for Zsh? If there's none, is there a document that summarizes all the language features?

The bottom line is that I fear this would be an insane amount of work for little benefit. I never use Zsh, so there's also that - I have no personal incentive to do it.

Also /cc @d630 who suggested zsh alongside mksh (the last one I did, it wasn't much work on top of Bash/POSIX)

Also note that I would put Zsh in a similar spot as Fish. They're cooler, newer shells that - as far as I know - are popular as interactive shells. But not so much for scripts that you maintain over time. Those tend to be in Bash or POSIX Shell, since you want the scripts to run on as many systems as possible. This is the kind of shell code that shfmt is for.

Also note that I would put Zsh in a similar spot as Fish. They're cooler, newer shells that - as far as I know - are popular as interactive shells. But not so much for scripts that you maintain over time. Those tend to be in Bash or POSIX Shell, since you want the scripts to run on as many systems as possible. This is the kind of shell code that shfmt is for.

yeah, I agree.

hello, no disagreements here. but I saw a very similar response in the equally "dam this is useful" shellcheck repo (im coming from vscode). now, im no shell expert, but i always had the impression zsh was the #2 game in town. at least, anyone who seems to care about aesthetics is almost guaranteed to be on zsh. its actually a bit disappointing to learn that its not that important (i.e., major tools don't support it). and really, i guess thats more on zsh people (who could make a spec or a pull req or smth). anyhow, thats just for context. great package!

@incognitoRepo

@incognitoRepo please note my earlier point about interactive shells. zsh may be popular as an interactive shell, but this tool is for scripts and programs one maintains. Can anyone provide proof that zsh is popular as a scripting language too? I've personally never come across a script in it, but I might be biased.

That's just as far as utility goes; after that, we'd also have to consider how much work it would be. I probably wouldn't have the time to impement all of its syntax features, particularly since bash support isn't even complete yet :)

Remove zsh and fish keywords

As of macOS Catalina (the current version) it's the default shell for new user accounts. It may result in more requests. I agree it won't increase real-world usage though.

Is there a language spec for Zsh? If there's none, is there a document that summarizes all the language features?

There's a pretty hefty manual (PDF) that I mainly reference when I see a glob or expansion I'm not familiar with. I couldn't find any formal grammar at all.

Huh, interesting, I didn't know Mac had switched over. I'm not sure if that will result in people writing more zsh scripts, though.

Different people have pinged me about the macOS move in the past few weeks, so let's reopen this issue for now.

Pros:

Supporting sh, bash, and mksh, it feels like zsh is the next logical step by popularity
Being the default shell of new macOS versions should mean that macOS users would start writing more scripts in zsh instead of bash
zsh is pretty similar to bash/mksh, so syntax-wise, we should be able to reuse a good amount of code

Cons:

Like bash, zsh is a very complex shell. bash work started nearly three years ago, and even today I still find bugs or missing features in the syntax package.
Like bash and mksh, zsh does not have a formal language specification. This will make it harder to map out what language features we're missing.
Increase in complexity, which would hurt binary sizes, compile times, and my ability to maintain this project long-term.
It's unlikely I would ever have the time to write proper support for zsh in the interpreter package.

I'm honestly about 50/50 on this right now. Thoughts welcome; please keep it concise so that the thread doesn't derail.

I used to use zsh daily. (More and more now I use mvdan/sh/interp! :) I wrote some scripts in it, almost entirely for my own use. My workplace(s) for years have generally been bash shops, so anything I wanted to share, I felt like I had to either heavily comment / document it, or just translate to bash. (In fairness, that wasn't usually a huge burden, but it was usually non-zero, nevertheless.)

So I like zsh, don't get me wrong!

But I also agree that it's very large, and kind of ad-hoc. It does kind of feel like there's an underlying logic to it, but that can be hard to suss out / reverse engineer.

I think it'd be fair to say "zsh maintainer wanted", and maybe implement often-used, low-hanging fruit, as time, demand, and contributions allow. (I was going to mention ** as a feature in zsh I miss a lot in bash, but I checked the bash manual and it turns out bash can do that, so I guess the joke's on me there. :)

Have you considered inquiring on the zsh mailing lists for collaborators?

But I also agree that it's very large, and kind of ad-hoc.

The good news here is that I'm only considering parser and printer support, i.e. just the syntax. Zsh is different from Bash in lots of ways when it comes to running a script, but we don't care because I don't think it would ever be a good idea to add a "zsh mode" in the interpreter.

implement often-used, low-hanging fruit, as time, demand, and contributions allow.

This would definitely be a best-effort basis :) That's how we're doing Bash too. It would be insane to try to reach 100% syntax compatibility in a single release.

Have you considered inquiring on the zsh mailing lists for collaborators?

That's a good idea. I guess I can phrase it as an FYI, to see if there would be interest from any zsh developers or heavy users.

I keep using shfmt and shellcheck with my zsh files. Most of the differences are semantic rather than syntactic. Here's an obtuse yet idiomatic example that doesn't parse:

#                ┌ nesting
#                │  ┌ flags ┌ modifiers
#                ▼  ▼       ▼
export ZDOTDIR=${${(%):-%x}:P:h}
# ...globbing also has additions

I see three potential levels of support:

Encourage encapsulation of unparseable code in separate files. It hasn't been too inconvenient for personal scripts. I'd write larger scripts in a different language anyway.
Support some comment to skip parsing the next line.
Only support differences at the highest level. My example highlights all the additions to expansions. You could test against one of the frameworks for edge cases.

Land fork/kjanat work onto master (#1)

With v3.13.1 out and the amount of incoming zsh bug reports slowing down, I think we can call the initial zsh support done :) Please upvote or raise issues that affect you and I'll look at them. We probably won't get to 100% compatibility, but we never got there with Bash and in practice that's been fine.

@mvdan

@mvdan thank you so much! I've been using it successfully, and 3.13.1 is handling the trickiest things that were causing me problems in earlier versions.

Good to hear :) I should also mention that anyone benefitting from this work, especially companies, can sponsor me on GitHub as well. I recently added tiers with benefits, both for recurring and one-time contributions.

Thank you, thank you, thank you! I loved when this was added..

I never imagined I'd live to see zsh support completed; it's amazing!

Linking this as it's quite related:

40x+ speedup compared with shellcheck.

@HaleTom

I'm sorry @HaleTom, but how does that relate to this project or issue in any way?

Perhaps because it claims to be a formatter while as well supporting zsh.

Point the zsh note at the upstream zsh label

Update mvdan.cc/sh to v3.14.0 and make zsh formatting opt-out (#22)

feat: add native Rust source fences

docs: close Sprint 187 Rust runtime story

Navigation Menu

Repository navigation

syntax: zsh support #120

67 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

syntax: zsh support #120

Description

Activity

mvdan commented on Jun 8, 2017

mvdan commented on Jun 8, 2017

caarlos0 commented on Jun 8, 2017

incognitoRepo commented on May 19, 2019

mvdan commented on Aug 30, 2019

texastoland commented on Apr 24, 2020

mvdan commented on Apr 24, 2020

mvdan commented on May 7, 2020

theclapp commented on May 7, 2020

mvdan commented on May 7, 2020

texastoland commented on May 8, 2020

67 remaining items

mvdan commented on Jun 2, 2026

mdekstrand commented on Jun 3, 2026

mvdan commented on Jun 3, 2026

carhartl commented on Jun 3, 2026

ch3rub1m commented on Jun 7, 2026

HaleTom commented on Jun 22, 2026

mvdan commented on Jun 22, 2026

felipecrs commented on Jun 22, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions