is env variable referencing supported?

Same here. I'd like to define the secret reference as part of some string in the .env file.

.env file

env
GITHUB_TOKEN="op://foo/bar/token"
DENO_AUTH_TOKENS="${GITHUB_TOKEN}@raw.githubusercontent.com"


error

txt
[ERROR] 2023/12/22 12:57:07 invalid secret reference 'op://foo/bar/token@raw.githubusercontent.com': invalid character in secret reference: '@'


I've stumbled on this thread because I'm having the same issue, and after trying numerous different approaches, I'm left wondering why this doesn't work.

Let's start with a simple example that uses https://developer.1password.com/docs/cli/secrets-template-syntax#enclosed-secret-references:

.env


DATABASE_URL="http://{{op://private/my_app/username}}:{{op://private/my_app/password}}@localhost:1234"


Checking this with op inject returns the expected result, with the two secret refs replaced with the values "bob" and "secret" respectively; but running through op run and printenv doesn't:

```
$ op inject -i .env
DATABASE_URL="http://bob:secret@localhost:1234"

$ op run --env-file=.env --no-masking -- printenv DATABASE_URL
http://{{op://private/my_app/username}}:{{op://private/my_app/password}}@localhost:1234
```

So it seems that constructing an ENV value by embedding enclosed secret refs into a string doesn't work.

Let's try a different approach using multiple ENV vars:

.env


USERNAME="op://private/my_app/username"
PASSWORD="op://private/my_app/password"
DATABASE_URL="http://${USERNAME}:${PASSWORD}@localhost:1234"


```
$ op inject -i .env

USERNAME=bob
PASSWORD=secret
DATABASE_URL="http://${USERNAME}:${PASSWORD}@localhost:1234"

$op run --env-file=.env --no-masking -- printenv USERNAME
bob

$op run --env-file=.env --no-masking -- printenv PASSWORD
secret

$ op run --env-file=.env --no-masking -- printenv DATABASE_URL
http://op://private/my_app/username:op://private/my_app/password@localhost:1234
```

Again, we can see that op inject seems to have correctly substituted the USERNAME and PASSWORD values, and left DATABASE_URL unchanged (with the assumption that they would be correctly expanded when a process tries to read $DATABASE_URL).

We can also see that op run has correctly resolved the USERNAME and PASSWORD vars, but now DATABASE_URL has been substituted with....the secret refs?

(I've tried this this with/without quotes, with/without curly braces etc. Nothing seems to work).

One more, just to really confuse things:

.env


USERNAME="op://private/my_app/username"
PASSWORD="op://private/my_app/password"
DATABASE_USERNAME="${USERNAME}"
DATABASE_PASSWORD="${PASSWORD}"


```
$ op inject -i .env
USERNAME="bob"
PASSWORD="secret"
DATABASE_USERNAME="${USERNAME}"
DATABASE_PASSWORD="${PASSWORD}"

$ op run --env-file=.env --no-masking -- printenv DATABASE_USERNAME

bob

$ op run --env-file=.env --no-masking -- printenv DATABASE_PASSWORD
secret
```

Wait, what? That works?

Here we have two ENV vars ($DATABASE_USERNAME and $DATABASE_PASSWORD) that reference to other ENV vars ($USERNAME and $PASSWORD) that are using secret refs....and it all works fine?

The difference here seems to be referencing a $VAR on its own ("${USERNAME}") is fine, but referencing it inside a string ("xx${USERNAME}") is not?

It seems like this should all just work.

````shell
$ op run --env-file=.env --no-masking -- printenv DATABASE_URL | op inject

````

if the completion is pushed to op inject the references will be completed. I am not sure env variables are intended to be used that way. Cause i believe they are read "as is".