os.editAtLineAndWait doesn't handle quotes correctly

[ahmetsait]

Describe the bug

editAtLine: '"C:\Program Files\Notepad++\notepad++.exe" -n{{line}} {{filename}}'

works, but

editAtLineAndWait: '"C:\Program Files\Notepad++\notepad++.exe" -multiInst -nosession -noPlugin -n{{line}} {{filename}}'

fails with 'C:\Program' is not recognized as an internal or external command, operable program or batch file.

To Reproduce

Steps to reproduce the behavior:

1. Use the following editor commands:

   # %LOCALAPPDATA%\lazygit\config.yml
   os:
     edit: '"C:\Program Files\Notepad++\notepad++.exe" {{filename}}'
     editAtLine: '"C:\Program Files\Notepad++\notepad++.exe" -n{{line}} {{filename}}'
     editAtLineAndWait: '"C:\Program Files\Notepad++\notepad++.exe" -multiInst -nosession -noPlugin -n{{line}} {{filename}}'

2. Try to trigger "edit" by pressing e on a file.
3. Try to trigger "editAtLine" by pressing e inside patch panel.
4. Observe that both of these work without issues.
5. Try to trigger "editAtLineAndWait" by pressing upper-case E (edit hunk) inside patch panel.
6. Observe the failure to launch the editor.

Expected behavior

editAtLineAndWait should work the same way as editAtLine and properly launch Notepad++.

Version info:

commit=d167063b4f45d044524f3fba97f850d1eec3f95c, build date=2026-04-13T20:06:40Z, build source=binaryRelease, version=0.61.1, os=windows, arch=amd64, git version=2.54.0.windows.1

Terminal info:

Windows Terminal, Version: 1.24.10921.0

Additional context

What I've tried to make it work so far:

