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
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
|
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
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
Comment by
Eli Schwartz (eschwartz) -
Wednesday, 16 January 2019, 18:52 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?
Never mind, according to upstream it's advised so recursive child
processes can find the location...