Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Ilyes512 opened this issue Mar 8, 2019 · 7 comments
Open

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

Ilyes512 opened this issue Mar 8, 2019 · 7 comments

Comments

@Ilyes512
Copy link

Ilyes512 commented Mar 8, 2019

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 :)

@andreynering andreynering added the type: question Further information is requested. label Mar 9, 2019
@andreynering andreynering changed the title String interpolation and home dir (including ~) env: is not being expanded, so stuff like ~ is working there Mar 9, 2019
@andreynering andreynering changed the title env: is not being expanded, so stuff like ~ is working there env: is not being expanded, so stuff like ~ isn't working there Mar 9, 2019
@andreynering
Copy link
Member

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.

@andreynering
Copy link
Member

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

@Ilyes512
Copy link
Author

Ilyes512 commented Mar 9, 2019

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 :)

@Ilyes512
Copy link
Author

Ilyes512 commented Mar 11, 2019

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).

@andreynering
Copy link
Member

@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).

@snoob
Copy link

snoob commented Jun 13, 2021

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

@amancevice
Copy link
Contributor

Expanding ~ in includes would be great:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants