.NET 10 Shebang Issue: `#!/usr/bin/dotnet` intercepts script arguments as dotnet commands

[StevenTCramer]

.NET 10 Shebang Issue: #!/usr/bin/dotnet intercepts script arguments as dotnet commands

Problem

The enhanced shebang support in .NET 10 Preview 6 (#!/usr/bin/dotnet) incorrectly interprets script arguments as dotnet CLI commands when they match known commands or options. This breaks tools that execute C# scripts with arguments like "list", "build", "run", etc.

Error example:

./script.cs list
# Results in: "Could not execute because the specified command or file was not found"
# Because dotnet tries to execute "dotnet-./script.cs list"

Expected behavior: Arguments should be passed to the script, not interpreted as dotnet commands.

Current Workarounds

Two workarounds exist, but the ideal fix would be for #!/usr/bin/dotnet to work correctly:

1. #!/usr/bin/dotnet -- - The -- prevents argument interception (works perfectly)
2. #!/usr/bin/dotnet run - Mostly works but still intercepts some options like -h

Comparison of Current Behavior

Shebang	Dotnet Commands (list, run)	Options (-v, -h)	All Other Args	Notes
#!/usr/bin/dotnet	❌ Fails	❌ Fails	✅ Works	Should be fixed
#!/usr/bin/dotnet run	✅ Works	⚠️ Some intercepted	✅ Works	Workaround
#!/usr/bin/dotnet --	✅ Works	✅ Works	✅ Works	Best workaround

Reproduction and Testing

I've created a complete test suite demonstrating the issue and workarounds (files attached):

• script-without-run - Shows the broken #!/usr/bin/dotnet behavior
• script-with-run - Shows the #!/usr/bin/dotnet run workaround
• script-with-dashdash - Shows the #!/usr/bin/dotnet -- workaround
• comprehensive-test.sh - Tests all three variants with various arguments
• README.md - Detailed documentation of findings

To reproduce:

chmod +x script-* comprehensive-test.sh

# Test the broken behavior
./comprehensive-test.sh script-without-run

# Test the best workaround
./comprehensive-test.sh script-with-dashdash

The test clearly shows which arguments fail/pass for each shebang variant.

Impact

This issue affects tools that execute C# scripts with arbitrary arguments, especially when those arguments happen to match dotnet CLI commands. The #!/usr/bin/dotnet -- workaround resolves the issue, but ideally #!/usr/bin/dotnet should work correctly without requiring --.

Environment

• .NET 10 Preview 6 (10.0.100-preview.6.24358.103)
• Linux (tested on WSL2)

Related

This issue builds on the closed issue #49871, which documented the problem but didn't provide comprehensive testing or workarounds. This issue provides:

• Complete reproduction test suite
• Documentation of all shebang variants and their behavior
• Working workarounds while the core issue is addressed

The #!/usr/bin/dotnet -- workaround works perfectly, but ideally we shouldn't need the --.

[StevenTCramer]

Attaching test files referenced in the issue description. These files demonstrate the issue and workarounds with all three shebang variants.