Ubuntu snap install of zig fails to format

[rippy]

When I try to save my Zig files and have code auto formatted, it fails. My workaround at the moment is to not use the 'snap' version of Zig.

Whenever I save Zig code, this error output is generated and the file is not formatted.

Error: Command failed: /snap/bin/zig fmt --stdin

My setup:

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS"

$ /snap/bin/zig version
0.5.0+5aa281250

$ cat .vscode/settings.json 
{
    "zig.zigPath": "/snap/bin/zig"
}

If I download Zig and run it from my home directory, it works as expected (and this is my workaround):

$ ~/bin/zig version
0.5.0+5aa281250

$ cat .vscode/settings.json 
{
    "zig.zigPath": "/home/rippy/bin/zig"
}

[lithdew]

I took some time to debug the extension to find out why.

require("child_process).exec, which is what vscode-zig uses to run the fmt command, does not support evaluating symlinks which /snap/bin/zig is in this case.

I tried to find a way to evaluate symlinks and couldn't find a proper way to do it cleanly (in a single line of code).

As an alternative solution, for the time being, you can set "zig.zigPath" to /snap/zig/current/zig, which is not a symlink in this case, and still points to the latest binary version of zig you have on your PC.

[Swoogan]

I am not able to reproduce this issue. I have /snap/bin in my path and I don't have any issue when not setting the zig path in the extension settings. I also tried manually setting the path to the snap and still didn't get any errors.

It might be specific to a version of VSCode or Zig. I am using vscode 1.50.1 and zig 0.6.0. Also, I am using the git version of the extension, not the packaged one.

[samuelventura]

Same error for asdf installed zig on macos. Manually running zig fmt on the files from vscode integrated terminal works.

[Vexu]

I don't think this is caused by symlinks since I have zig.zigPath set to /home/vexu/bin/zig which is a symlink to my build directory and formatting works just fine for me.

[berkantsoytas]

I don't think this is caused by symlinks since I have zig.zigPath set to /home/vexu/bin/zig which is a symlink to my build directory and formatting works just fine for me.

Did you download it with the package manager or did you compile it yourself?

[zbynekwinkler]

There is an option to use zls for formatting, which actually works.

[Vexu]

I was not able to reproduce this by installing snap and Zig with it. Closing unless someone can confirm that this is still an issue.

[sacsbrainz]

i just face same issues now

[sacsbrainz]

firstly i install zig from snap stable branch then i installed zig vscode plugin the i tried to run my first zig file as i saved it the zig extension said it could not find zig installed on my pc so i click install zig, then i close my vscode because it was taking too much time then i reopened vs code and the same modal showed up, then i click i have zig already installed which is the last option, then it said i should install zls, which i clicked ok and it did then it said my zls version is ahead of my current zig version so i went and uninstall my zig version and reinstall it from snap store this time around i installed the beta which is 0.11.0-dev.3892+0a6cd257b, then i reopened vscode and while checking my output i saw the error and i started looking for solutions and i ended up here

[blubberdiblub]

I don't think this is caused by symlinks since I have zig.zigPath set to /home/vexu/bin/zig which is a symlink to my build directory and formatting works just fine for me.

Well, I don't think the problem comes from using a symlink in and of itself. However, it may very well come from what the symlink target actually is.

When using zig installed from snap utilizing the standard $PATH, it will be /snap/bin/zig, which is a snap alias. Snap aliases work by linking to the snap executable, which, when executed, notices that it was called with the name zig, looks up where the actual zig executable is depending on the activated zig snap and then execs that real zig, which to the user behaves as though they executed the real zig directly.

All this to say that in the case of snap installed zig, /snap/bin/zig is a symlink to /usr/bin/snap and not to the real zig executable itself, which possibly throws the extension off track?

[Vexu]

That still wouldn't explain the issue assuming that running /snap/bin/zig fmt file.zig from a terminal works and because I was unable to reproduce it by installing snap on my system.

[blubberdiblub]

Alright, new guess, it might be due to apparmor (or its configuration as it pertains to snaps), which would mean the problem wouldn't show up on a system without apparmor (or with a better apparmor configuration regarding snaps).

And yeah, I can confirm that both /snap/bin/zig fmt file.zig as well as /snap/bin/zig fmt --stdin < file.zig from a terminal work fine.

Anyway, here's the final part (starting from the last execve()) of a strace log of the failed attempt to execute /snap/bin/zig fmt from within vscode (I removed mmap()/munmap() calls, as they just clutter the output):

execve("/snap/zig/10089/zig", ["/snap/zig/10089/zig", "fmt", "--stdin"], 0xc000047800 /* 125 vars */) = 0
arch_prctl(ARCH_SET_FS, 0x7a50cc7dd228) = 0
set_tid_address(0xa643584)              = 120969
gettid()                                = 120969
gettid()                                = 120969
brk(NULL)                               = 0xc0f5000
brk(0xc0f7000)                          = 0xc0f7000
gettid()                                = 120969
gettid()                                = 120969
gettid()                                = 120969
lseek(2, 0, SEEK_CUR)                   = 0
fstat(2, {st_mode=S_IFCHR|0666, st_rdev=makedev(0x1, 0x3), ...}) = 0
brk(0xc0f8000)                          = 0xc0f8000
gettid()                                = 120969
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
prlimit64(0, RLIMIT_STACK, {rlim_cur=32768*1024, rlim_max=RLIM64_INFINITY}, NULL) = 0
rt_sigprocmask(SIG_UNBLOCK, [RT_1 RT_2], NULL, 8) = 0
rt_sigaction(SIGPIPE, {sa_handler=0xa095450, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x9479a6d}, NULL, 8) = 0
read(0, 0x7a50cc7d7550, 5250)           = -1 EACCES (Permission denied)
write(2, "error: unable to read stdin: ", 29) = -1 EACCES (Permission denied)
exit_group(1)                           = ?
+++ exited with 1 +++

Which is what gave me the idea that it might be apparmor at work: Both the read() of stdin and the subsequent attempt to write() the error message to stderr fail with EACCES, which to me makes no sense unless I take something (e.g. apparmor) into account that somehow restricts access.

Unfortunately, I'm not proficient with apparmor, so I have no idea how to investigate further or how to read and understand the apparmor configuration (the config file pertaining to snaps is a humongous jumble of stuff that goes over my head).