cp: unrecognized option: n

[jurschel]

This morning all of my pipelines stopped working and are failing with this error. cp: unrecognized option: n I believe this is coming from the dotnet-install.sh script that is pulled down at runtime when my pipelines run. At the moment all of the pipelines are broken due to this.

GNU bash, version 5.1.16(1)-release (x86_64-alpine-linux-musl)
dotnet-install: Attempting to download using primary link https://dotnetcli.azureedge.net/dotnet/Sdk/3.1.426/dotnet-sdk-3.1.426-linux-musl-x64.tar.gz
dotnet-install: Remote file https://dotnetcli.azureedge.net/dotnet/Sdk/3.1.426/dotnet-sdk-3.1.426-linux-musl-x64.tar.gz size is 123630520 bytes.
dotnet-install: Extracting archive from https://dotnetcli.azureedge.net/dotnet/Sdk/3.1.426/dotnet-sdk-3.1.426-linux-musl-x64.tar.gz
cp: unrecognized option: n
BusyBox v1.[33](https://xxx.com/xxx/-/jobs/8153870880#L33).1 () multi-call binary.
Usage: cp [-arPLHpfilsTu] SOURCE... DEST
Copy SOURCE(s) to DEST
    -a  Same as -dpR
    -R,-r   Recurse
    -d,-P   Preserve symlinks (default if -R)
    -L  Follow all symlinks
    -H  Follow symlinks on command line
    -p  Preserve file attributes if possible
    -f  Overwrite
    -i  Prompt before overwrite
    -l,-s   Create (sym)links
    -T  Treat DEST as a normal file
    -u  Copy only newer files

[baronfel]

Can you provide more information about

• where you are getting the scripts from precisely (the URL?)
• your OS/runtime environment?
• the version of the cp command that you have available on your system?

[rootwyrm]

@baronfel let's go ahead and mark this as a confirmed bug. I discussed with @jurschel and the precise reproduction is on docker:20.10.11 which is alpine 3.14.3, which previously worked.

A super quick reproduction would be:

docker run --rm -it docker:20.10.11 /bin/sh
apk add --no-cache -q curl bash
curl -o dotnet-install.sh https://dotnet-install.sh ; chmod +x ./dotnet-install.sh
./install.sh --channel 3.1 --no-path --verbose

I think the issue is that $override_switch introduced in https://github.com/dotnet/install-scripts/pull/528 is only detecting linux-musl and not the busybox version. busybox 1.33.x needs -u whereas later versions of Alpine using 1.36.x support -n.

[jurschel]

Yes The install script is coming from "https://dot.net/v1/dotnet-install.sh" and is causing the error. Just noticed another pipeline is pulling it from here "https://raw.githubusercontent.com/dotnet/cli/master/scripts/obtain/dotnet-install.sh" and it is not broken.

[baronfel]

"https://raw.githubusercontent.com/dotnet/cli/master/scripts/obtain/dotnet-install.sh"

That version of the script is quite old (the dotnet/cli repo has been archived for years now) - so I'd recommend getting the scripts from the commit before the regression directly via https://github.com/dotnet/install-scripts/blob/45075b846ed408300987a444ac440b77846be101/src/dotnet-install.sh until we get this fixed and release a new version.

@rootwyrm thanks for the details - that should be pretty easy for us to triage and fix.

cc @am11 for a Linux corner-case that I at least wasn't aware of.

@JanProvaznik we should build a matrix of test cases to explicitly check for compatibility, the good news is that many Linux distros we'd want to verify have Docker images that we can use to quickly test.

[rootwyrm]

So some quick additional testing/validation here confirmed that the issue is not necessarily a regression, it's that the test here does not behave as intended on BusyBox 1.33.x.

https://github.com/dotnet/install-scripts/blob/9497f4b1a4598e2780e7f39e6c7ee8a55a6555b5/src/dotnet-install.sh#L972-L979

/ # cp -v
BusyBox v1.33.1 () multi-call binary.

Usage: cp [-arPLHpfilsTu] SOURCE... DEST

Copy SOURCE(s) to DEST

    -a  Same as -dpR
    -R,-r   Recurse
    -d,-P   Preserve symlinks (default if -R)
    -L  Follow all symlinks
    -H  Follow symlinks on command line
    -p  Preserve file attributes if possible
    -f  Overwrite
    -i  Prompt before overwrite
    -l,-s   Create (sym)links
    -T  Treat DEST as a normal file
    -u  Copy only newer files
/ # if cp -u --help >/dev/null 2>&1; then
> echo "-u"
> fi
/ # 

This is because BusyBox doesn't recognize --help (and doesn't even provide it when combined with a flag,) but other distributions do.

[jurschel]

A work around for us has been to upgrade our docker build dind image to 20.10.24 for now. We are out of the ditch! Thanks again.

[am11]

Sorry about that. I am working on making the test robust.