ppm missing on Linux

[nwhetsell]

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?

NOTE: This is an issue about the action-pulsar-dependency GitHub action, not Pulsar itself. I checked the box for reproducing the issue in safe mode, but while Pulsar has a safe mode, GitHub actions do not.

At some point between Nov 24, 2025 and Dec 8, 2025, using action-pulsar-dependency on Linux began installing Pulsar such that ppm is not available after installation.

• https://github.com/nwhetsell/ide-csound/actions/runs/19643075041/job/56251463836#step:9:1 – Nov 24 run when ppm runs successfully, Pulsar 1.130.2025112201
• https://github.com/nwhetsell/language-rtf/actions/runs/20044825987/job/57488517982#step:6:1 – Dec 8 run where ppm isn’t found, Pulsar 1.130.2025120304

Pulsar version

1.130.2025120304

Which OS does this happen on?

🐧 Debian based (Linux Mint, Ubuntu, etc.)

OS details

Ubuntu 24.04.3

Which CPU architecture are you running this on?

None

What steps are needed to reproduce this?

Run a GitHub Actions job with these steps:

jobs:
  Test:
    runs-on: ubuntu-latest
    steps:
    - name: Check out repository
      uses: actions/checkout@v6

    - name: Install Pulsar dependencies on Linux
      run: sudo apt install -y libsecret-1-0

    - name: Install Pulsar on Linux
      uses: pulsar-edit/action-pulsar-dependency@v3

    - name: Install package dependencies
      run: ppm install

Additional Information:

No response

[confused-Techie]

Thanks a ton for reporting this! A quick check and this is rather strange. Between those dates there should be zero difference in the binary that was installed by this action, meaning I'd expect zero change in behavior.

Wondering if the more Linux experienced folks have any thoughts @DeeDeeG

[savetheclocktower]

Is the pulsar binary available? If so, then the quickest workaround is to change ppm to pulsar -p. If not, then that might hint at the underlying cause.

[nwhetsell]

Using pulsar -p fixes it:

https://github.com/nwhetsell/language-rtf/actions/runs/20077424627/job/57595399766#step:6:1

[savetheclocktower]

We do nothing special to set up ppm in this workflow. So if this broke, it's probably because the .deb file previously set up ppm and now doesn't, for whatever reason.

In other words: the effects are unlikely to be limited to action-pulsar-dependency. This is probably a new bug in Pulsar’s build process.

[DeeDeeG]

I'm thinking of throwing some echo spam in the postinstall script to try and debug what's going on. (Once I get a good opportune time to try this.)

[DeeDeeG]

Okay, I think there is a mixup in script/postinstall.sh of Pulsar core repo as of the Electron 30 PR (pulsar-edit/pulsar#1367).

See: https://github.com/pulsar-edit/pulsar/blame/c78a97c8ae6ad779a9f017d7c5030c71b43dadc1/script/post-install.sh

tl;dr: It seems we have to make successful use of some preprocessor syntax that exists, and outside of that, not attempt similar-looking shell parameter expansion (aka string interpolation) within single quotes, which won't work -- the preprocessor coincidentally appears to work regardless of single quotes or lack thereof. Shell scripts generally don't work that way on their own, however.

Hopefully I'll have a PR for this soon? If I can sort out the preprocessor vs parameter expansion... dueling / midly overloaded (similar-looking) syntaxes.

---

Details:

Normally, we don't get parameter expansion ("string interpolation") in Unix shell scripts within single quotes ''. For example, echo '${SOME_VAR}' just prints the literal text ${SOME_VAR}, dollar sign and brackets and all.

Furthermore, by convention, variables in shell scripts are often SCREAMING_SNAKE_CASE (all uppercase, words separated by underscores)...

The fact we have some working lowercase and/or camelCase variables in some parts of the postinstall scripts (at least "working" in a templating/preprocessing sense) is a hint to me that we are working across a partly non-shell-scripting context -- something is treating our postinstall.sh as a template and preprocessing it before it becomes part of the final .deb or .rpm output. Either the native deb or rpm machinery, or electron-builder is replacing, for example, ${sanitizedProductName}, even (or specifically??) within single quoted text, with Pulsar, and ${executable} with pulsar, respectively. (Aside: I don't know which thing is the preprocessor, and can't seem to find docs for it in electron-builder's docs, so... I'm just gonna guess the pattern of how to use this preprocessing and move on 😅.)

But later in the script, we attempt to use $executable without brackets. I surmise this is not preprocessed due to the lack of brackets. So it stays as $executable instead of reading pulsar or pulsar-next. (Since $executable is never set, it evaluates to the empty string.) So, setting shell variable ppm_executable in the case statement hits the catch-all default path, due to malformed input (unintentional empty string), and we get result ppm always, never ppm-next as intended for the pulsar-next code path.

Furthermore, we attempt our own non-preprocessor parameter expansion (string interpolation) within single quotes, which does not work, for the symlink target and destination. SYMLINK_TARGET='/opt/${sanitizedProductName}/resources/app/ppm/bin/${ppm_executable}' gets preprocessed to SYMLINK_TARGET='/opt/pulsar/resources/app/ppm/bin/${ppm_executable}', which evaluates to /opt/pulsar/resources/app/ppm/bin/${ppm_executable} (note the literal ${ppm_executable} is not expanded/interpolated).

We are creating a symlink at the path /usr/bin/${ppm_executable} pointing to target /opt/Pulsar/resources/app/ppm/bin/${ppm_executable}, special characters and all. The target, needless to say, is not a real file. And /usr/bin/ppm symlink is never made, only the oddly named /usr/bin/${ppm_executable}.

---

I should have probably flagged this syntax as a bit sus while reviewing pulsar-edit/pulsar#1367, but I didn't know how the preprocessor worked at the time, and it was (still is!) at least partly working, so I just threw my hands up and trusted the result. But I didn't notice the ppm symlink had broken, just that the /usr/bin/pulsar script was being made and was working. Kinda tricky. But still an oversight.

[DeeDeeG]

For reference, here are the scriptlets of the latest Pulsar Rolling .rpm at the moment:

$ rpm -qp --scripts pulsar-1.130.2026010400.x86_64.rpm 
postinstall scriptlet (using /bin/sh):
#!/bin/sh

FILESOURCE='/opt/Pulsar/resources/pulsar.sh'
FILEDEST='/usr/bin/pulsar'

if [ -f "$FILEDEST" ]
then
  rm "$FILEDEST"
fi
cp "$FILESOURCE" "$FILEDEST"

case $executable in
  pulsar-next)
    ppm_executable=ppm-next
    ;;
  *)
    ppm_executable=ppm
    ;;
esac

SYMLINK_TARGET='/opt/Pulsar/resources/app/ppm/bin/${ppm_executable}'
SYMLINK_PATH='/usr/bin/${ppm_executable}'

if [ -L "$SYMLINK_PATH" ]
then
  rm "$SYMLINK_PATH"
fi
ln -s "$SYMLINK_TARGET" "$SYMLINK_PATH"
postuninstall scriptlet (using /bin/sh):
#!/bin/sh

PULSAR_SCRIPT_PATH='/usr/bin/pulsar'

if [ -f "$PULSAR_SCRIPT_PATH" ]
then
  rm "$PULSAR_SCRIPT_PATH"
fi

case $executable in
  pulsar-next)
    ppm_executable=ppm-next
    ;;
  *)
    ppm_executable=ppm
    ;;
esac

PPM_SYMLINK_PATH='/usr/bin/${ppm_executable}'

if [ -L "$PPM_SYMLINK_PATH" ]
then
  rm "$PPM_SYMLINK_PATH"
fi

(Note: We should also be using the rpm-specific post-uninstall script not the generic/deb-oriented one, but that appears to have accidentally gotten yeeted in an apparent single-vs-double-quoting merge conflict incident in script/electron-builder.js. A situation that appears to have hid that the filenames of the scripts were meaningfully different, not just a quoting disparity on those lines of diff conflict.)

[savetheclocktower]

I have no memory of how I derived the changes I made in post-install.sh. The aim was to genericize the RPM so it would work for both Pulsar and PulsarNext. The interpolation, if it happens, needs to be made by electron-builder; that's the only thing for which sanitizedProductName is a meaningful identifier. I'll look into this some more on my own end.