[pulsar-next] pulsar-next command on Windows doesn't set the right ATOM_HOME

[savetheclocktower]

Thanks in advance for your bug report!

• Have you reproduced issue in safe mode?
• Have you used the debugging guide to try to resolve the issue?
• Have you checked our FAQs to make sure your question isn't answered there?
• Have you checked to make sure your issue does not already exist?
• Have you checked you are on the latest release of Pulsar?

What happened?

Not sure why yet, but (after a recent bug fix that prevented the app from launching at all) running pulsar-next doesn't set ATOM_HOME correctly.

The idea is that ATOM_HOME should be resolved first by explicit environment variable (so the user can override it), then by defaulting to the home directory on a particular OS plus either pulsar or pulsar-next, depending on the release channel. So either a variable isn't getting set by pulsar-next.cmd or it's not getting properly inherited by the shell.

By contrast, launching PulsarNext from the GUI seems to set the correct ATOM_HOME.

Pulsar version

PulsarNext 1.124.0

Which OS does this happen on?

🪟 Windows

OS details

(any)

Which CPU architecture are you running this on?

None

What steps are needed to reproduce this?

1. Manually set the correct PATH entry for pulsar-next [installation-location]\resources
2. Open a new shell
3. Run pulsar-next
4. Check your ATOM_HOME via one of several approaches: atom.configDirPath in a dev tools console, or open Settings and then click on the “Open Config Folder” button in the sidebar
5. Observe how it's pointing to your .pulsar folder instead of your .pulsar-next folder

Additional Information:

No response

[savetheclocktower]

Looking back through my commits on the PulsarNext branch, I see that d9ef212 was supposed to simplify all of this by using the version number as the source of truth: on PulsarNext builds it should end in -next, and that should trigger the logic that chooses .pulsar-next instead of .pulsar for ATOM_HOME.

So either this logic is somehow not “sticking” on Windows, or (more likely, IMO) some other piece of machinery is setting a default ATOM_HOME on Windows before this code acts (which would explain why overriding ATOM_HOME still works fine).