__DOOMSTEP envvar missing

[JP-Ellis]

What did you expect to happen?

For various bin/doom commands to not exit with failure

What actually happened?

A lot of bin/doom commands fail with the following error message:

x There was an unexpected runtime error
  Message: __DOOMSTEP envvar missing; extended `exit!' functionality will not work
  Backtrace:
    (error "__DOOMSTEP envvar missing; extended `exit!' functionality will n...
    (progn (error "__DOOMSTEP envvar missing; extended `exit!' functionality...
    (if (= (progn (or (progn (and (memq (type-of context) cl-struct-doom-cli...
    (doom-cli--restart "less -r +g <\"c:/Users/$USER/tmp2/.emacs.d/.local/...
    (let ((tmpfile (doom-cli--output-file 'output context)) (coding-system-f...
    (cond ((null (or pager (executable-find "less"))) (user-error "No pager ...
    (let ((pager (or doom-cli-pager (getenv "DOOMPAGER")))) (cond ((null (or...
    (doom-cli--exit-pager nil #s(doom-cli-context (25318 11097 950752 0) 221...
    (funcall doom-cli--exit-pager nil #s(doom-cli-context (25318 11097 95075...
    (if fn (funcall fn args context) (error "Invalid exit command: %s" comma...
    (let* ((fn (and t (alist-get command doom-cli-exit-commands)))) (if fn (...
    (let nil (let* ((fn (and t (alist-get command doom-cli-exit-commands))))...

Describe your attempts to resolve the issue

I created a fresh new installation, and the error can be reproduced without needing to install any doom package. I initially thought it was related to having a literate config as the above error prevented doom sync from working; but my attempts to make a minimal example (below) show that it happens even before even running doom install.

Steps to reproduce

1. Create a new directory, set HOME to it.
2. git clone https://github.com/doomemacs/doomemacs.git $HOME/.emacs.d
3. cd $HOME/.emacs.d/
4. bin/doom help
   and I get the above error.

I have tried also using bin/doom.cmd instead of bin/doom as this is on Windows, but the error is still there.

Defining a new environment variable __DOOMSTEP (to any value) seems to offer a temporary fix.

System Information

bin/doom info

generated  Jul 31, 2022 17:19:28
system     Windows Unknown
emacs      28.1 ~/.emacs.d/ -> ~/.emacs.d/
doom       3.0.0-dev HEAD -> master, origin/master, origin/HEAD 615848e3a
           2022-07-31 00:58:36 +0200 ~/.doom.d/ -> ~/.doom.d/
shell      C:/Users/$USER/scoop/apps/emacs/current/libexec/emacs/28.1/x86_64-w64-mingw32/cmdproxy.exe
features   ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES
           NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF
           TOOLKIT_SCROLL_BARS XPM ZLIB
traits     batch
modules    n/a

Emacs with installed with scoop install emacs on Windows.

[hlissner]

This appears to be a windows issue. How are you running bin/doom? In cmd.exe? In Git Bash? Cygwin? A native shell under WSL1/2?

The doom script requires a POSIX shell, so either it's not being launched in one, or I've erroneously assumed that the arithmetic syntax I use to initialize __DOOMSTEP isn't POSIX-complaint.

[JP-Ellis]

This is indeed on Windows, the standard Scoop installation which is running natively within Windows (no Git Bash, Cygwin or WSL).

I've tried launching bin/doom from the following shells, and all have produced the same error:

• Nushell
• Powershell 7.2.5
• Powershell 5.1.19041.1682
• Command Prompt 10.0.19044.1826

I'm thinking that it doesn't really matter what shell I'm calling bin/doom from, since I think that bin/doom automatically reverts to bin/doom.cmd (based on the PATHEXT environment variable defined on Windows), and this then invokes the bin/doom script using Emacs.

I tried adding some simple echo statements to the top of the bin/doom script, but they don't seem to get printed at all.

[hlissner]

• Nushell
• Powershell 7.2.5
• Powershell 5.1.19041.1682
• Command Prompt 10.0.19044.1826

None of these are POSIX shells. Are you able to install Git bash and try it there instead?

since I think that bin/doom automatically reverts to bin/doom.cmd (based on the PATHEXT environment variable defined on Windows), and this then invokes the bin/doom script using Emacs.

I could see that happening, yeah. What's more, doom.cmd hasn't been updated to reflect recent (major) changes to Doom's CLI (causing #6620), and I know too little about batch scripting to do so myself. Git bash may be unavoidable for the time being.

[JP-Ellis-KPMG]

I can confirm that using Git Bash works.

If/when I have time, I might have a look at see if I can get bin/doom.cmd to work, but looking at bin/doom, I doubt I could ever reach parity.

[azzamsa]

@hlissner should we set shell-file-name by default in doom. I set it to bash. Otherwise, many package didn't work well. Such projectile. Because I use Fish and Nushell. Both of them are not POSIX compliant.

;; Emacs doesn't play well with fish
(setq shell-file-name "/bin/bash")

[willcohen]

Trying to get doom running on SDF, a NetBSD shell server. When trying to run doom install, I get the following error:

$ ~/.emacs.d/bin/doom install
~/.emacs.d/bin/doom install
/sdf/arpa/tz/myhomedir/.emacs.d/bin/doom: arith: syntax error: "__DOOMSTEP+1"

While the default shell used here is ksh, it does seem like this should be using netbsd's sh per the env command invoking the script. @hlissner

[willcohen]

@azzamsa @JP-Ellis does the modified __DOOMSTEP syntax from #6970 work for you all? I can confirm that it does work for netbsd, which seems to have a similar error.

[hlissner]

I'm hoping 0ecf69a addresses OP's issue. @JP-Ellis Can you confirm?

[JP-Ellis]

I have been working around this issue by using Git Bash which works fine.

I have just tried it (commit history includes both db2534a and 0ecf69a) and unfortunately doom sync still produces the same error in both NuShell and Powershell.

While I don't necessarily expect NuShell to work perfectly given it is still quite new, it would be nice to have PowerShell working on Windows.

[padril]

I think the advice given in this issue (primarily to use git-bash should be in the getting started documentation.

I installed using Windows and Scoop, and it took me a long time to search the right thing to find these issues and get a successful install, but using git bash did the trick seamlessly.