editAtLineAndWait: 'C:\\Program\ Files\\Notepad++\\notepad++.exe -multiInst -nosession -noPlugin -n{{line}} {{filename}}'
editAtLineAndWait: 'C:\Program^ Files\Notepad++\notepad++.exe -multiInst -nosession -noPlugin -n{{line}} {{filename}}'
editAtLineAndWait: 'C:\Program" "Files\Notepad++\notepad++.exe -multiInst -nosession -noPlugin -n{{line}} {{filename}}'
editAtLineAndWait: '\"C:\\Program Files\\Notepad++\\notepad++.exe\" -multiInst -nosession -noPlugin -n{{line}} {{filename}}'
editAtLineAndWait: '\"C:\\Program\ Files\\Notepad++\\notepad++.exe\" -multiInst -nosession -noPlugin -n{{line}} {{filename}}'
editAtLineAndWait: '\"C:\Program Files\Notepad++\notepad++.exe\" -multiInst -nosession -noPlugin -n{{line}} {{filename}}'
editAtLineAndWait: '''C:\Program Files\Notepad++\notepad++.exe'' -multiInst -nosession -noPlugin -n{{line}} {{filename}}'

All failing the exact same way.

---

---

I believe a better way to implement command configs is to make them arrays instead. This would allow lazygit to handle quotes correctly for all platforms/shells and remove any guess-work for the user.

editAtLineAndWait: ['C:\Program Files\Notepad++\notepad++.exe', '-multiInst', '-nosession', '-noPlugin', '-n{{line}}', '{{filename}}']

I don't know how easy it is to allow both arrays and strings for the same key.

[stefanhaller]

I'm very surprised that edit and editAtLine work for you, but only editAtLineAndWait fails. For me they all fail in the same way, and I can't see any difference in the code that would explain why one works but not the other.

I don't immediately see an easy way to fix this or work around it (but I also don't have a lot of time to dig into it). I agree that it would be better to model these as arrays rather than quoted strings, and maybe I'll change that some day.

For now, my best recommendation is to add C:\Program Files\Notepad++ to your system PATH env var, and use just notepad++.exe in the config. I haven't tried it, but I guess it should work.

[ahmetsait]

I've tried this on a different Windows 10 machine and was able to repro my exact same results with both lazygit 0.57.0 and 0.61.1 there. I would be happy to help investigate if you or (any maintainer) finds the time.

[AntoineGS]

A quick hack that you can use on Windows is to use the following path instead:
C:\Progra~1\Notepad++\notepad++.exe
There are specific cases where this could fall on the wrong folder (like you create a C:\Prograame) but otherwise it should hold up.
Progra~2 would be Program Files (x86)

[AntoineGS]

@stefanhaller I did some research and was able to find a fix
It is based on info documented here and here, as it seems others have similar issues with Go.
Like you though all three cases were failing, so I am still unsure how it could have worked for 2/3 but in any case this resolves all three.
I had Claude write the tests so I still need to review and clean them up if you want a PR for this.

[stefanhaller]

I agree that it would be better to model these as arrays rather than quoted strings, and maybe I'll change that some day.

@ahmetsait I take that back actually. It is important that the command string is interpreted by a shell (or cmd.exe on Windows) so that things like pipes, output redirection, command substitution, globbing, and env var expansion work. Granted, none of these are likely to be needed for calling an editor, but they are very much needed in custom commands, and I think we should be consistent with how we call external commands across the app.

@AntoineGS I tried again, and I could now reproduce that editAtLineAndWait failed but the other two worked. Very weird. I think it might have something to do with the total number of quotes in the string or something (e.g. "C:\My editor.exe" {{filename}} and "C:\My editor.exe" "{{filename}}" might be different). I stopped investigating this more because I don't have much time right now.

I think adding /s is the right move to solve this. I tried your branch and it worked for me, so that's nice; didn't look at the code much yet. Just for fun I asked Claude to fix this too, and this resulted in the fix-windows-cmd-quoting branch (I didn't look at its code, either). I noticed that they seem to behave differently: for mine, the /s and the additional quotes show up in the Log panel, for yours they don't. I think I would prefer it if they did.

In my branch I added another commit that simplifies things and (I think) fixes use of && which was broken before; I think this should fix #2427 (didn't get a chance to try this yet).

Not sure yet how to proceed from here; I don't have much time today to continue, but in general I think I'd prefer to work on this myself rather than review yours. But any input is welcome.

[ahmetsait]

"C:\My editor.exe" {{filename}} and "C:\My editor.exe" "{{filename}}" is of course different. The former fails to find My editor.exe and the later fails to find {{filename}} if it contains spaces. At least that's how it behaves on my end.

Tbh, it is pretty obvious that commands in lazygit were not meant to be shell code because all the special characters are escaped according to the issue you've linked. With arrays, shells can still be called anytime the user wants:

editAtLineAndWait: ['bash', '-c', 'set -uo pipefail; base64 "$1" | sponge "$1"; kate -n "$1"', 'bash', '{{filename}}']

But if you still want to have built-in shell support then a string key can be treated as a "shell" command, and an array key can be treated as a "process" command. Or you can look at how vscode handles this.
The important thing to get right is to pass the command to shell verbatim so people can actually use shell constructs. (Although personally I haven't needed them.)

These are all suggestions of course, so please don't take it as some kind of entitled demand ^_^

[AntoineGS]

I agree that it would be better to model these as arrays rather than quoted strings, and maybe I'll change that some day.

@ahmetsait I take that back actually. It is important that the command string is interpreted by a shell (or cmd.exe on Windows) so that things like pipes, output redirection, command substitution, globbing, and env var expansion work. Granted, none of these are likely to be needed for calling an editor, but they are very much needed in custom commands, and I think we should be consistent with how we call external commands across the app.

@AntoineGS I tried again, and I could now reproduce that editAtLineAndWait failed but the other two worked. Very weird. I think it might have something to do with the total number of quotes in the string or something (e.g. "C:\My editor.exe" {{filename}} and "C:\My editor.exe" "{{filename}}" might be different). I stopped investigating this more because I don't have much time right now.

I think adding /s is the right move to solve this. I tried your branch and it worked for me, so that's nice; didn't look at the code much yet. Just for fun I asked Claude to fix this too, and this resulted in the fix-windows-cmd-quoting branch (I didn't look at its code, either). I noticed that they seem to behave differently: for mine, the /s and the additional quotes show up in the Log panel, for yours they don't. I think I would prefer it if they did.

In my branch I added another commit that simplifies things and (I think) fixes use of && which was broken before; I think this should fix #2427 (didn't get a chance to try this yet).

Not sure yet how to proceed from here; I don't have much time today to continue, but in general I think I'd prefer to work on this myself rather than review yours. But any input is welcome.

No problem at all! I'll leave the branch for a while if ever you end up wanting to take something from it, but I agree that seeing the actual command run is a much better UX.