[DISCUSSION] 终端创建时默认传入IDE Server的process env 是否合理？

[life2015]

讨论内容：

终端创建时默认传入IDE Server的process env 是否合理？

在IDE Server的开发与部署中，遇到了使用CloudIDE开发的项目环境变量不符合用户预期的情况。比如说因为IDE Server是以生产模式部署，因此NODE_ENV变量为production，这就导致了使用CloudIDE 开发前端项目时npm行为不符合预期。

总之，被注入到终端中的环境变量会变得不可控或者不符合预期。

个人的看法是：process.env 注入终端的变量按需获取，采用白名单机制而不是黑名单机制。至于用户终端的环境变量具体是什么，要按照Linux的系统机制来，根据.bashrc / .bash_profile 这些机制来。

目前尽管我们的Terminal Profile Api提供了StrictEnv的能力，但是默认黑名单机制注入process.env 依然有不妥，尤其是在IDE Server部署环境鱼龙混杂的情况下。

因为process.env被污染的用户开发空间截图示例

目前的pty逻辑：

项目：终端改造：

关联PR #713
关联ISSUE #803

[erha19]

@life2015

1. KTELECTRON 这个变量是否还有业务在用？这个变量是用来做啥的？没用感觉可以去掉
2. 白名单机制赞同，但环境变量具体是什么? 这个对应的配置设计好像没有提到？

[erha19]

另外，有没有看过 VS Code 相关的设计，可以也贴一下看看

[life2015]

VSCode 里面对ENV的处理是更加细致的，对于 non-interactively 的 shell 程序，VSCode会有逻辑去拿取ShellEnv然后手动注入
https://github.dev/microsoft/vscode/blob/8632e9c4096eab5773958b9fb3f45f92efba74a8/src/vs/platform/shell/node/shellEnv.ts#L139

对于正常的终端程序，VSCode注入之前也会剔除掉对用户可能有影响的Electron变量，另外就是VSCode的使用场景环境变量比较可控，因为一般是Electron App 或者 Remote。而我们会因为部署环境的不同而产生很多不同的环境变量

[life2015]

目前我的处理是在集成端对pty.ts做一些继承覆写来满足自己的需要，等后续的探索成熟之后在下沉到opensumi中。