FS#61427 - [dotnet-host] argument quotation when invoking /usr/bin/dotnet

Attached to Project: Community Packages
Opened by why do you care? (Vogel612) - Wednesday, 16 January 2019, 12:36 GMT
Last edited by Maxime Gauduin (Alucryd) - Thursday, 17 January 2019, 22:25 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Maxime Gauduin (Alucryd)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Quoted arguments are not correctly handled by dotnet-cli on arch with dotnet-host 2.2.0+100-1

This was discovered when reporting a regression against dotnet-cli upstream. https://github.com/dotnet/cli/issues/4139

Upstream developers determined that the current packaging behaviour for `dotnet` is the root cause for incorrect handling of quoted arguments.

Steps to reproduce:

$ dotnet new console
// change generated Program.cs to echo the arguments on separate lines
// eg:
- Console.WriteLine("HelloWorld!");
+ for (int i = 0; i < args.Length; i++)
+ {
+ Console.WriteLine($"ARG {i} {args[i]}");
+ }
$ dotnet run "h x a"
ARG 0 h
ARG 1 x
ARG 2 a

The expected behaviour would be the output:

$ dotnet run "h x a"
ARG 0 h x a

Repro steps adapted from github thread.

According to @peterhuene the solution is to replace $@ with "$@" in the /usr/bin/dotnet wrapper script
This task depends upon

Closed by  Maxime Gauduin (Alucryd)
Thursday, 17 January 2019, 22:25 GMT
Reason for closing:  Fixed
Additional comments about closing:  2.2.1+102-1
Comment by Eli Schwartz (eschwartz) - Wednesday, 16 January 2019, 18:21 GMT
  • Field changed: Summary (argument quotation when invoking /usr/bin/dotnet is not carried over to /opt/dotnet/dotnet → [dotnet-host] argument quotation when invoking /usr/bin/dotnet)
  • Field changed: Status (Unconfirmed → Assigned)
  • Task assigned to Maxime Gauduin (Alucryd)
What is the wrapper script needed for? One of the possible workarounds suggested by the upstream issue is to use /opt/dotnet/dotnet directly -- does this mean it is fully relocatable and we can just use a symlink?
Comment by Eli Schwartz (eschwartz) - Wednesday, 16 January 2019, 18:52 GMT
Never mind, according to upstream it's advised so recursive child processes can find the location...

Loading...