Allow Overriding shell for tasks

[uroybd]

Check for existing issues

• Completed

Describe the feature

Many of the newer shell programs (and some popular ones) have some syntactical differences with sh-like shells. Fish and Nushell are the 2 examples that easily come to mind. Often we like to use them as users, however, it is preferable to use a standard shell for tasks for a project.

I propose an option to override the shell program for each task (in tasks.json). Also, a local settings level terminal override will be nice.

If you plan to do this and don't mind me contributing, I can try implementing this feature.

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[osiewicz]

Hey, yeah, contributions are welcome. We had a discussion about this internally and one suggested solution was to use user-specified shell for user tasks (coming from global tasks.json/oneshots) and "standard" shell like bash with worktree tasks and language tasks.

For what it's worth, tasks currently use the same shell as the one configured for your Zed terminal.

IMHO making it tweakable on a task-by-task basis is a bit too fine-grained. You're either gonna set a custom shell for all of your tasks or none of them I suppose?

[uroybd]

IMHO making it tweakable on a task-by-task basis is a bit too fine-grained.

It is a bit too fine-grained. However, the tasks.json file is a list, so setting params for all tasks has to do in the local settings perhaps? Alternatively, we can redefine tasks.json schema to something like this:

{
  "terminal": {
    "shell": "bash"
  },
  "tasks": [
    ...tasks as was before
  ]
}

[osiewicz]

Yeah, I think we should bite a bullet and allow defining it in tasks.json. I don't think we should use user settings there given that you can have worktree-local tasks.json; I think it should be possible to write a given tasks.json file with confidence about the shell that's gonna use (even though it'll be bash most of the time I guess).

We need to take backwards compat into account there though, as we don't want to break existing tasks.json files on end user machines. We should be able to deserialize both the "Task-list" format (which uses JSON array) and "tasks-and-settings" (that's JSON map/object - most likely).

[Joshix-1]

I feel like the shell should not depend on the current user shell. That's not guaranteed to conform to any spec. /bin/sh on the other hand should always be posix-compliant.

You could maybe vendor your own cross-plattform shell for tasks. Deno e.g. uses their own custom shell https://github.com/denoland/deno_task_shell/ (written in rust) for their tasks. Maybe that or something similar could be used.

[osiewicz]

The problem is, while uniformly sticking to a common shell like /bin/sh makes certain scenarios easier (e.g. writing tasks as extension author), it prevents user from accessing the aliases and environmental variables from their OG shell, which in my opinion is a downside. I think it's fine to use user shell for oneshots and - if they want/need - for global/worktree tasks.json if they want. The only place where we really should use a standard shell is the language tasks, as we don't know the shell we're targeting.
/cc @mrnugget who was a proponent of that change in our internal discussions.

[WeetHet]

The problem is, while uniformly sticking to a common shell like /bin/sh makes certain scenarios easier (e.g. writing tasks as extension author), it prevents user from accessing the aliases and environmental variables from their OG shell, which in my opinion is a downside. I think it's fine to use user shell for oneshots and - if they want/need - for global/worktree tasks.json if they want. The only place where we really should use a standard shell is the language tasks, as we don't know the shell we're targeting. /cc @mrnugget who was a proponent of that change in our internal discussions.

We already have a mechanism for retrieving environment variables from user shell and passing them to tasks, so those won't be a big problem. Aliases are a bit harder to reason about, but I don't think not having those would be that terrible (I'd say it even would be a positive, as tasks might be shared via git and executed on systems with different aliases set up)