Closed qualiaMachine closed 2 years ago
Thanks for highlighting this @qualiaMachine. I assume you're referring specifically to using Windows here? I know Git Bash is recommended for use in the Carpentries shell lesson since it's the most straightforward way to get access to a Bash shell on Windows.
Can you provide some more information regarding the problem with /etc/os-release
not being present in the context of the docker lesson material? I may be missing the context of this suggestion so apologies if that's the case.
I'd be happy to clarify. In episode 3 (03-running-containers.md), the following command is used:
docker run alpine cat /etc/os-release
This is the command that fails when using Git Bash. Hope this helps.
Thanks for the clarification @qualiaMachine, I see what you're referring to now. 🙂
I don't actually think this should be an issue since the point of this is example is to demonstrate the running of the cat /etc/os-release
command within the Alpine Linux container, where the /etc/os-release
file will exist. This will be the case regardless of where you're executing the docker run
command from.
I've never actually run docker from within a Git Bash shell on Windows but I'm assuming that if you have Docker Desktop installed on Windows (I assume this provides a command line docker
executable in addition to the GUI as the macOS version does) and you have your Git Bash environment set up so that the docker executable is accessible in the PATH
then you should be able to run docker run alpine cat /etc/os-release
.
I hope that makes sense. If you've tried to do this and it's not working, let us know, it would be useful to investigate in case I'm missing something here. Thanks.
@qualiaMachine did you have problems running the cat /etc/os-release command in the container (as Jeremy describes above)? or was it just not correct when run in the default git bash shell (which is fine)?
The problem is that git bash has a feature that interprets any paths you write into windows paths. So the /etc/os-release
gets rewritten as something like C:\etc\os-release\
prior to running the container and that path doesn't work inside the container. We did discuss this at the 2021 Oct Sprint. There is an option you can enable for the session (or forever) that gets around this. More here
Would including documentation in the setup instructions regarding how to disable the Git Bash path rewriting be sufficient to allow Git Bash users to use Docker practically (including our example command invocation)? Or would it be better to advise against using Git Bash to drive command-line Docker in any case? I'm not a Git Bash user, so can't provide a view from my own experience.
I think it would be good to instead include how to turn off the path interpretation while using docker for those that use gitbash instead of not having users use gitbash.
In setup.md, we should add a warning to prevent users from using git bash. The following command does not work in git bash: cat /etc/os-release
This is because git bash has its own local etc folder, and tries to look there to run the function.