env: is not being expanded, so stuff like ~ isn't working there

Task version: 2.4.0 OS: Darwin (MacOS)

This project really looks promising, and I would really like to use this instead of Make except I am running into some problems.

I have the fallowing example task file. For the below test I ran this first to have a test file: $ echo 'hello world' > ~/testfile.txt:

version: "2"

env:
  WORLD: world!!!!!
  HW: hello_${WORLD}
  TEST_FILE: ~/testfile.txt

tasks:
  test:
    cmds:
      - echo $HOME
      - echo ~
      - echo $WORLD
      - echo $HW
      - echo $TEST_FILE
      - echo ~/testfile.txt
      - cat ~/testfile.txt
      - echo ${TEST_FILE}
      - cat ${TEST_FILE}

I get the fallowing output (minus the -----> expected appended) when I run $ task test:

echo $HOME
/Users/ilyes512
echo ~
/Users/ilyes512
echo $WORLD
world!!!!!
echo $HW
hello_${WORLD} -----> expected: hello_world!!!!!
echo $TEST_FILE
~/testfile.txt
echo ~/testfile.txt
/Users/ilyes512/testfile.txt
cat ~/testfile.txt
hello world
echo ${TEST_FILE}
~/testfile.txt -----> expected: /Users/ilyes512/testfile.txt
cat ${TEST_FILE}
cat: ~/testfile.txt: No such file or directory -----> expected: hello world

When I set an env variable like this (and I don't even use it):

env:
  EXAMPLE: ${HOME}/foobar

It will error with:

"{HOME}/foobar": executable file not found in $PATH
task: Command "{HOME}/foobar" in taskvars file failed: exit status 127

So should I be able to use a earlier set env variable in another env?
Does the ~ and ${HOME} behave correctly?

Another issue I saw about almost the same thing: #74 It also mentions a "chat". Is this still in use, and if so, it should be documented somewhere? (would expect the readme to mention it).

BTW I have tried variables as both ${FOOBAR} as well as $FOOBAR (so minus the { and }).

Thanks in advance :)

@Ilyes512

Hi @Ilyes512,

We had a chat room in the past here (you'd need to sign up on https://gophers.slack.com first). It's still there, but I removed the links from the GitHub repo and site because I not always had time to answer questions quickly, and also it's not very searchable. GitHub issues suits better, IMHO.

About the issues you've being having... that's happening because Task isn't currently expanding values on env: at all. Expanding are only happening for dir: and sources: and generates:, so stuff like ~ will work there. But I think it makes sense to also expand env:, so I'll look into fixing this soon.

Even then, you still won't be able to reference other environment variables add to env:, though. Unless it's a previously set one, like PATH, etc.

Keep in mind variable expansion works for env:, too. That is likely to solve your use case already.

Yes, I was just now playing with vars instead and I realise I wouldn't actually use env variables that much.

I also noticed I can use vars to "build" env variables when needed ie:

vars:
  HOME: {sh: "echo $HOME"}

env:
  HOME: "{{.HOME}}/foobar"

BTW I am already am a member of gophers :)

This might be it's own issue but I was wondering what your thought are about adding this:

vars:
  MINIKUBE_IP: {sh: "minikube ip", ignore_error: true}

If Minikube is not running it would stop execution with: 💣 Error getting IP: Host is not running which is fine, but would be nicer to do this in the task explicitly. Another great addition might be something like a condition key. A sort of check if the task deps are met:

tasks:
  foobar:
    condition:
      - node --version
    cmds:
      - <node stuff>

hmm, but then again, having an easy to understand, not bloated task runner, is very nice as well. Could probably come up with 10's of idea's. A more generic way would maybe be a before_cmds and after_cmds (with the last one always beging run even when cmds errors, but not if before_cmds errored).

@Ilyes512

@Ilyes512 Yeah, I try not to add lots of features, but keep Task concise when possible.

For now, you can use Bash to check if the executable is available, and do nothing if don't. (The commands inside cmds and sh are interpreted as Bash commands, so you can use if, test, [], etc).

@andreynering

@andreynering Maybe home expanding is missing for includes too no ?

Expanding ~ in includes would be great:

includes:
  shared: ~/.task/Taskfile.yml

I think it's good to have env expanding like below:

env:
  DB_HOST: hostname
  DB_PASS: pass
  CONNECTION_STRICT: "posgresql://{{.DB_HOST}}+{{.DB_PASS}}"

It's a common use case for js projects. Bun, dotenv, node all support this. I guess the alternative with taskfile is now as below but that's too repetitive when you need many env vars.

vars:
  DB_HOST: hostname
  DB_PASS: pass
  CONNECTION_STRING: "posgresql://{{.DB_HOST}}+{{.DB_PASS}}"
env:
  DB_HOST: "{{.DB_HOST}}"
  DB_PASS: "{{.DB_PASS}}"
  CONNECTION_STRING: "{{.CONNECTION_STRING}}"

This issue is in the weeds. As correctly noted, use vars and templating as much as possible.

For the original problem, prefix you command with eval to expand the envars: eval echo $HW

Navigation Menu

Repository navigation

env: is not being expanded, so stuff like ~ isn't working there #185

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

env: is not being expanded, so stuff like ~ isn't working there #185

Description

Activity

andreynering commented on Mar 9, 2019

andreynering commented on Mar 9, 2019

Ilyes512 commented on Mar 9, 2019

Ilyes512 commented on Mar 11, 2019

andreynering commented on Mar 16, 2019

snoob commented on Jun 13, 2021

amancevice commented on Jul 28, 2021

MansurAliKoroglu commented on Jan 29, 2026

trulede commented on Feb 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions