August 15, 2025

If you start a non-interactive bash shell it will source the content of the file defined in BASH_ENV (and ENV for a POSIX shell).

When bash is started non-interactively, to run a shell script, for example, it looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute. Bash behaves as if the following command were executed:

if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi

but the value of the PATH variable is not used to search for the file name.

The YAML anchors to name a reusable section are defined by &name and then to use them to replace the value of something you do *name, if you want to “unsplat”/merge a dictionary/object then use <<: *name and then it’ll insert it at that point.

world: &world World
example: &example-anchor
  HELLO: *world
  There: Yo

my-values:
  <<: *example-anchor
  foo: bar

becomes

---
example:
  HELLO: World
  There: Yo
my-values:
  HELLO: World
  There: Yo
  foo: bar

YAML does not support unsplatting lists (basically, merging list items inline like you can with objects) and that’s intentional.

So if you have a document like below, there is no syntax to make the commands a three item list:

---
example: &example
  - "Hello"
  - "World!"

name: "hello"
commands:
  - << *example
  - "Oho!"

WILL NOT turn into:

---
example: &example
  - "Hello"
  - "World!"

name: "hello"
commands:
  - "Hello"
  - "World!"
  - "Oho!"

…and just because before I found the issue where it was described that this isn’t happening I had made a test repo to try and understand if it was a library/usage issue, because I noticed I could get things running on CI with << *example which syntax didn’t give syntax error, but also did nothing when running on Drone CI.