[nerdponx]

There are good reasons to use Zsh beyond its autocomplete system. Zsh parameter expansions are a beautiful thing. When I write CLI scripts, I don't write Bash scripts, I write Zsh scripts.

Documentation, however, is lacking. It's not quite as bad as Vim, but there are massive swaths of the program, entire subsystems, that are more or less completely undocumented. It's very user unfriendly.

Also, the ad-hoc "plugin" ecosystem is in a strange and fragmented state. It's a shame that more people don't write actual modules in C (yes, Zsh has a native module system), but then again, is the API even documented?

The thing about Fish vs Zsh is that Zsh, with all those pre-command hooks running in Zsh scripts to replicate out-of-the-box Fish functionality, it's slow. I haven't tried compiling my plugin files (yes, Zsh also has a byte compiler), so maybe that would help. But I've occasionally found myself poring over logs from zsh -x to see diagose my 200ms delay.

One more thing about Zsh: it has emacs syndrome. Do your really need an FTP client and calendar built into your shell?

[oblio]

I've been using zsh for a long time and I didn't know it had native plugins, a bytecode compiler, an FTP client and a calendar.

To be frank, that's kind of scary, I'll probably have to take another look at fish :)

[jandrese]

Zsh was undocumented in Ubuntu 14 because a bug in the package prevented the manuals from being installed and due to the way Canonical handles packages it was never fixed for the entirety of Ubuntu 14.

I am one of those few remaining Zsh users that doesn't have an 200MB baggage train on my shell though. I have a modest (2kb) .zshrc/.zshenv and for the most part just use the builtins.

[okdana]

> There are good reasons to use Zsh beyond its autocomplete system...

zsh also performs much better in practice than bash. Not only does it run the same code faster, it subsumes a great deal of functionality that normally requires external utility calls (which are very slow) into the shell itself.

For example:

* zsh has native floating-point arithmetic, so no need for `awk` or whatever. It can even format (digit-group) the numbers

* Regular-expression matching with =~ can be replaced by extended globs (which offer similar functionality but are significantly faster in most cases)

* `basename`, `dirname`, `readlink -m`, and `readlink -f` can be replaced by parameter-expansion modifiers

* `sort` can be replaced by parameter-expansion flags

* `grep` can be replaced by parameter-expansion flags and extended globs

* `find` (including its `-type` and `-exec` features) can be replaced by globs

* `date` can be replaced by prompt expansion or the `zsh/datetime` module

* `cp`, `mkdir`, `rm`, and so on can be replaced by the `zsh/files` module

* `stat` can be replaced by the `zsh/stat` module

* `column` can be replaced by `print -c` or `print -C`

> there are massive swaths of the program, entire subsystems, that are more or less completely undocumented

Like what? I'm not sure i'd noticed that myself. Sometimes the documentation is vague, maybe hard to find (e.g., the completion system's documentation is a bit overwhelming), but it's always been there when i went looking for it.

> Also, the ad-hoc "plugin" ecosystem is in a strange and fragmented state.

The plug-in ecosystem (i assume you mean OMZ, zplug, and stuff like that) is entirely unofficial and most of the zsh developers don't seem to care for any of it because it tends to be slow, error-prone, and often just unnecessary. It's also a major support burden for the people on IRC and in the mailing list, which doesn't endear them to it. Might be cool to have something official though.

> It's a shame that more people don't write actual modules in C (yes, Zsh has a native module system), but then again, is the API even documented?

I don't think it is, there's just an example module you can build. bash also supports loadable modules and it's the same way AFAIK.

> One more thing about Zsh: it has emacs syndrome. Do your really need an FTP client and calendar built into your shell?

Most of the weird stuff like the FTP client and calendar and Tetris game are optional modules or even just regular shell scripts. None of them are enabled by default and packagers can omit them (and they often do, especially with static builds).

[nerdponx]

> zsh also performs much better in practice than bash. Not only does it run the same code faster, it subsumes a great deal of functionality that normally requires external utility calls (which are very slow) into the shell itself.

For the uninitiated: Zsh parameters expansions and globbing (called "filename generation" in the docs) are beautiful. As I said above, I don't write Bash scripts, I write Zsh scripts, and this kind of thing is why:

    % cd /tmp
    % mkdir example
    % cd example
    % touch foo
    % touch bar
    % mkdir "my documents"
    % touch "my documents/baz"

    % tree -N
    .
    ├── bar
    ├── foo
    └── my documents
        └── baz

    1 directory, 3 files

    % for f in **/*(.);
    >   do echo File ${f:t} lives in ${f:A:h}
    > done
    File bar lives in /tmp/example
    File foo lives in /tmp/example
    File baz lives in /tmp/example/my documents

> Like what? I'm not sure i'd noticed that myself. Sometimes the documentation is vague, maybe hard to find (e.g., the completion system's documentation is a bit overwhelming), but it's always been there when i went looking for it.

Fair enough. Although IMO "vague and disorganized" is just as good as "nonexistent". Just try reading the docs for `autoload`/`typeset`/`local`, or `zstyle` [0], or `zmodload`. The whole thing badly needs to be tagged and reverse-indexed by functionality ("how do I accomplish X"), not by flag ("what does foo -q mean?"). I wrote a long comment about this kind of documentation recently [1].

> The plug-in ecosystem (i assume you mean OMZ, zplug, and stuff like that) is entirely unofficial and most of the zsh developers don't seem to care for any of it because it tends to be slow, error-prone, and often just unnecessary. It's also a major support burden for the people on IRC and in the mailing list, which doesn't endear them to it. Might be cool to have something official though.

Yes, this. It seems like everyone and their mother at one point decided to try to write a "package manager" for Zsh.

But I think the problem with these unofficial plugins is mainly that sourcing thousands of lines of shell script on every terminal load, and running potentially dozens of functions before every command, is just plain slow. Zsh might be faster than Bash, but it's still really really slow. Just looping over 1..1000000 takes well over a second in Zsh, but less than 1/2 second in Python (which is already considered a slow language).

What I haven't tried is zcompile-ing all my startup scripts. Would that help?

And of course, actually documenting the C API and build process would be a good first step for the maintainers and devs. The example module is easy enough to follow, but actually writing a module is another matter entirely. This is especially frustrating because AFAICT Zsh builtins are themselves implemented as a statically-linked module called "zsh/main", so it must be a powerful system.

[0]: https://unix.stackexchange.com/q/214657

[1]: https://news.ycombinator.com/item?id=15479273