32

The Custom tasks section of the Tasks in Visual Studio Code describe the task's properties. There is a type property that define task's type:

type: The task's type. For a custom task, this can either be shell or process. If shell is specified, the command is interpreted as a shell command (for example: bash, cmd, or PowerShell). If process is specified, the command is interpreted as a process to execute.

I couldn't understand what's the different between them. No matter I choose shell or process, all the execute results are all the same.

So what's the different between interpreted as a shell command and command is interpreted as a process to execute really mean?

Nurbol Alpysbayev
  • 19,522
  • 3
  • 54
  • 89
Will Huang
  • 2,955
  • 2
  • 37
  • 90

3 Answers3

30

The shell commands can only run inside a shell such as DIR for cmd and if for bash. So when you want to run shell commands, you have to use "type": "shell" setting to run it correctly. When you want to just run a program such as .bat, .sh or .exe, then you can just use "type": "process" setting.

Will Huang
  • 2,955
  • 2
  • 37
  • 90
  • 1
    You're a real hero. – Aminadav Glickshtein Aug 26 '19 at 10:54
  • 1
    So I should be defaulting to process? Does it spawn a cmd too or am I saving that time? What's the benefit of process is what I'm asking I guess. – Razze Feb 20 '20 at 10:34
  • @Razze As I said, **The shell commands can only run inside a shell**. If you are going to run a "program", then you need to use `"type": "process"` for sure. – Will Huang Feb 22 '20 at 17:15
  • 2
    That does not really answer what the pro/con arguments are – Razze Feb 25 '20 at 10:53
  • @Razze There is no pros and cons comparison. They are just different purpose. – Will Huang Mar 03 '20 at 14:37
  • 1
    I would suggest to rephrase it slightly. Specifically, "When you want to just run a program such as .bat, .sh or .exe, ..." is confusing with respect to "when you want to run shell commands" as .BAT and .SH are not programs but shell scripts that *may* and typically contain shell commands and statements. So, if you want to launch executable and pass parameters to it, you are safe to use "process". If you pass shell script or commands specific to shell as mentioned above, use "shell" – Petr Lazecky Mar 17 '20 at 18:56
  • 4
    I agree with @Razze that the pro/con arguments are still not answered. What's the benefit of using the "process" type when executing a program when I could just as easily use the "shell" type for calling said program? They offer the "process" type for some reason, but what is it? What do I gain by switching to "process" for a single program command? I can't find that answer in the docs. – plwalsh88 Oct 06 '20 at 17:04
  • @plwalsh88 If you want to use "pipes" in the commands, then you will have to use "shell" to be interpreted correctly. – Will Huang Oct 07 '20 at 02:26
  • 2
    @WillHuang, well yes. If I want to use any additional logic in the commands, aside from the program name, I would need to use the "shell" type. But again, I could still just use the "shell" type for the program name, and as far as I know, the result will be the same as using the "process" type. So that still doesn't answer the question of "why should I ever choose the 'process' type?" – plwalsh88 Oct 09 '20 at 19:08
3

well, I recently troubled by a problem, and I finally done it by changing the type from "process" to "shell" and I think this might help you: I'm trying to run more than one .cpp files, and I used a wildcard in the args:"${fileDirname}/.cpp". When the type was process, I cannot run the project successfully, as it always tell me: "*.cpp":no such file or directory and when I change to "shell" it goes well. This might be one of the differences between "process" and "shell".

Zifan Ma
  • 31
  • 2
3

I think the difference is as follows:

  • process: runs a specific program (a binary)
  • shell: starts a shell session and runs the given command inside of that shell session

If the command you give to a shell is just (the path to) a program, for example date, the result will be exactly the same.

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "example1",
      "type": "process",
      "command": "date",
      "presentation": {
        "reveal": "always"
      },
      "problemMatcher": []
    },
    {
      "label": "example2",
      "type": "shell",
      "command": "date",
      "presentation": {
        "reveal": "always"
      },
      "problemMatcher": []
    }
  ]
}

The task that uses process will probably be a little faster because it does not start a shell session.

But because a shell type task creates a shell session it can use any command you can type on the command line. So let's say the task we want to run is date -u +"%Y-%m-%dT%H:%M:%SZ", we can do this with a shell task, but not with a process task.

Example:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "example1",
      "type": "process",
      "command": "date",
      "presentation": {
        "reveal": "always"
      },
      "problemMatcher": []
    },
    {
      "label": "example2",
      "type": "shell",
      "command": "date -u +\"%Y-%m-%dT%H:%M:%SZ\"",
      "presentation": {
        "reveal": "always"
      },
      "problemMatcher": []
    }
  ]
}

So, as always, it depends on what you need or want. Personally I think tasks of type shell are useful way more often.


One extra thing: a task definition can also have a "args" key where you can send arguments. That may allow you to send arguments if you need to use process. I did not investigate that to answer this question.

Another relevant page of docs.

Niels Bom
  • 8,728
  • 11
  • 46
  • 62