Repository navigation
What does "only when sourcing script" mean? #683
Description
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
Activity
MartinJohns commentedon Jun 10, 2016
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 commentedon Jun 10, 2016
I think mainly I'm confused as to why it's printed at all. And/or it needs a "this" in the message.
TheRealPiotrP commentedon Jun 10, 2016
@MartinJohns is spot on
@bartonjs what experience do you suggest?
@blackdwarf
bartonjs commentedon Jun 10, 2016
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 commentedon Apr 17, 2017
I completely agree. It confused me two. I think two changes are needed.
and an example like this should be added, with a comment to say that these examples will modify the path
. ./dotnet-install.sh --channel Futureor
source ./dotnet-install.sh --channel Futurekrwq commentedon Apr 17, 2017
@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 -ewhich 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 guidelinessrynowak commentedon May 31, 2017
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 commentedon May 9, 2018
It's 2018 and it still does not add to the path, I tried the
chmod +x, executing asbash ./dotnet-install.sh1, etc (see referenced issue 9234 above). Can you not give an example that does work in the message?dazinator commentedon Jun 5, 2019
I'm just after a command that I can run on an Ubuntu container to install the dotnet sdk, and then use a
dotnetcli 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:gfoidl commentedon Jun 5, 2019
@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$installdiris the given installation directory from above.dazinator commentedon Jun 5, 2019
@gfoidl I was hoping to use
apt-getbut 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:
sudois not installed.apt-get install -y dotnet-sdk-2.1fails becuase of two missing libraries:Dockerfile:
gfoidl commentedon Jun 5, 2019
Aside: your dockerfile has too many layers. See Best practices for writing Dockerfiles -- Minimize the number of layers.
Try something like this:
So
dazinator commentedon Jun 5, 2019
@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 commentedon Jun 5, 2019
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 commentedon Jun 5, 2019
The
rm *is there to delete the downloadeddotnet-install.sh. But this can be specified -- i.e. without the wildcard, so it becomesrm dotnet-install.sh(I was just lazy).ggirard07 commentedon Oct 12, 2021
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 commentedon Oct 10, 2024
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
-InstallDirparam to a directory already present in the PATH, obviously 🤦♂ Hope it helps if that’s possible for you.dazinator commentedon Oct 10, 2024
@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.