[Bug]: Error: couldn't get client config: While parsing config: toml: expected newline but got U+0022 '"'

[taitruong]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

I'm using v17.1.1 and did this:

export OUTPUT="json"
OUTPUT='{"":""}'
gaiad config node test

Now gaiad config throws this error:

Error: couldn't get client config: While parsing config: toml: expected newline but got U+0022 '"'

And now in client.toml this has changed to : output = "{"":""}"

Cosmos SDK Version

gaia v17.1.1

How to reproduce?

See description above, basically did this in shell:

export OUTPUT="json"
OUTPUT='{"":""}'
gaiad config node test

[julienrbrt]

Hi,
Why would you set output to '{"":""}'?
Can you reproduce with a maintained version of the SDK? (v0.47 or v0.50)?

[taitruong]

Hi, Why would you set output to '{"":""}'? Can you reproduce with a maintained version of the SDK? (v0.47 or v0.50)?

Basically it is a name class. My script was using OUTPUT and wasn't aware CLI uses same var. As stated in juno issue (CosmosContracts/juno#866) it should be prefixed. Like "JUNOD_OUTPUT" resp. "GAIAD_OUTPUT".

I dunno how to figure out which SDK version e.g. gaia v17.1.1 is using. But my guess is, that bug is even on main - just execute above 3 lines in shell :).

[Reecepbcups]

^ Juno is SDK v47, Gaia is a modified SDK v45

our prefixes work (ex: JUNOD_NODE) but output is different it seems

[julienrbrt]

our prefixes work (ex: JUNOD_NODE) but output is different it seems

Well, they always work for both, viper reads the prefix or the env without prefix:
e.g:

NODE=https://uni-rpc.reece.sh:443 junod tx bank send alice $(junod keys show alice -a --keyring-backend test) 10ujuno --keyring-backend test
JUNOD_NODE=https://uni-rpc.reece.sh:443 junod tx bank send alice $(junod keys show alice -a --keyring-backend test) 10ujuno --keyring-backend test
junod_NODE=https://uni-rpc.reece.sh:443 junod tx bank send alice $(junod keys show alice -a --keyring-backend test) 10ujuno --keyring-backend test

So here it makes sense for OUTPUT as well.

Maybe viper is misconfigured on our side 🤔 but I think it has been working like this since forever (at least there hasn't been change in the code for a while).

[julienrbrt]

Took a brief look, and that fallback isn't the normal viper behavior.