dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.71k stars 1.06k forks source link

What does "only when sourcing script" mean? #6368

Open bartonjs opened 8 years ago

bartonjs commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

TheRealPiotrP commented 8 years ago

@MartinJohns is spot on

@bartonjs what experience do you suggest?

@blackdwarf

bartonjs commented 8 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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.

dazinator commented 5 years ago

oh i'm guessing it's the rm * you've put at the end deleting stuff it shouldn't? I'll give a quick try without that.

gfoidl commented 5 years ago

The rm * is there to delete the downloaded dotnet-install.sh. But this can be specified -- i.e. without the wildcard, so it becomes rm dotnet-install.sh (I was just lazy).

ggirard07 commented 3 years ago

Documentation and script output is still not useful at all, especially for Windows users moving on to Docker and Linux environments... This issue is the closest I found to help me understand what is going on here!

laurentpayot commented 3 weeks ago

I had a similar PATH issue in a Cloudflare pages build process. The PATH couldn’t be modified, even when sourcing the install script. The solution was to set the -InstallDir param to a directory already present in the PATH, obviously 🤦‍♂ Hope it helps if that’s possible for you.

dazinator commented 3 weeks ago

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#

@gfoidl - I forgot to thank you 5 years ago. So thank you for your response at that time, it did help and was much appreciated.