6 ms·

It seems like the command is from this line of the VSCode source (Cursor is a fork of VSCode): https://github.com/microsoft/vscode/blob/f8b29f8da2c9bfda02924243

It seems like the command is from this line of the VSCode source (Cursor is a fork of VSCode): https://github.com/microsoft/vscode/blob/f8b29f8da2c9bfda02924243e02a5da864581aa0/src/vs/platform/shell/node/shellEnv.ts#L144C4-L144C108 https://github.com/microsoft/vscode/blob/f8b29f8da2c9bfda029... GitHub Copilot thinks it does this to capture shell-specific environment variables (like those set up in .zshrc) that you wouldn't necessarily get unless you open the app from a shell yourself. Given it's been like this for at least 4 years, I don't think it's necessarily anything nefarious, and it's likely unchanged in Cursor.

jrootabega 2y ago
Seems like the correct answer to me. Let's assume henceforth in this post that the code still does what the original vs code authors claim it was intended to do, and nothing more. If you launch the IDE from a shell, or launch ANY program from that same shell, it will automatically have access to the environment that you're concerned about. Here's where they introduced wrapping the environment output in "random" numbers: https://github.com/microsoft/vscode/commit/1336b3d3c0d4338fbd96d74b38f9a18df3a54956#diff-17718e297b12a6c80ef2c9022ee8ea0834f81436d199e55d0a87c36f8b7c0143R298 https://github.com/microsoft/vscode/commit/1336b3d3c0d4338fb... The associated issue explains that they needed to be able to ignore extraneous info returned by the shell itself, so they make the command return a token to delimit the actual environment info they want. The very idea of spawning a shell to grab its environment has been there since the beginning of vs code: https://github.com/microsoft/vscode/commit/8f35cc4768393b25468416829e980d7550619fb1#diff-21bce218207c71a3acc721ce40e63038a0cb544eac4f1444c7ccf41ed55e418fR23 https://github.com/microsoft/vscode/commit/8f35cc4768393b254...
- iyn 2y ago
  Thanks, I appreciate the additional context. Now all of it makes sense :)
iyn 2y ago
Thank you, this is it!

jrootabega 2y ago

Seems like the correct answer to me. Let's assume henceforth in this post that the code still does what the original vs code authors claim it was intended to do, and nothing more. If you launch the IDE from a shell, or launch ANY program from that same shell, it will automatically have access to the environment that you're concerned about. Here's where they introduced wrapping the environment output in "random" numbers: https://github.com/microsoft/vscode/commit/1336b3d3c0d4338fbd96d74b38f9a18df3a54956#diff-17718e297b12a6c80ef2c9022ee8ea0834f81436d199e55d0a87c36f8b7c0143R298 https://github.com/microsoft/vscode/commit/1336b3d3c0d4338fb... The associated issue explains that they needed to be able to ignore extraneous info returned by the shell itself, so they make the command return a token to delimit the actual environment info they want. The very idea of spawning a shell to grab its environment has been there since the beginning of vs code: https://github.com/microsoft/vscode/commit/8f35cc4768393b25468416829e980d7550619fb1#diff-21bce218207c71a3acc721ce40e63038a0cb544eac4f1444c7ccf41ed55e418fR23 https://github.com/microsoft/vscode/commit/8f35cc4768393b254...

iyn 2y ago
Thanks, I appreciate the additional context. Now all of it makes sense :)

iyn 2y ago

Thank you, this is it!