Changing PATH env var doesn't seem to work

Task version: 3.2.2
Operating System: MacOS & Linux

Firstly thanks a lot for the excellent tool! I've moved lots of hacky shell scripts over to task.

Example Taskfile showing the issue

version: "3"

env:
  PATH: test

tasks:
  path:
    - echo $PATH

The result is my existing path. Switching from PATH to PATH2 shows test as expected. Is this intentional?

@andreynering

afaik, it is not possible to override environment variables, and this is expected. I asked in #449 whether it'd be possible to add this change in a PR, but the question hasn't been answered. I'd be happy to contribute with this but would like to know first if @andreynering would be open to have a PR with these changes.

@ivotron

@ivotron Well you can try to implement this and maintain change at least in your fork. As for me will pull this change to mine for sure.

To me, it seems like the more correct way might be to opt-in to the inheritance.

env:
  PATH: $PATH

I think the closest parallel would be a Dockerfile, where the stacking goes:

ENV directive
.env file
-e flag

I think the interactions for most of this is underspecified. And the "$" in env: actually is equivalent to { sh: }.

Hi everybody,

Changing the priority order of ENVs is a breaking change and would be unexpected to existing users that rely on it. Currently it's possible to override ENVs with something like env MY_ENV=overriden task foo. This proposal would break that.

Making this change would make ENV work similar to VARS regarding its priority, but would require people to use MY_ENV: '{{default FOO .MY_ENV}}' on all ENV declarations that should be overridable. This could be inconvenient for some and would likely require a release of v4 since it's a breaking change. The same applies to #521.

I would love to hear opinions on what do you think. An alternative would likely be better than a breaking change. Let me know if you have any ideas on how to do that.

Regarding the ability to override PATH, as a workaround you could have a variable with the prefix command:

version: '3'

vars:
  PREFIX: env PATH="/some/path:$PATH"

tasks:
  foo:
    cmds:
      - '{{.PREFIX}} my command'
      - '{{.PREFIX}} another command'

Perhaps #204 (comment) would be nice to have this workaround cleaner.

I just found this, and this feels like a pretty big issue. Here's the simplest case:

version: '3'

tasks:
  one:
    env:
      HAM: one
    cmds:
      - echo $HAM


  two:
    cmds:
      - task: one
        env:
          HAM: two

at 13:41:58 ❯ task -t Taskfile.tmp.yml one
task: [one] echo $HAM
one

at 13:42:09 ❯ task -t Taskfile.tmp.yml two
task: [one] echo $HAM
one

I also tried this:

version: '3'

tasks:
  one:
    env:
      HAM: '{{env "HAM" | default "one"}}'
    cmds:
      - echo $HAM


  two:
    cmds:
      - task: one
        env:
          HAM: two

The following DOES work:

version: '3'

tasks:
  one:
    vars:
      HAM: '{{.HAM | default "one"}}'
    env:
      HAM: '{{.HAM}}'
    cmds:
      - echo $HAM


  two:
    cmds:
      - task: one
        vars:
          HAM: two

Which leads me to believe that really vars should be used more liberally than env, and env should always derive from vars, because then you can do this:

version: '3'

vars:
  HAM: '{{env "HAM"}}'

tasks:
...

Which would allow the make behavior of HAM ?= default-value-here

It seems there are many related issues to this as well: #591, #658, #630, #593, #191

@andreynering

@andreynering

change and would be unexpected to existing users

Have you considered adding an override_env variable in the global scope
which by default will be false (same order as now)
but if true, it will handle replacing existing envs (for example with PATH)

it would not be such a big change to increase the version to v4, but it also allowed to solve this problem

and in the future, simply version v4 will be the default value of true

version: "3"

override_env: true

env:
  PATH: test

tasks:
  path:
    - echo $PATH

Have you considered adding an override_env variable in the global scope which by default will be false (same order as now) but if true, it will handle replacing existing envs (for example with PATH)

it would not be such a big change to increase the version to v4, but it also allowed to solve this problem

A per-variable override (force, erase or whatever you see fit) parameter would be fine too. E.g.

version: "3"

override_env: true

env:
  PATH:
    value: test
    override: true

tasks:
  path:
    - echo $PATH

This would be very useful to replace npm scripts with Task with simply doing

version: '3'
vars:
  WORKSPACE:
    sh: pwd
env:
  PATH: "{{.WORKSPACE}}/node_modules/.bin:{{.ENV.PATH}}"

tasks:
  lint:
    cmds:
      - eslint .

Currently I have to do:

lint:
  cads: ['pnpm run-script eslint .']

Hi all, there are many open issues related to variables in v3. To help centralise and focus our discussions we have created a new megathread. The env precedence experiment is now stable and there are open tickets linked from the megathread to discuss inheritance and scoping so I'm going to close this issue.

Navigation Menu

Repository navigation

Changing PATH env var doesn't seem to work #482

Example Taskfile showing the issue

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Changing PATH env var doesn't seem to work #482

Description

Example Taskfile showing the issue

Activity

ivotron commented on May 3, 2021

butuzov commented on May 12, 2021

d3dc commented on Jul 16, 2021

andreynering commented on Jul 17, 2021

ghostsquad commented on Mar 1, 2022

sirenkovladd commented on Feb 14, 2024

Adirelle commented on Nov 12, 2024

mohsen1 commented on Jan 10, 2025

pd93 commented on Feb 3, 2025

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions