String script args with parenthesis are mangled

[pcrock-thmdo]

Describe the bug

Passing string args with parenthesis to a nushell script can cause the args to be mangled.

How to reproduce

example echo.nu script:

#!/usr/bin/env nu

def main [input: string] {
    print $input
}

here's how it behaves when you run it:

./echo.nu "hi"
# output: hi

./echo.nu "hi(1)"
# output: hi1

Expected behavior

./echo.nu "hi(1)"
# output: hi(1)

Screenshots

No response

Configuration

key	value
version	0.86.0
branch
commit_hash
build_os	linux-x86_64
build_target	x86_64-unknown-linux-gnu
rust_version	rustc 1.72.1 (d5c2e9c34 2023-09-13) (Homebrew)
cargo_version	cargo 1.72.1
build_time	2023-10-17 17:08:20 +00:00
build_rust_channel	release
allocator	mimalloc
features	dataframe, default, sqlite, trash, which, zip
installed_plugins

Additional context

I noticed this when my browser downloaded a file twice, and it added the (1) to the end of the file name just before the extension. i.e. the_file(1).log was mangled into the_file1.log. Passing this file path to a script caused the script to fail because the_file1.log doesn't exist.

[amtoine]

good catch @pcrock-thmdo

i couldn't reproduce this in the REPL nor as a module, so i'd say it's an issue with Nushell scripts, not custom commands or modules 👌

[MarikaChlebowska]

I experimented with it and interestingly ./echo.nu "hi (1)" works as expected. The difference between calling it directly and in a script from what I see if that the variable is put on stack in the second case and on stack it's already without parentheses. I think it's the way arguments are parsed somewhere in low level code but so far I haven't identified where is the logic that needs to be fixed. And also that's a change which can break some things potentially.

[MarikaChlebowska]

I think I found where things go wrong. Before entering parse_string "1232 (1)" (with space) is implicitly transformed to `1232 (1)` which is considered just string and works fine. The version without space has quotation marks stripped and is just 1232(1) which is parsed as StringInterpolation. The only thing I don't know yet is where does the implicit transformation happen but I spent enough time today on this. Also I'm not sure if StringInterpolation parsing is broken or the conversion shouldn't take place.

[MarikaChlebowska]

I finally found it, it's an issue with deparser which should add backticks to non string interpolation values with brackets. I'll post a PR for it soon.