# /.travis/functions: No such file or directory **URL:** \ **Category:** Travis CI Discussions & Feedback\ **Created:** [February 14, 2019, 4:29pm UTC](https://travis-ci.community/t/travis-functions-no-such-file-or-directory/2286 "2019-02-14T16:29:16Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![chrisspen](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/chrisspen/32/1189_2.png) [@chrisspen](https://travis-ci.community/u/chrisspen)\ **Post date:** [February 14, 2019, 4:29pm UTC](https://travis-ci.community/t/travis-functions-no-such-file-or-directory/2286/1 "2019-02-14T16:29:16Z")
My unittests that check certain OS-level commands are failing with the errors: [127.0.0.1] sudo: whoami [127.0.0.1] out: /home/travis/.travis/job\_stages: line 1: /.travis/functions: No such file or directory [127.0.0.1] out: root [127.0.0.1] out: AssertionError: ‘/home/travis/.travis/job\_stages: line 1: /.travis/functions: No such file or directory\nroot’ != ‘root’ These don’t happen for me on my local Ubuntu install, and they look to be due to some Travis-specific configuration. Any idea how I can resolve them? ---
**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\ **Post date:** [February 14, 2019, 5:19pm UTC](https://travis-ci.community/t/travis-functions-no-such-file-or-directory/2286/2 "2019-02-14T17:19:14Z")
When reporting a problem, please include the build log URL, so that we can help you better. Thank you! ---
**Author:** ![sebbacon](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/sebbacon/32/1278_2.png) [@sebbacon](https://travis-ci.community/u/sebbacon)\ **Post date:** [February 25, 2019, 1:50pm UTC](https://travis-ci.community/t/travis-functions-no-such-file-or-directory/2286/3 "2019-02-25T13:50:59Z")
Same problem here. [https://travis-ci.com/ebmdatalab/ebmbot/builds/102161323#L594](https://travis-ci.com/ebmdatalab/ebmbot/builds/102161323#L594) Looks like `job_stages` sources `$TRAVIS_HOME/.travis/functions`, but for some reason, at the time that `job_stages` was created, that variable was empty (when it should, in my environment, have been `/home/travis`). I found the code that’s supposed to do this [here](https://github.com/travis-ci/travis-build/blob/275ce64b5ffa058c0c755fa18654f1f0c517cbed/lib/travis/build/script.rb#L248-L254), but not sure why it’s not working. In my case, the code under test creates a new bash subshell by sshing to localhost, so I guess it’s related to that. ---
**Author:** ![native-api](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/native-api/32/430_2.png) [@native-api](https://travis-ci.community/u/native-api)\ **Post date:** [February 25, 2019, 3:53pm UTC](https://travis-ci.community/t/travis-functions-no-such-file-or-directory/2286/4 "2019-02-25T15:53:46Z")
It looks like your code is doing something funny: for some reason, `result[HOSTS[0]]` has the value `/home/travis/.travis/job_stages: line 1: /.travis/functions: No such file or directory`. I guess that your program captures stdout+stderr of some command (and probably does not check its exit code), likely in an altered environment. According to [https://en.wikipedia.org/wiki/Standard\_streams](https://en.wikipedia.org/wiki/Standard_streams) , a program’s _result_ is supposed to be just `stdout` contents, `stderr` is only supposed to be used for diagnostics/error reporting. You need to track the above-mentioned erroneous value back to its origin along your program’s logic – with debugger or with debug printing. For the former, you can request Travis staff to enable debug mode for your repo as per [https://docs.travis-ci.com/user/running-build-in-debug-mode/](https://docs.travis-ci.com/user/running-build-in-debug-mode/) . ---
**Author:** ![chrisspen](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/chrisspen/32/1189_2.png) [@chrisspen](https://travis-ci.community/u/chrisspen)\ **Post date:** [February 28, 2019, 11:01pm UTC](https://travis-ci.community/t/travis-functions-no-such-file-or-directory/2286/5 "2019-02-28T23:01:31Z")
Here’s my failing build: [https://travis-ci.org/chrisspen/burlap/builds/500063221](https://travis-ci.org/chrisspen/burlap/builds/500063221) I’m trying to run “sudo whoami”, and it’s throwing that error. This used to run without error in Travis. ---
**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\ **Post date:** [February 28, 2019, 11:24pm UTC](https://travis-ci.community/t/travis-functions-no-such-file-or-directory/2286/6 "2019-02-28T23:24:29Z")
> [@sebbacon](#): > > Looks like `job_stages` sources `$TRAVIS_HOME/.travis/functions` , but for some reason, at the time that `job_stages` was created, that variable was empty (when it should, in my environment, have been `/home/travis` ). Or, your jobs managed to `source ~/.travis/job_stages` without `$TRAVIS_HOME` set. The _content_ of `~/.travis/job_stages` should have: ``` source "${TRAVIS_HOME}/.travis/functions" ``` See [Travis CI - Test and Deploy with Confidence](https://travis-ci.org/BanzaiMan/travis_production_test/builds/500078837#L176) ---
**Author:** ![chrisspen](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/chrisspen/32/1189_2.png) [@chrisspen](https://travis-ci.community/u/chrisspen)\ **Post date:** [March 13, 2019, 4:45pm UTC](https://travis-ci.community/t/travis-functions-no-such-file-or-directory/2286/7 "2019-03-13T16:45:04Z")
Any update on this? I have a lot of code that processes output from shell commands, and this bug is adding Travis-specific junk to everything, breaking a ton of my tests. I can update my code to ignore everything but the last line of output, but it’d be nice if Travis didn’t populate output with irrelevant errors. ---
**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\ **Post date:** [March 13, 2019, 6:21pm UTC](https://travis-ci.community/t/travis-functions-no-such-file-or-directory/2286/8 "2019-03-13T18:21:32Z")
Please read my previous comment. Your tool is `source`ing the file without the required environment variables set. Please consult your tools (documentation, or if you know the internals, source code). I do not believe this is something we can fix. ---
**Author:** ![chrisspen](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/chrisspen/32/1189_2.png) [@chrisspen](https://travis-ci.community/u/chrisspen)\ **Post date:** [March 13, 2019, 7:03pm UTC](https://travis-ci.community/t/travis-functions-no-such-file-or-directory/2286/9 "2019-03-13T19:03:10Z")
I don’t understand your comment. My tool is Fabric, a library for running arbitrary shell commands from Python. How can it source a custom Travis file that neither it nor I know about, much less define a custom TRAVIS\_HOME environment variable? If the patch is to manually define TRAVIS\_HOME, please document what that value should be. ---
**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\ **Post date:** [March 13, 2019, 7:48pm UTC](https://travis-ci.community/t/travis-functions-no-such-file-or-directory/2286/10 "2019-03-13T19:48:04Z")
> [@chrisspen](#): > > How can it source a custom Travis file that neither it nor I know about, much less define a custom TRAVIS\_HOME environment variable? `$TRAVIS_HOME` is defined by our build script, and it is `export`ed during the build. This is documented in [Environment Variables - Travis CI](https://docs.travis-ci.com/user/environment-variables#default-environment-variables). The file in question `/home/travis/.travis/job_stages` is designed to be used (`source`d) in such an execution environment. And it works. Something beyond our control is `source`ing this file in an inappropriate manner, and causing the issue. It may be Fabric, as you say, or it may not be. ---
**Author:** ![ploxiln](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/ploxiln/32/1709_2.png) [@ploxiln](https://travis-ci.community/u/ploxiln)\ **Post date:** [April 28, 2019, 7:23pm UTC](https://travis-ci.community/t/travis-functions-no-such-file-or-directory/2286/11 "2019-04-28T19:23:41Z")
This is probably related to `.bashrc` or `.bash_profile` being sourced by the local ssh session, and one of those standard bash files being set-up by travis to `source ~/.travis/job_stages`, but this ssh session does not have `$TRAVIS_HOME` set like other forked processes do. ---
**Author:** ![ploxiln](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/ploxiln/32/1709_2.png) [@ploxiln](https://travis-ci.community/u/ploxiln)\ **Post date:** [April 28, 2019, 7:49pm UTC](https://travis-ci.community/t/travis-functions-no-such-file-or-directory/2286/12 "2019-04-28T19:49:01Z")
At the end of `~/.bashrc` in a travis-ci xenial test environment there is: ```auto ... [[-s "$HOME/.rvm/scripts/rvm"]] && source "$HOME/.rvm/scripts/rvm" ulimit -n 30000 2>/dev/null || true source /home/travis/.travis/job_stages ``` So if you start a new bash shell with a _clean_ environment (which happens when you ssh to localhost as some test systems do), then this error results. I was able to fix this with the following addition to my `.travis.yml` ```auto before_script: - echo "export TRAVIS_HOME=$TRAVIS_HOME" | cat - ~/.bashrc > ~/.bashrc.mod - mv -v ~/.bashrc.mod ~/.bashrc ``` ---
**Author:** ![chrisspen](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/chrisspen/32/1189_2.png) [@chrisspen](https://travis-ci.community/u/chrisspen)\ **Post date:** [June 17, 2019, 9:44pm UTC](https://travis-ci.community/t/travis-functions-no-such-file-or-directory/2286/13 "2019-06-17T21:44:07Z")
The problem seems to have two parts. First, Travis defines a custom .bashrc that requires the “TRAVIS\_HOME” environment variable to be explicitly defined, or else the above error is thrown. The other issue is any code that executes shell commands has to explicitly pass through the inherited TRAVIS\_HOME, or else the error happens. Since most people don’t target Travis as their production environment, most people don’t think to define the TRAVIS\_HOME environment variable. The solution for me was to update my Tox configuration to whitelist TRAVIS\_HOME so it gets passed to my tests. That’s fixed most of the errors, but there are still a few calls within my code that make additional calls to a shell, which are harder to fix since there’s no explicitly support for passing through specific environment variables. A better solution would be if Travis just updated their .bashrc so that if TRAVIS\_HOME isn’t defined, then default it to /home/travis. That seems a lot simpler than requiring all users to patch their code. ---
**Author:** ![native-api](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/native-api/32/430_2.png) [@native-api](https://travis-ci.community/u/native-api)\ **Post date:** [June 18, 2019, 12:53am UTC](https://travis-ci.community/t/travis-functions-no-such-file-or-directory/2286/14 "2019-06-18T00:53:20Z")
> [@chrisspen](#): > > Since most people don’t target Travis as their production environment, most people don’t think to define the TRAVIS\_HOME environment variable. Passing through any environment variables that a tool does not specifically manage is standard practice specifically because of this. If `tox` violates this practice, that’s `tox`’s problem. The impact of this violation is not limited to `TRAVIS_HOME`. Any envvar that alters the behavior of any external shell commands used would have the same effect. The implication here is that a local sysadmin knows better than a tool how their system should operate. For behavior consistency purposes that `tox` pursues, tests and the tested software shouldn’t use any non-`tox`-managed envvars, only external software may. Under the current circumstances as you described them, whitelisting the envvar was the right thing AFAICS.