Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running a .mjs-script through symlink with early exit creates copy of the script #993

Closed
ath88 opened this issue Dec 15, 2024 · 5 comments · Fixed by #997
Closed

Running a .mjs-script through symlink with early exit creates copy of the script #993

ath88 opened this issue Dec 15, 2024 · 5 comments · Fixed by #997

Comments

@ath88
Copy link

ath88 commented Dec 15, 2024

To follow up on #579 - I don't know why it was considered completed, as there is no resolution mentioned in the issue.

I still experience this issue with zx 8.2.4.

To replicate, make a file called test.mjs with one line:

process.exit();

.. then make a symlink to the file with ln test.mjs test, and run with zx test.

You'll start seeing a copy of test.mjs for every execution, showing up in the directory with names like:

  • test-zz5yo0hugt.mjs
  • test-ysdh5sy58g.mjs
@ath88
Copy link
Author

ath88 commented Dec 16, 2024

After some digging, I notice that its a combination of a few pieces of code. Namely these:

  if (ext === '') {
    const tmpFilename = fs.existsSync(`${filepath}.mjs`)
      ? `${base}-${randomId()}.mjs`
      : `${base}.mjs`

    return writeAndImport(
      await fs.readFile(filepath),
      path.join(dir, tmpFilename),
      origin
    )
  }

Here - if there is no extension, we make a copy, now with an extension, and with a random ID in my case, to avoid collisions.

export async function writeAndImport(
  script: string | Buffer,
  filepath: string,
  origin = filepath
) {
  await fs.writeFile(filepath, script.toString())
  try {
    await importPath(filepath, origin)
  } finally {
    await fs.rm(filepath)
  }
}

Here - we write the new filename, and once we have executed the script, we remove the file again with a finally block.

  await import(url.pathToFileURL(filepath).toString())

Here there actual execution happens. Though - if this executes a process.exit() we never reach the finally block and the temporary file is never deleted.

A fix - in my case - could be to execute the file without the extension, which works just fine. Removing the first block of code above does it. I don't know why the block was added in the first place - I don't see any comments or information in the git commit message.

However - there is still an issue with .md files executing process.exit(). Also - should a finally block be added elsewhere, this will still not be executed.

Another solution would be to execute the script in another thread, so we avoid having process.exit() terminate the parent process. I bet there will be another host of issues cropping up by doing this.

Feedback will be appreciated. :)

@antongolub
Copy link
Collaborator

* Thinking about replacing randomId with some sort of file hash...

@ath88
Copy link
Author

ath88 commented Dec 16, 2024

* Thinking about replacing randomId with some sort of file hash...

At least there will only be one file then, but it still doesn't fix the issue, right?

antongolub added a commit to antongolub/zx that referenced this issue Dec 17, 2024
antongolub added a commit that referenced this issue Dec 17, 2024
* fix(cli): add `process.exit` hook to rm temp file

closes #993

* test: refactor deps tests

* fix: update zurk to v0.9.2 to handle tslib literals issue

closes #966

* chore: up size limit

* chore: up dev deps

* chore: update zurk to v0.9.3
@antongolub
Copy link
Collaborator

@ath88,

Check this out: v8.2.4-dev.c8ca866

@ath88
Copy link
Author

ath88 commented Dec 18, 2024

@ath88,

Check this out: v8.2.4-dev.c8ca866

Works as intended. :) Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants