What does "only when sourcing script" mean?

[bartonjs]

Steps to reproduce

curl -sSL https://raw.githubusercontent.com/dotnet/cli/rel/1.0.0-preview2/scripts/obtain/dotnet-install.sh | bash /dev/stdin --version 1.0.0-preview2-002996 --install-dir ~/dotnet

Expected behavior

I understand messages that it prints.

Actual behavior

dotnet-install: Downloading https://dotnetcli.blob.core.windows.net/dotnet/preview/Binaries/1.0.0-preview2-002996/dotnet-dev-centos-x64.1.0.0-preview2-002996.tar.gz
dotnet-install: Extracting zip
dotnet-install: Adding to current process PATH: /home/bb/dotnet. Note: This change will be visible only when sourcing script.
dotnet-install: Installation finished successfuly.

Environment data

dotnet --info output:

 [bb@bb-centos72-3 ~]$ dotnet --info
-bash: dotnet: command not found

Or, more usefully:

[bb@bb-centos72-3 ~]$ ./dotnet/dotnet --info
.NET Command Line Tools (1.0.0-preview2-002996)

Product Information:
 Version:            1.0.0-preview2-002996
 Commit SHA-1 hash:  cff4f37456

Runtime Environment:
 OS Name:     centos
 OS Version:  7
 OS Platform: Linux
 RID:         centos.7-x64

[MartinJohns]

http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/x237.html

As I understand it, when you source it is as if the commands in the script are typed into the bash. That way the change to the PATH variable will be present in the current bash instance - because it was changed in it.

But when you don't "source" the script, it will be executed in a new bash, in a child-process. So the change to the PATH variable will only be present in the child-process (which terminates once done), and not in your current bash.

[bartonjs]

I think mainly I'm confused as to why it's printed at all. And/or it needs a "this" in the message.

[TheRealPiotrP]

@MartinJohns is spot on

@bartonjs what experience do you suggest?

@blackdwarf

[bartonjs]

Since you're presenting information to me: What do you expect me to do with it? If "nothing", don't print it.

Otherwise, notice that the message uses an open "when sourcing script". I can source lots of script(s) that has nothing to do with adding the dotnet install-dir to my $PATH. If the message has an interesting value that I'm not seeing, it needs to change from an open qualifier (suggesting you've somehow patched bash) to a closed qualifier, such as "when sourcing this script".

But, really, I can't see what the purpose for the message is. A reader of the script? Then make it a comment, not an echo.

[JohnRusk]

I completely agree. It confused me two. I think two changes are needed.

1. Add the word "this" @bartonjs said above. So that it's clear that its talking about sourcing "this" script. However, that's actually too late, because by the time you see it, you've already run the script. So
2. Get the documentation changed, here: https://docs.microsoft.com/en-us/dotnet/articles/core/tools/dotnet-install-script That page quite clearly says "By default, the script will modify the PATH, which makes the CLI tools available immediately after install." But in reality none of examples on the page actually do that, because none of them source the script. It should be changed to say "If your source the script, the script will modify the PATH, which makes the CLI tools available immediately after install."
   and an example like this should be added, with a comment to say that these examples will modify the path
   . ./dotnet-install.sh --channel Future
   or
   source ./dotnet-install.sh --channel Future

[krwq]

@JohnRusk you're right - I'm not native speaker and despite knowing the theory I really have to focus hard to spot the difference between "a", "the", "this" or no article 😉

My 2c - I think we should not set the PATH at all in the script (and remove that sentence) - when you source the dotnet-install.sh you also do set -e which is later closing the shell on a first command which ends with non-zero exit code. If we want to set the PATH we should change the one-liner description in the guideliness

[rynowak]

when you source the dotnet-install.sh you also do set -e which is later closing the shell on a first command which ends with non-zero exit code. If we want to set the PATH we should change the one-liner description in the guideliness

It would be really nice to see this addressed. Since the guidance calls out sourcing the script, it shouldn't set options that dirty the shell.

It took me a while to chase down why my shell was exiting on a failed, unrelated command after sourcing dotnet-install.

[bergmeister]

It's 2018 and it still does not add to the path, I tried the chmod +x, executing as bash ./dotnet-install.sh1, etc (see referenced issue 9234 above). Can you not give an example that does work in the message?

[dazinator]

I'm just after a command that I can run on an Ubuntu container to install the dotnet sdk, and then use a dotnet cli commands in the same script.. Nothing on the docs site so far works. For example using this example command from the docs in a DOCKERFILE doesn't seem to do that:

RUN curl -sSL https://dot.net/v1/dotnet-install.sh | bash /dev/stdin -Channel 2.0

[gfoidl]

@dazinator the best way is to set the -InstallDir (see doc) and add this direcotry to the $PATH.

As alternative create a symlink: ln -s $installdir/dotnet /usr/local/bin. Where $installdir is the given installation directory from above.

[dazinator]

@gfoidl I was hoping to use apt-get but there are a few things missing on the sdk 3.0 debian10 based docker image that prevent this from being straightforward.

Here is finally a working DOCKERFILE that shows the issues I had to overcome in order to apt-get dotnet core sdk 2.1 and build a Blazor client / server project. The issues were:

1. sudo is not installed.
2. apt-get install -y dotnet-sdk-2.1 fails becuase of two missing libraries:
   • libicu57_57.1-6+deb9u2_amd64.deb
   • libssl1.0.2_1.0.2r-1~deb9u1_amd64.deb
3. microsoft package sources need to be added.

Dockerfile:

FROM mcr.microsoft.com/dotnet/core/sdk:3.0
ARG BUILD_CONFIGURATION=Debug
ENV ASPNETCORE_ENVIRONMENT=Development
ENV DOTNET_USE_POLLING_FILE_WATCHER=true
EXPOSE 80

WORKDIR /src

RUN apt-get update && apt-get install -y sudo

RUN wget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.asc.gpg
RUN sudo mv microsoft.asc.gpg /etc/apt/trusted.gpg.d/
RUN sudo chown root:root /etc/apt/trusted.gpg.d/microsoft.asc.gpg

RUN wget -q https://packages.microsoft.com/config/debian/9/prod.list
RUN sudo mv prod.list /etc/apt/sources.list.d/microsoft-prod.list
RUN sudo chown root:root /etc/apt/sources.list.d/microsoft-prod.list

RUN sudo apt-get update

# dotnet sdk 2.1 dependencies fail to install with apt-get unless this libraries are installed manually first.
RUN wget http://debian.mirrors.uk2.net/pool/main/i/icu/libicu57_57.1-6+deb9u2_amd64.deb
RUN wget http://debian.mirrors.uk2.net/pool/main/o/openssl1.0/libssl1.0.2_1.0.2r-1~deb9u1_amd64.deb

RUN dpkg -i libicu57*.deb
RUN dpkg -i libssl1.0.2*.deb

# Now we can atleast install dotnet sdk 2.1
RUN sudo apt-get install -y dotnet-sdk-2.1

# Finally we can build a blazor server project that references a blazor client project.
COPY ["Hub.Platform.Client/Hub.Platform.Client.csproj", "Hub.Platform.Client/"]
COPY ["Hub.Platform.Core/Hub.Platform.Core.csproj", "Hub.Platform.Core/"]
COPY ["Hub.Platform.Server/Hub.Platform.Server.csproj", "Hub.Platform.Server/"]
COPY ["Hub.Platform.Shared/Hub.Platform.Shared.csproj", "Hub.Platform.Shared/"]

# I install the blazor templates, not absolutely sure certain this is necessary.
RUN dotnet new -i Microsoft.AspNetCore.Blazor.Templates::3.0.0-preview5-19227-01
RUN dotnet restore "Hub.Platform.Server/Hub.Platform.Server.csproj"
COPY . .
WORKDIR "/src/Hub.Platform.Server"
RUN dotnet build --no-restore "Hub.Platform.Server.csproj" -c $BUILD_CONFIGURATION

RUN echo "exec dotnet run --no-build --no-launch-profile -c $BUILD_CONFIGURATION --" > /entrypoint.sh

ENTRYPOINT ["/bin/bash", "/entrypoint.sh"]

[gfoidl]

Aside: your dockerfile has too many layers. See Best practices for writing Dockerfiles -- Minimize the number of layers.

---

Try something like this:

FROM mcr.microsoft.com/dotnet/core/sdk:3.0

RUN curl https://dot.net/v1/dotnet-install.sh > dotnet-install.sh && chmod +x *.sh \
&&  ./dotnet-install.sh -Channel 2.0 -InstallDir /usr/share/dotnet \
&&  rm *

So

root@6931308c0a7b:/src# dotnet --list-sdks
2.1.202 [/usr/share/dotnet/sdk]
3.0.100-preview5-011568 [/usr/share/dotnet/sdk]
root@6931308c0a7b:/src#

[dazinator]

@gfoidl even though that seems to successfully install, it still yield a failure from razor during the build:

RAZORTAGHELPER : Failed to load hF�, error : libunwind.so.8: cannot open shared object file: No such file or directory [/src/Hub.Platform.Core/Hub.Platform.Core.csproj]
5 Warning(s)
1 Error(s)
Time Elapsed 00:00:24.97
The command '/bin/sh -c dotnet build --no-restore "Hub.Platform.Server.csproj" -c $BUILD_CONFIGURATION' returned a non-zero code: 1

Something about the non-optimised version I have shown, results in some difference that allows this build to succeed. Perhaps the apt-get approach results in additional tools being installed? no idea. I have just about run out of time debugging this issue now.