This is offshoot of How to define variables in global options in vscode tasks.json and refer it in task?

We use some custom build system (not vanilla make). Generally, we don't build code (C++) in the sandbox and create linked area (directory with soft links to files in the sandbox) to do the build there. For debug and optimized builds, I may have 2 such paths. And I want to define 2 different tasks for triggering opt or debug builds ...

To experiment to open build log through tasks, I tried following -

{
    "version": "2.0.0",
    "options": {
        "env": {
            "OPT_BUILD_AREA": "<some path>/opt",
            "DBG_BUILD_AREA": "<some path>/dbg"
        },
    },
    "tasks": [
        {
            "label": "Open Full Opt-Build Log",
            "type": "shell",
            "command": "code",
            "args": [
                "--reuse-window",
                "--goto",
                "${OPT_BUILD_AREA}/build.log"
            ],
            "presentation": {
                "reveal": "silent",
                "focus": true,
                "panel": "shared"
            },
        },
        {
            "label": "Test Full Opt-Build Log Path",
            "type": "shell",
            "command": "echo",
            "args": ["${OPT_BUILD_AREA}/build.log"]  
        }
    ]
}

However, this always opens the log in new window. How to open it in a new table of existing window?

I have already tried following but does nothing

            "command": "${command:workbench.action.quickOpen}",
            "args": ["${env:OPT_BUILD_AREA}/build.log"],

Also, what happens, say, if the file does not exist - could my vscode session crash? And if my build command is "build", how can I trigger "build" and open the log from the same task?

This is offshoot of How to define variables in global options in vscode tasks.json and refer it in task?

We use some custom build system (not vanilla make). Generally, we don't build code (C++) in the sandbox and create linked area (directory with soft links to files in the sandbox) to do the build there. For debug and optimized builds, I may have 2 such paths. And I want to define 2 different tasks for triggering opt or debug builds ...

To experiment to open build log through tasks, I tried following -

{
    "version": "2.0.0",
    "options": {
        "env": {
            "OPT_BUILD_AREA": "<some path>/opt",
            "DBG_BUILD_AREA": "<some path>/dbg"
        },
    },
    "tasks": [
        {
            "label": "Open Full Opt-Build Log",
            "type": "shell",
            "command": "code",
            "args": [
                "--reuse-window",
                "--goto",
                "${OPT_BUILD_AREA}/build.log"
            ],
            "presentation": {
                "reveal": "silent",
                "focus": true,
                "panel": "shared"
            },
        },
        {
            "label": "Test Full Opt-Build Log Path",
            "type": "shell",
            "command": "echo",
            "args": ["${OPT_BUILD_AREA}/build.log"]  
        }
    ]
}

However, this always opens the log in new window. How to open it in a new table of existing window?

I have already tried following but does nothing

            "command": "${command:workbench.action.quickOpen}",
            "args": ["${env:OPT_BUILD_AREA}/build.log"],

Also, what happens, say, if the file does not exist - could my vscode session crash? And if my build command is "build", how can I trigger "build" and open the log from the same task?

• visual-studio-code
• vscode-tasks

1 Answer 1

It works fine for me if I just switch the task type from shell to process. You don't need a shell type anyway.

Also, your environment variable reference should be of the form ${env:FOO}. You seem to know this but don't apply it consistently.

Also, as you should already know from your other question, and as the docs say:

Environment variables configured [in options] can only be referenced from within your task script or process and will not be resolved if they are part of your args, command, or other task attributes.

So your environment variable reference in args just evaluates to nothing.