Unable to feed a space to probe-rs --log-format, via .cargo/config.toml

[lure23]

Problem

I noticed that it seems impossible to feed a space to the runner's parameter. Here's what I have tried:

runner = 'probe-rs run --chip=esp32c6 --log-format "{L} {s}"'
-> Running `probe-rs run --chip=esp32c6 --log-format '"{L}' '{s}"' target/riscv32imac-unknown-none-elf/release/examples/nada`

"[...] --log-format '{L} {s}'"
"[...] --log-format \"{L} {s}\""
'[...] --log-format "{L} {s}"'
"[...] --log-format {L}\ {s}"
'[...] --log-format {L}\ {s}'

This seems like a parsing bug. I picked --log-format '{L} {s}' from somewhere on the Internet; it's an advice you are likely to come across. It definitely works with probe-rs - just not when launched via .cargo/config.toml.

Since less surprises is good for DX (and I didn't find an already open issue), I would like someone to have a look.

Work-around:

Do not use spaces:

runner = "probe-rs run --chip=esp32c6 --log-format {L}_{s}"

Steps

Have the runner line in .config/cargo.toml, e.g.

[target.'cfg(all())']   # this works; gives unconditional '[target]'
runner = "probe-rs run --chip=esp32c6 --log-format '{L} {s}'"

Possible Solution(s)

Do not use spaces in runner parameters

Joking. This is not about that. More about eliminating surprises that hurt.

Notes

No response

Version

cargo 1.80.1 (376290515 2024-07-16)
release: 1.80.1
commit-hash: 37629051518c3df9ac2c1744589362a02ecafa99
commit-date: 2024-07-16
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.3 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Ubuntu 24.4.0 (noble) [64-bit]

[weihanglo]

Thanks for the report. This is a known inconvenience. A recent discussion happened in #14381 (comment).

For configuration, target.<cfg>.runner accepts an array as documented. For example,

[target.'cfg(all())']   # this works; gives unconditional '[target]'
runner = ["probe-rs", "run", "--chip=esp32c6", "--log-format", "{L} {s}"]

[lure23]

Ah, I think I'd seen the array trick, but didn't remember.

Perhaps that only runs home the point on least surprises; keeping this issue open. Thanks @weihanglo

[weihanglo]

keeping this issue open

Thanks, though I am going to close this as it is the expected and documented behavior and array is the way to deal with it. Let us know if there is a reason this should be kept open.