When running the command bash or ubuntu in PowerShell, the Windows-Subsystem-for-Linux is entered, however, the current working dir for PowerShell is not carried across to BASH. Is there a way to implement this functionality?
From your Windows Powershell or Powershell Core window, type bash (or wsl); for example:
Now, later versions of Windows include WSL.exe, which replaces bash.exe. The behavior of both executable is the same on my system. The official documentation for wsl.exe states:
You can read that documentation here. Net-net,
I'm running Windows 10 Build-17763. If you aren't experiencing the same behavior I am, you might be running an older version of WSL. You can determine the version of WSL from your build number.
Related
How can I use unix commands in Gitkraken?
So I've recently picked up coding again, going back to the basics, and when I was learning previously I used windows and installed Git Bash which uses a Unix command-line environment if I'm not mistaken. The Odin Project (the website I am learning to code from) does not support Windows as an operating system when learning to code due to various reasons listed on their website. I believe that Windows is adequate and would like to continue using it instead of using VMware or VirtualBox to 'install' Linux. The only issue I'm having is executing commands using GitKraken. Some of the commands are different, so I was just wondering if there is a way to use Unix commands in GitKraken? At this point, I am just curious if it is possible. I can continue to use Git Bash, however, GitKraken displaying a visual map of my repos is very helpful.
Ex. How to open a file
$ open ./index.html - macOS
$ start index.html - Windows OS
Any help would be appreciated.
I'm new to PowerShell, so this may be a basic oversight.
On windows 10 pro (for development) and Windows Server 2016 (target environment) I have installed the latest released version of PowerShell.
(Get-Host).Version gives Major 6, Minor 1, Build 0, Revision -1.
My first mistake? as a version of PowerShell is already installed by default?
The process I am trying to automate is to share a backup cartridge drive from host physical machines, and access it as a network share for the VMs (Hyper-V) to backup to. In development I'm just using a USB attached drive, but errors are the same in both environments.
I keep getting errors in any of the SMBShare commands :
Get-SmbShare, Remove-SmbShare, New-SMBShare.
The errors are of the format:
"The term 'Get-SmbShare' is not recognized as the name of a cmdlet,
function, script file, or operable program"
I am running Powershell as administrator, and getting the same errors when typing directly, or from running a script.
Is there something I need to add/import to use SMBShare commands ?
PowerShell has fractured; everything up to v5.1 was Windows only, then v6 was made cross-platform by moving it to a new foundation, and that lost a lot of compatibility.
Your easiest way forward is to use PowerShell 5.1, unless you need v6 for some specific feature. Or to use 6 to launch 5.1 and run a script, the same way you might launch Python or VBScript engines to run a script.
But if you are staying with 6, then there is another option - Microsoft have released a WindowsCompatibility Module - still an early release candidate, so not heavily tested. This brings a way to run Windows modules inside PS v6 (only on Windows, not cross platform).
You would need to install it, with this as an administrator:
Install-Module WindowsCompatibility
Then you can:
Import-Module WindowsCompatibility
Import-WinModule SmbShare
Get-SmbShare
I've two Windows machines and both have bash installed. However, they differ in the way bash starts up:
Machine 1:
Typing "bash" starts the bash. Then I can type commands like ls.
Machine 2:
It seems like it starts bash and directly runs ls in it, by only typing "ls". After that it switches back to CMD automatically, like this:
Does anyone know which setting enables the behavior of machine 2? Everything looks the same for me. It's a nice feature and I want to enable it on machine 1 as well.
Bash on Ubuntu on Windows executables (binaries) cannot run from Windows applications such as cmd.exe or PowerShell.exe - Windows doesn't even see them as executable.
The likeliest explanation is that you've installed a separate Unix emulation environment such as GnuWin, which comes with native Windows binaries.
To see the location of your - by definition Windows-native - ls executable, run where ls, which will probably tell you what product it came with, such as
C:\Program Files (x86)\GnuWin32\bin\ls.EXE.
Note that the Ubuntu on Windows binaries are stored in a user-specific manner in
%LOCALAPPDATA%\lxss\rootfs\bin, but that is a moot point, given that you cannot invoke them from Windows.
In Windows 10, there is a built-in Linux subsystem (one of the greatest features of Windows 10). It gives you almost a complete Linux shell for various distributions, and you can almost do anything with it (user mode).
I bet it is installed on your first computer, and you are using that subsystem. In the latest version of this subsystem, you can run both Linux executables and Windows exe files.
I've been using ConEmu x64 on my home computer with Git Bash, and it works well for me.
I recently started a new job and I haven't been able to get them to work together on my new machine.
At first ConEmu would run just fine but wouldn't run git bash, now after a few uninstalls when I try to launch conemu it tries to open and crashes immediately.
Git Bash works on it's own, although it's opening inside MinGW which is different than how it works on my home machine.
I don't know much about the distinction between mingw and git bash but I know mingw comes with git bash on windows.
I'm running Windows 10 on both computers and I've set the corresponding environment variables to be exactly the same using Rapid EE.
How can I launch a bash session within the ConEmu windows, without crash?
Finally fixed my issue - I uninstalled git bash and then the conemu window would stay open. I checked the Settings tab and the terminal was trying to open git bash still, and the path to the file was no longer valid. So after clearing out all the pre-defined tasks, I was able to re-install ConEmu an Git Bash and set the correct path to the git bash .exe. Works just fine now. I definitely appreciate conemu, as a Windows user in a Linux environment it's a super useful tool.
I usually:
unzip https://github.com/git-for-windows/git/releases/download/v2.7.2.windows.1/PortableGit-2.7.2-64-bit.7z.exe anywhere I want,
add the folder to the PATH, and
I am able to call <path\to\git\bin\bash.exe> in a ConEmu session without any issue.
If you do not see "Crash message", than it's improperly to say that ConEmu crashes. If your shell terminates immediately and properly, than ConEmu closes its window by default, and that is normal and expected behavior.
So your question must be rephrased like "Why my bash instance terminates immediately after start". The question does not relate to ConEmu itself.
However, reading ConEmu docs would give you much interesting notes. Especially:
ConEmu -detached
ConEmu -basic
ConEmu -log
ConEmu -? at last!
I'm working on some scripts that use javaps (Linux Java Process Status ).
The majority of the development has been on linux, but now we need to switch to running them on Windows XP via GIT Bash and I get the following response.
$ javaps
/c/Documents and Settings/xxxx/bin/javaps: must be executed on Linux system (found MINGW32_NT-5.1)
Any ideas apart from not switching to windows.
I was not aware of JPS as suggested by Petesh and we can alter the scripts to work with this over javaps on Windows.
Playing with the arguments provides the information we require to be able to use it.