Fails on Arch, looking for zsh version?

[thecatwasnot]

Broken as of at least last 2 updates. Zsh is currently version 5.9.

(14:21:04)(cole)(~)fastfetch
                  -`                     cole@pulsar
                 .o+`                    -----------
                `ooo/                    OS: Arch Linux x86_64
               `+oooo:                   Kernel: 5.19.13-arch1-1
              `+oooooo:                  Uptime: 22 hours, 24 mins
              -+oooooo+:                 Packages: 980 (pacman), 1 (flatpak)
fastfetch: /home/cole/.cache/paru/clone/fastfetch/src/fastfetch-1.7.4/src/util/FFstrbuf.c:299: ffStrbufPreviousIndexC: Assertion `start <= strbuf->length' failed.
zsh: IOT instruction (core dumped)  fastfetch

I

[CarterLi]

Did you have nested shell running?

For example bash / zsh / fastfetch?

[LinusDierheimer]

Can you please try the dev branch? If it works, i will cherry pick the commit to master and make a new release.

And to understand what went wrong, please post the output of zsh --version.

[CarterLi]

There is a case that fastfetch detects multiple shells.

For example a user runs zsh inside of bash. Because we was using ffStrbufAppendS, all shell info we detected was appended into shellProcessName. Then we got zshbash. This issue has been fixed in dev branch.

In addition, most terminalShell module logics depend on /proc/pid, which is Linux specific. All other platforms falls back to guessing.

[thecatwasnot]

I'm not in a subshell that I'm aware. Zsh is set as my system shell.

(19:54:42)(cole)(~)echo $SHLVL
1
(06:41:33)(cole)(~)zsh --version
zsh 5.9 (x86_64-pc-linux-gnu)

Dev branch works:

(06:45:39)(cole)(~/src/githu/fastf/build)./fastfetch
                  -`                     cole@pulsar
                 .o+`                    -----------
                `ooo/                    OS: Arch Linux x86_64
               `+oooo:                   Kernel: 5.19.13-arch1-1
              `+oooooo:                  Uptime: 1 day, 14 hours, 48 mins
              -+oooooo+:                 Packages: 980 (pacman), 1 (flatpak)
            `/:-:++oooo+:                Shell: zsh 5.9
           `/++++/+++++++:               Resolution 1: 2560x1080 @ 60Hz
          `/++++++++++++++:              Resolution 2: 1920x1080 @ 60Hz
         `/+++ooooooooooooo/`            Resolution 3: 1920x1080 @ 60Hz
        ./ooosssso++osssssso+`           WM: Sway (Wayland)
       .oossssso-````/ossssss+`          Cursor: capitaine (24px)
      -osssssso.      :ssssssso.         Terminal: foot
     :osssssss/        osssso+++.        CPU: AMD FX-8320 (8) @ 3.5 GHz
    /ossssssss/        +ssssooo/-        GPU: AMD Radeon HD 7700
  `/ossssso+/:-        -:/+osssso+-      Memory: 10.57 GiB / 31.32 GiB (33%)
 `+sso+:-`                 `.-/+oso:     Disk (/): 21.18 GiB / 29.36 GiB (72%)
`++:.                           `-/+/    Disk (/home): 53.45 GiB / 63.69 GiB (83%)
.`                                 `/    Locale: en_US.UTF-8

                                         ████████████████████████
                                         ████████████████████████
(06:47:05)(cole)(~/src/githu/fastf/build)./fastfetch --version
fastfetch 1.7.4-48

[LinusDierheimer]

In the ZSH version code, the following code path existed:

ffStrbufSubstrBeforeLastC(version, ' ')

void ffStrbufSubstrBeforeLastC(FFstrbuf* strbuf, char c)
{
    ffStrbufSubstrBefore(strbuf, ffStrbufLastIndexC(strbuf, c));
}

static inline FF_C_NODISCARD uint32_t ffStrbufLastIndexC(const FFstrbuf* strbuf, char c)
{
    return ffStrbufPreviousIndexC(strbuf, strbuf->length - 1, c);
}

uint32_t ffStrbufPreviousIndexC(const FFstrbuf* strbuf, uint32_t start, char c)
{
    assert(start <= strbuf->length);
    [...]
}

Which would fail with the mentioned assertion, if the version string is empty. I am pretty sure this is the code path we are hitting. That is why i updated ffStrbufLastIndexC to work with empty strings too. I have no idea why the version string is empty tho.

[LinusDierheimer]

zsh 5.9 (x86_64-pc-linux-gnu)

Hmm that is definitely not empty. But updating the method seems to fix the bug anyway, will release the commit soon.

[LinusDierheimer]

I have backported both fixes to 1.7.5, please try this commit just to be sure, and close this issue if it does work.

[thecatwasnot]

Good to go on 1.7.5 thank you!