-
Notifications
You must be signed in to change notification settings - Fork 29k
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
Setting a terminal by workspace settings is broken! User settings are not sufficient! #19758
Comments
Similar thing - I use Bash in some workspaces, Cmd in others - hence user settings alone isn't sufficient. |
I could easily downgrade by uninstalling and installing the previous version via chocolately: |
@kieferrm thoughts? |
I agree, we need a way to specify these sort of settings per workspace. I work across different projects where while the bulk use PowerShell some others use SQL Command line and Bash etc Another point to this is I collaborate across teams with these projects. I dont really want to have to explain to them how to edit their User settings each time a new member helps out on a project. It should just ship the workspace setting with the code base. Isn't that the intent here? I mean I understand this could be seen as a security risk, but no more than running any terminal / command line code? If I was starting out on an existing project after I get the code I would check what workspace settings are set. Maybe that could be a solution, the first time someone opens a project up display the workspace settings to them for review? |
I've been reading the release notes and there seems to be language specific settings now (or maybe I'm just catching up). This might help in some circumstance but not in all cases like mentioned in other comments |
Maybe we are being too strict, this use case does seem particularly useful. How about we take another approach to the problem while still protecting users from running malicious executables? Consider the following scenario:
For example: The actions on the message box could be [Yes] and [Ignore] (or something more verbose). When [Yes] if selected, the option would be saved in local storage and not bug the user again. When [Ignore] is selected, the message box will go away from the rest of the session, displaying again the next time the workspace is loaded. Something like this would prevent anything from running without an explicit opt in from the user. |
I understand the concern with targeting malicious executables in git repo. Hadn't thought about that before. |
I think the shell name and shell executable path can be separate settings. And executable path settings will not be allowed in project/workspace settings. The names can be- "BASH", "CMD", "Powershell", "SQL", "Custom" etc. Then a project will be able to set the name of the intended shell but not the path. |
The usable thing is the whole use case, not just a part of it: The settings as in 1.8.1 are flexible and this way good for every situation. |
@Tyriar your proposed solution makes sense that is applicable to all platforms. |
Thank you! |
Steps to Reproduce:
VSCode complains that my custom terminal settings in the workspace configuration are wrong after the update. It does not respect these anymore.
I need per project/workspace configuration because i use remote ssh terminals to work on the dev server. The dev server is different in every workspace.
This was perfectly working:
Please tell me how i can downgrade to the working version until this is fixed.
The text was updated successfully, but these errors were encountered: