Open bartonjs opened 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.
I think mainly I'm confused as to why it's printed at all. And/or it needs a "this" in the message.
@MartinJohns is spot on
@bartonjs what experience do you suggest?
@blackdwarf
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.
I completely agree. It confused me two. I think two changes are needed.
. ./dotnet-install.sh --channel Future
or
source ./dotnet-install.sh --channel Future
@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
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.
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?
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
@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.
@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:
sudo
is not installed.apt-get install -y dotnet-sdk-2.1
fails becuase of two missing libraries:
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"]
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 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.
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.
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).
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!
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.
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.
Steps to reproduce
I understand messages that it prints.
Actual behavior
dotnet --info
output:Or, more usefully: