To see problem, use this:
using System;
class Program
{
static void Main(string[] args)
{
for(var i = 0; i < args.Length; i++)
{
Console.WriteLine($"{i} = {args[i]}");
}
}
}
Execute dotnet run a b '" c "' d
Output should be:
0 = a
1 = b
2 = " c "
3 = d
0 = a
1 = b
2 = "
3 = c
4 = "
5 = d
Repros in preview2 and preview3 nightlies, bash on Linux and OSX
dotnet --info output:
.NET Command Line Tools (1.0.0-preview3-003546)
Product Information:
Version: 1.0.0-preview3-003546
Commit SHA-1 hash: c0c07ed959
Runtime Environment:
OS Name: ubuntu
OS Version: 14.04
OS Platform: Linux
RID: ubuntu.14.04-x64
The problem appears to be somewhere in CLI. Using dotnet exec does not have this problem.
namc@ubuntu:/tmp/quoted$ dotnet exec --depsfile bin/Debug/netcoreapp1.0/quoted.deps.json --runtimeconfig bin/Debug/netcoreapp1.0/quoted.runtimeconfig.json bin/Debug/netcoreapp1.0/quoted.dll a b '" c "' d
0 = a
1 = b
2 = " c "
3 = d
cc @brthor
@natemcmaster What shell are you using, bash?
Repros on bash and zsh, Linux and macOS.
Moving to the backlog for the moment as we can work around this using dotnet path/to.dll. I'd love to fix it but we need to focus on issues with no workarounds :-/
@natemcmaster if this IS blocking something, please let me know and we can repriorotize
I'm currently encountering this issue on ArchLinux using zsh, bash and sh. dotnet --info puts me at version 2.2.100 for the sdk and 2.2.0 for the host version.
î‚° dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 2.2.100
Commit: b9f2fa0ca8
Runtime Environment:
OS Name: arch
OS Version:
OS Platform: Linux
RID: arch-x64
Base Path: /opt/dotnet/sdk/2.2.100/
Host (useful for support):
Version: 2.2.0
Commit: 1249f08fed
.NET Core SDKs installed:
2.2.100 [/opt/dotnet/sdk]
.NET Core runtimes installed:
Microsoft.NETCore.App 2.2.0 [/opt/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download
Using the 3.0.100-preview-009752 fixes the issue.
Hi @Vogel612,
I'm unable to reproduce this issue with either 2.2.100 or 2.2.101 (the most recent SDK version), at least on macOS. Unfortunately I'm far away from my Arch system (which is powered down), but I can try to reproduce it in a VM if you like.
The fix should have made it into 2.1.300 and I see it tagged all the way through to the current release.
Also experiencing this issue on Arch linux. Works correctly on macOS, Ubuntu, Debian with 2.2.100. Failing only on Arch.
@externl What shell are you using?
@peterhuene Using Bash 5.0.0
GNU bash, version 5.0.0(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2019 Free Software Foundation, Inc.
I tried Bash 5.0.0 on macOS and everything works correctly.
ZSH (5.6.2) on Arch fails as well.
@peterhuene testing with a simple programs that just print the argugments
archlinux% dotnet bin/Debug/netcoreapp2.2/test.dll "h x a"
ARG 0 h
ARG 1 x
ARG 2 a
archlinux% cat Program.cs
using System;
namespace test
{
class Program
{
static void Main(string[] args)
{
for(int i = 0; i < args.Length; i++)
{
System.Console.WriteLine("ARG {0} {1}", i, args[i]);
}
}
}
}
Thanks for the test case. I'll take a look on my arch system now.
The issue on Arch Linux is how dotnet is being packaged.
It's installing .NET Core into a non-standard location of /opt/dotnet/dotnet and then using a shell script at /usr/bin/dotnet to invoke /opt/dotnet/dotnet after setting DOTNET_ROOT to point at /opt/dotnet/dotnet. This shell script does not preserve the quotes when forwarding the arguments to /opt/dotnet/dotnet.
Possible workarounds:
/opt/dotnet/dotnet to invoke (e.g. /opt/dotnet/dotnet run foo "bar baz")./usr/bin/dotnet and change $@ to "$@" to preserve the quotes.An issue should be filed with the Arch Linux bug tracker for the community/dotnet-host package regarding fixing the /usr/bin/dotnet wrapper script.
reported against the arch bugtracker as https://bugs.archlinux.org/task/61427
Is that wrapper script even needed? According to your suggestion to run /opt/dotnet/dotnet directly, I would expect a symlink to work without the need to set a variable indicating the root of the runtime installation. For relocatable programs, detecting the root on its own is the ideal solution.
Ideally DOTNET_ROOT should be set to allow applications that launch via an apphost to locate the .NET Core runtime that is installed to a non-default location. In 2.2 you can publish a .NET Core application as RID-specific (i.e. "platform-specific") "framework-dependent" (as opposed to "self-contained") and get a native executable that can start the .NET application so that you don't need to use dotnet. The environment variable would let that framework-dependent executable know where to find the runtime.
Technically setting the environment variable isn't required to start dotnet itself since it can find the runtime relative to its location. However, imagine a scenario where dotnet build execs another process that needs to find the non-default location of the runtime. Without DOTNET_ROOT set it would not start correctly.
There was some debate as to whether or not the SDK should set DOTNET_ROOT inside the dotnet process for child processes to respect, but there were some concerns there that ultimately resulted in the SDK not doing so.
That said, I'd probably recommend the script in this case to ensure that every process started by dotnet can properly locate the runtime at its non-default location.
Most helpful comment
The issue on Arch Linux is how
dotnetis being packaged.It's installing .NET Core into a non-standard location of
/opt/dotnet/dotnetand then using a shell script at/usr/bin/dotnetto invoke/opt/dotnet/dotnetafter settingDOTNET_ROOTto point at/opt/dotnet/dotnet. This shell script does not preserve the quotes when forwarding the arguments to/opt/dotnet/dotnet.Possible workarounds:
/opt/dotnet/dotnetto invoke (e.g./opt/dotnet/dotnet run foo "bar baz")./usr/bin/dotnetand change$@to"$@"to preserve the quotes.An issue should be filed with the Arch Linux bug tracker for the
community/dotnet-hostpackage regarding fixing the/usr/bin/dotnetwrapper script.