The Docker extension for VS-code attaches /bin/sh to your containers by default. The settings file confirms this:
"docker.attachShellCommand.linuxContainer": "/bin/sh"
I have changed this in the settings editor of VS-code to attach to bash instead:
"docker.attachShellCommand.linuxContainer": "/bin/bash"
I expected to get /bin/bash as CLI when attaching to the container. Instead, it still attached me to /bin/sh.
In the meantime, I'm a day further and the behaviour of my shell has changed to the behaviour of /bin/bash. This is confusing.
After even more experimenting, I found out that I have a problem with the Chrome cache. I installed a clear-cache button in Chrome, which allowed me to clear the cache whenever I suspected this problem. Now I am in control. I did nothing wrong with the settings.
Question answered. :-)
I've had similar issues trying to use:
"docker.attachShellCommand.linuxContainer": "/bin/bash"
Getting and error:
"The terminal process failed to launch: Path to shell executable "/bin/bash" does not exist.
Ended up reverting back to:
"docker.attachShellCommand.linuxContainer": "/bin/sh"
Related
I have installed Anaconda under Windows and Ubuntu under WSL. I have not used this Ubuntu installation for a long time. When I tried to run Ubuntu now, I saw the following:
That is, WSL starts a Jupyter Notebook server, which I have to kill by hitting Ctrl-C to get the Ubuntu prompt. What could be causing this behavior?
There are several ways for something to "autostart" when running WSL:
First, you (or an application) may have modified your startup scripts to start the Jupyter Notebook server. To see if this is the case, try starting WSL from PowerShell by running:
wsl -e bash --noprofile --norc
This will run bash without the startup scripts. If this brings you to the prompt without running the notebook sesrver, then the problem is in your ~/.bashrc or ~/.bash_profile (assuming bash is your default shell).
Given the symptoms you are seeing, this is the most likely cause. If that's the case, look in those files to see if you can find the line that is starting the server, and comment it out.
Second, and related to the first, do you recall trying to enable Systemd at any point using something like Genie or WSL2Hacks? If so, then I believe they modify your start scripts to run Systemd, which can be used to start other services. However, I would expect those Systemd-executed services to start daemonized, in the background, and not interrupt your shell's startup.
Under Windows 11, services can also be autostarted via /etc/wsl.conf, but again, they would be started by the root user in this case, and in the background. I can't think of a non-pathological way that this could be used to interrupt the user's startup shell experience.
I am using PyCharm 2019.3.3 (Community Edition) on Windows 8. I wanted to integrate Git bash in the PyCharm terminal. I have set the shell path in the terminal application settings of PyCharm as
C:\Program Files\Git\bin\bash.exe
The problem occurs when I activate a venv virtual ennvironment, set up using
python -m venv env
by running
source env/Scripts/activate
I think env is active as I see two parenthesis, () and typing pip freeze displays all installed packages in env. But this is accompanied with an error message that displays in the terminal
bash: basename: command not found
This same message is logged after typing commands like ls, clear which doesn't work but pip freeze and pip --version work. And when I deactivate env, ls, clear and pip stopped working displaying the mentioned error message.
All this problems do not occur in the Git bash application for Windows irrespective of whether I am in env or global environment and all commands work properly. I know I can just use Git bash instead of the integrated terminal of PyCharm but just wanted an answer to this problem.
What seems to be the problem here? Am I setting up my shell path wrongly or is this problem specific to PyCharm?
I solved this issue by disabling "Activate Virtualenv" checkbox in File -> Settings -> Tools -> Terminal
Since, pycharm documents does not show any support for 'Git Bash', that is probably the reason for this weird behaviour.
Terminal Options in Pycharm
This happened right after I tried to install pyenv and then virtualenvrapper.
As soon as I open iTerminal I get a "Broken Pipe" message and macOS terminal also shuts down immediately.
I have been trying to debug my .bash_profile but uncommenting one after another but without avail
I tried updating homebrew and bash but no change (using a previously open iterm session)
I restarted my computer with the unfortunate effect that I can't access iterm or terminal now (all old sessions closed)
I am quite at loss here now, I have no clue why this happened and how to go about fixing it without having a functioning terminal.
I'd appreciate any advice or pointers.
Following #user1934428 advice I added set -x to all the bash startup files, unfortunately was still met with the same problem. Changing the startup shell in the terminal preferences didn't work.
Thankfully when using emacs ansi-term I was able to get some information/feedback message:
The default interactive shell is now zsh.
To update your account to use zsh, please run chsh -s /bin/zsh.
For more details, please visit https://support.apple.com/kb/HT208050.
Following the link I found that default shell has been changed to zsh Catalina. So I went and followed the instructions on the support page and changed the default shell back to bash, which fixed the problem. I am not quite sure why this problem occurred initially since the Broken Pipe Error appeared before I updated to Catalina.
Anyways changing the default shell back to bash shell fixed everything
I've been working with Docker for Windows, attempting to create a Windows Container that can run cygwin as the shell within the container itself. I haven't had any luck getting this going yet. Here's the Dockerfile that I've been messing with.
# escape=`
FROM microsoft/windowsservercore
SHELL ["powershell", "-command"]
RUN Invoke-WebRequest https://chocolatey.org/install.ps1 -UseBasicParsing | Invoke-Expression
RUN choco install cygwin -y
RUN refreshenv
RUN [Environment]::SetEnvironmentVariable('Path', $env:Path + ';C:\tools\cygwin\bin', [EnvironmentVariableTarget]::Machine)
I've tried setting the ENTRYPOINT and CMD to try and get into cygwin, but neither seems to do anything. I've also attached to the container with docker run -it and fired off the cygwin command to get into the shell, but it doesn't appear to do anything. I don't get an error, it just returns to the command prompt as if nothing happened.
Is it possible to run another shell in the Windows Container, or am I just doing something incorrectly?
Thanks!
You don't "attach" to a container with docker run: you start a container with it.
In your case, as seen here, docker run -it is the right approach.
You can try as an entry point using c:\cygwin\bin\bash, as seen in this issue.
As commented in issue 32330:
Don't get me wrong, cygwin should work in Docker Windows containers.
But, it's also a little paradoxical that containers were painstakingly wrought into Windows, modeled on containers on Linux, only for people to then want to run Linux-utils in these newly minted Docker Windows containers...
That same issue is still unresolved, with new case seen in May and June 2018:
We have an environment that compiles with Visual Studio but still we want to use git and some very useful commands taken from linux.
Also we use of-the-shelve utilities (e.g. git-repo) that uses linux commands (e.g. curl, grep,...)
Some builds require Cygwin like ICU (a cross-platform Unicode based globalization library), and worst: our builds require building it from source.
You can see an example of a crash in MSYS2-packages issue 1239:
Step 5/5 : RUN "C:\\msys64\\usr\\bin\\ls.exe"
---> Running in 5d7867a1f8da
The command 'cmd /S /C "C:\\msys64\\usr\\bin\\ls.exe"' returned a non-zero code: 3221225794
This can get more information on the crash:
PS C:\msys64\usr\bin>
Get-EventLog -Index 28,29,30 -LogName "Application" | Format-List -Property *
The workaround was:
PS > xcopy /S C:\Git C:\Git_Copy
PS > C:\Git_Copy\usr\bin\sh.exe --version > v.txt
PS > type v.txt
As mentioned in that thread, the output gets lost somewhere in the container, thus sending it to a text file.
After playing with it for a long time, my findings were the following:
If your Cygwin utilities are crashing your container, you need to use process isolation. See https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility for the requirements (essentially you need to use Windows Server 2016 and a build-matching Docker Image). I spent some time trying to understand the reason why hyper-v isolation doesn't work and so far I didn't come to any conclusion;
If your Cygwin utilities apparently do nothing - but they don't crash the container - you need to remove the -t flag (the -i flag is still ok) or alternatively play with stdout redirection. Apparently there seems to be an issue with MSYS2 when it deals with some pseudo-ttys. You can verify that programs still run if you redirect stdout to a file (e.g. whoami won't output anything when you run it without any stdout redirection, but whoami > out.txt will output the expected result to a file). It might be possible to fix this by replacing the pseudo-tty but I didn't try it. I suspect that the problem is an invalid handle somewhere inside the MSYS2 libs - as other console apps can print things to the terminal - but I didn't verify this.
Hope it helps to all of you having the same problem.
I was able to get a preinstalled (copied from the host) copy of Cygwin to work in a nanoserver-based container with these two steps:
Using Żubrówka's recommendation for no -t in the docker run cmd-line (when running docker interactively)
Copying the host's (Windows Server 2016) kernel32.dll to the container's c:\windows\system32
I found serveral versions of kernel32.dll on my system, and used the one from c:\windows\system32 with md5 hash d8948a7af764f7153b3e396ad44992ff
This also made a large variety of other executables work. Note that without a tty, using the container is even more cumbersome, and the bash shell doesn't render the prompt. However, scripts (via Jenkins, in my case) that rely on cygwin components work fine.
If that doesn't help, try this guide, it helped me a lot. If your windows application (other than cygwin) is legitimately missing DLLs, the instructions in this guide can help. It never occurred to me that SysInternals' procmon.exe can be run on the host and still report events from the container!
I am really enjoying my time with git.
I'm operating on 2 machines with what I thought were pretty similar setups
On my Laptop
When I type "Git help SomeCommand" from the CLI, my laptop launches the html help in my browser and I am free to read up on whatever help element I asked about.
On my Desktop
The CLI responds as if is is going to do the same, but no browser is switched to and no help is launched
What can I do to get my help back on my desktop?
Note: I'm running the bash shell through console2, but this problem appears to affect the default bash shell run via the context menu in explorer just as much.
I just recently had the same problem, browser wouldn't launch.
I'm running Git 1.9.2.msysgit.0 on Windows 8.1. Default browser - Chrome.
None of the solutions above worked for me. But I simply went to the html file in the explorer, and double-clicked it. Windows then asked me what app to use to open it, and I chose chrome.
Now usual git commands work and open the help html files in Chrome.
As mentioned in the msysgit bug report 445:
Git has it's own tool called "git web--browse" that invokes the web-browser.
Set the environment GIT_TRACE to 1 to see what processes are started, and with what
command-lines.
So that can help debugging the issue.
A temporary workaround (which might not be effective in your case) was:
As temporary workaround one can rename all git-<command>.html to git<command>.html in his <Git>\doc\git\html directory.
The git <cmd> --help suggested by Andy seems to have helped though, and must have "reset" something.
You can configure a web browser to be used to open Git's help files independently of the system's default program assigned to open .html files.
To check if it's set and to what value, simply run:
git config web.browser
To set it globally for all repositories, for example to chrome, run:
git config --global web.browser chrome
You can also set it per-repository, in that case run it inside a repository and without the --global parameter:
git config web.browser chrome
It works automatically if the specified browser's executable is in PATH. If it's not, you may set it manually:
git config browser.<name>.path <path-to-browser-executable>
...so for Chrome browser, it may look like the following:
git config browser.chrome.path "c:\Program Files (x86)\Google\Chrome\Application\chrome.exe"
See the documentation for details.
It seems that this bug went away when I upgraded to the latest version of msysgit (1.7.6 from 1.7.3)
I have this problem currently, and the git <cmd> --help technique doesn't fix it.
I have however found that doing
git help -w <cmd>
Will actually open the help file in the browser, so this is a useful workaround.
I had the same problem (browser wouldn't open), then I realized it's probably because our laptops at work are "least privileged access", meaning we're logged into our Windows systems as standard users. But for development work, including the command window I'm doing git commands from, I'm running as a different user who has local admin privileges. So it actually was opening the Chrome browser, just not in my "logged in" desktop session where I could see it.
To work around this, I ran another copy of Chrome as that user (by Shift-Right clicking on Chrome.exe and running it as the same privileged user that my command prompt is running as). Once that instance of Chrome was running on my desktop, I returned to the command prompt and re-ran the "git help " and it properly launched a new tab in that instance of the browser that was running as the same user my command prompt was.
Stab in the dark: I've always done git <cmd> --help. Does that work?
edit: For future reference. This appears to be what fixed the OP's problem. Running git <cmd> --help seemed to have cleared out something so that it works as specified now. If only I knew the how/why of it...
This set up is current, working and the convention.
It's most likely because you are using the default Git that comes with MacOS called Apple Git which is outdated.
run git --version and check against the Git website.
Install Git using brew install git.
To make sure Homebrew installs take precedence over MacOS installs add the usr/local/bin path to your .zshrc or .bash_profile. export PATH=/usr/local/bin:$PATH. (*Btw, you should use this path also for using Python 3 instead of MacOS Python 2.7 and many other applications).
To make sure all of this is activated do source ~/.zshrc or source ~/.bash_profile. Or simply restart Terminal.
Test it. git help -w commit. A browser window will open.