This just happened to me now. Here is what I did on my Win7 box:
Fresh re-install Cygwin
Put c:\cygwin\bin in win7 Path
In Win7 Command Prompt (cmd, not in cygwin), try to install Vundle.vim by:
git clone https://github.com/gmarik/Vundle.vim.git %USERPROFILE%/vimfiles/bundle/Vundle.vim
AND got:
fatal: Invalid path '/cygdrive/c/Users/dlittle/C:\Users\dlittel': No such file or directory
Obviously, %USERPROFILE% was NOT interpreted properly. But in the same CMD window, I do:
echo %USERPROFILE%
It gives correct result which is: c:\Users\dlittle>
Any suggestions would be highly appreciated.
Related
I have windows 10 and I want to execute the sh command in the Jenkinsfile from Jenkins pipeline using bash for Ubuntu for windows, but it doesn't work
I have the following stage in my Jenkins pipeline :
stage('sh how to') {
steps {
sh 'ls -l'
}
}
The error message is :
[C:\Program Files (x86)\Jenkins\workspace\pipelineascode] Running shell script
Cannot run program "nohup" (in directory "C:\Program Files (x86)\Jenkins\workspace\pipelineascode"): CreateProcess error=2, Le fichier spécifié est introuvable
I tried changing Jenkins parameter->shell executable with
C:\Windows\System32\bash.exe
but same error...
how to run sh script using windows 10's bash?
From a very quick search, it looks like your error is related to the following issue : JENKINS-33708
The main cause looks like the sh step is not supported on the Windows. You may use bat or install Cygwin for instance.
Nevertheless two solutions were proposed in the previous link, suggesting you to do the following steps :
Install git-bash
Ensure the Git\bin folder (i.e.: C:\Program Files\Git\bin) is in the global search path, in order for Jenkins to find sh.exe
Make nohup available for Jenkins, doing the following in git-bash (adapt your paths accordingly) :
mklink "C:\Program Files\Git\bin\nohup.exe" "C:\Program Files\git\usr\bin\nohup.exe"
mklink "C:\Program Files\Git\bin\msys-2.0.dll" "C:\Program Files\git\usr\bin\msys-2.0.dll"
mklink "C:\Program Files\Git\bin\msys-iconv-2.dll" "C:\Program Files\git\usr\bin\msys-iconv-2.dll"
mklink "C:\Program Files\Git\bin\msys-intl-8.dll" "C:\Program Files\git\usr\bin\msys-intl-8.dll"
Depending on your installation you may have to use these paths :
mklink "C:\Program Files\Git\cmd\nohup.exe" "C:\Program Files\git\usr\bin\nohup.exe"
mklink "C:\Program Files\Git\cmd\msys-2.0.dll" "C:\Program Files\git\usr\bin\msys-2.0.dll"
mklink "C:\Program Files\Git\cmd\msys-iconv-2.dll" "C:\Program Files\git\usr\bin\msys-iconv-2.dll"
mklink "C:\Program Files\Git\cmd\msys-intl-8.dll" "C:\Program Files\git\usr\bin\msys-intl-8.dll"
With Git for Windows 2.16.2, I was able to add C:\Program Files\Git\usr\bin to the PATH (rather than C:\Program Files\Git\bin) and consequently my sh commands work in both FreeStyle and Pipeline builds. No mklink was necessary. (Source)
If you are executing on Windows, just change sh to bat. it will work as expected.
Example:
pipeline {
agent any
stages {
stage ('Compile Stage') {
steps {
withMaven(maven : 'apache-maven-3.6.1') {
bat'mvn clean compile'
}
}
}
}
}
With Git for Windows, I had to add C:\Program Files\Git\bin to the PATH environment variable of the slave node in Jenkins (to get access to sh), then add C:\Program Files\Git\usr\bin to the PATH locally on the Windows slave too (to get access to nohup).
Windows doesn't understand the "sh" command. To enable this, add
C:\Program Files\Git\bin &
C:\Program Files\Git\usr\bin
to the System Environment variable PATH, than restart your system.
Than execute your command in jenkins, it will work.
Switching sh to bat worked for me - I am running Jenkins on Windows. But only after I had resolved an issue caused by the fact I had not configured my tools (maven and the JDK) correctly in Jenkins either.
In my case I replaced 'sh' by 'bat' in Pipeline script and worked.
sh is not windows command. The simple way to enable the use of 'sh' command in windows is to install GIT BASH
Once you install GIT BASH, then you need to set below environment variables path.
C:\Program Files\Git\bin : This path contains sh.exe, bash.exe and git.exe
C:\Program Files\Git\usr\bin : This path contains several Linux based exe and dll (cat.exe, find.exe etc.)
By setting above configuration you will be able to execute 'sh' command in Jenkinsfiles on Jenkins installed on windows machine.
I was getting the same error below solutions worked for me..
Install git-bash
for windows use "bat" instead of "sh"
set "C:\Program Files\Git\usr\bin" to PATH(user variable)
My observation is that the agent seems to be trying to run nohup in the context where the agent.jar is run, not in the container. It didn't matter what I put in the container, the error message was the same. By putting nohup and sh in the PATH where the jenkins agent is running, I see a change in behavior.
git config core.sparsecheckout # timeout=10
git checkout -f c64c7bf905b6a4f5a8f85eb23bbd108f4c805386
sh: /home/jenkins/workspace/projname/simple_docker#tmp/durable-9fedc317/jenkins-log.txt: No such file or directory
sh: /home/jenkins/workspace/projname/simple_docker#tmp/durable-9fedc317/jenkins-result.txt.tmp: No such file or directory
mv: cannot stat '/home/jenkins/workspace/projname/simple_docker#tmp/durable-9fedc317/jenkins-result.txt.tmp': No such file or directory
I am seeing a folder /home/jenkins/workspace/projname/simple_docker#tmp/durable-9fedc317 which contains a file "script.sh" with the contents "docker inspect -f . repositoryname:tagname"
When this docker command is run manually on the command line, it always produces a single line of output consisting of a single period character. I have no doubt this is not what the jenkins system is looking for.
So you want the job running under WSL. If you want all jobs running under WSL have you considered installing Jenkins under WSL? Then everything is already in GNU land and you don't have to bridge the envrionment/culture of windows to GNU from within your Jenkins configuration.
I got the above issue in windows 10 and just added the path "C:\Program Files\Git\usr\bin" to the system variables then it started working.
What is the difference between running commands on Gitbash (on windows) and the command prompt? I installed Gitbash on my Windows machine and using the mkdir function does not create a new directory (a folder that I can see).
git bash opens an msys bash session
git-cmd.bat opens a CMD session
Both set HOME properly (it is not set by default in Windows, as opposed to Unix/Linux).
And both add Git to the %PATH%.
They are package in Git For Windows (with a 64bits coming soon, with a more recent bash).
in gitbash mingw64 for windows 10 when you are in c:, mkdir creates new directory without problems.
For do it, you can go to c: by typing cd /c/ and after, press enter key. When you are in C change to your work directory with CD command, and type mkdir yournewdirectoryname. It works for me.
I want to use git in Intellij Terminal but it does not recognize the command. In Command Prompt and Windows power shell the command in recognized (I added the git path in System Environment Variables). I am also aware that Intellij has an GUI integration with Git.
So, can anyone tell me how can I use the git command in the Intellij terminal.
Setup JetBrains(InteliJ, WebStorm, PHPStorm) IDE terminal to use GIT bash
File
Settings
(Enter 'Terminal' in search)
Change Shell path to:
"C:\Program Files\Git\bin\sh.exe" --login -i
or
"C:\Program Files\Git\bin\bash.exe"
If you have another directory for installed git change it respectively.
In the IDEA settings make sure that your terminal path leads to "usr/bin" instead of "/bin".
As a result you will see pretty rich console output:
For me, it works also but only the path of Git Bash has changed in Windows :
"C:\Users\REPLACE_THIS_BY_YOUR_USER\AppData\Local\Programs\Git\bin\sh.exe" --login -i
The full path is not needed anymore (windows), I just replaced cmd.exe to sh.exe and bingo was his name O
Settings > Tools > Terminal > Shell path > sh.exe
In my case, the Git Bash through IntelliJ had TERM=xterm-256color.
Regular Git Bash had TERM=xterm
To fix the garbled characters issue in IntelliJ Idea,
Go to "File | Settings | Tools | Terminal"
Environment Variables: TERM=cygwin
In IntelliJ Terminal, Shell Path I was using was already:
C:\Users\<userId>\programs\Git\bin\bash.exe --login -i
You don't need to reinstall anything. Go to:
File
Settings
Search for terminal
in shell path type: "C:\Program Files\Git\bin\sh.exe" --login -i (or another directory where you installed Git)
This worked for me:
IntelliJ:
File->Settings->Version Control->Git:
On the right side, Path to Git executable:
"C:\Program Files\Git\bin\git.exe"
I am trying to use Emacs 24.2 with Tramp on windows 7 to remotely edit files on a linux server. I installed the Putty suit program and OpenSSH. I also placed the plink.exe in the putty suit into the bin folder under the emacs 24 folder, and added the folder emacs24/bin into the PATH environment variable.
However, when I try to access the remote file from emacs with the command in the minibuffer: /username#host:filename, I get the following error message from emacs: plink is not recognized as an internal or external command. It seems that emacs cannot find the plink program. But, when I try to run plink in windows cmd, it can find the plink program. Also, I can ssh to the remote server in windows cmd.
Can anyone tell me what's my problem? Do I need to install cygwin to make it work? Thanks a lot.
To get tramp with plink to work, I had to add my PuTTY path to my system search path.
On Windows 10:
control panel >> System & Security >> System >> advanced system settings >> enviroment variables
To PATH I appended the PuTTY path: C:\Program Files (x86)\PuTTY
I'm guessing the key is that from PowerShell or the command prompt, you need to be able to run plink without specifying the path.
I was able to resolve this and I did not have to install cygwin.
Try adding the path where putty was installed to your exec-path variable in emacs. Execute the following elisp code in emacs or put it in your .emacs file. Make sure the slashes are forward, not backslashes, as Emacs and Windows use different conventions.
(add-to-list 'exec-path "C:/Program Files (x86)/PuTTy")
check what exec-path is set to by typing C-h v exec-path
I have Cygwin running on a Windows 7 machine and have the Cygwin ssh server running on it. On Linux I have a shell script where I want to do
ssh myuser#mymachine "qwinsta | grep Active"
to see who is logged in. This worked fine for a Windows Server 2008 R2 machine, but seems to have problems on Windows 7.
If I try this on the Windows 7 machine, I get:
bash: qwinsta: command not found
Now, here is where the weirdness begins...
If I login to the Windows 7 machine normally and look in C:\Windows\System32 with Windows Explorer, I see qwinsta.exe. If I open a CMD session and do a dir in C:\Windows\System32, I see qwinsta.exe. If I open a Cygwin shell and do a ls qwinsta.exe in /cygdrive/c/Windows/System32, I get:
ls: cannot access qwinsta.exe: No such file or directory
If I do a cmd /c dir C:\\\\Windows\\\\System32\\\\qwinsta.exe from the Cygwin shell, I get a "File Not Found"
If I copy qwinsta.exe into my Cygwin home directory, then it is visible in my home directory with ls. If I try to run this local copy of qwinsta from the Cygwin shell, it runs, but it also outputs a line:
{Message(): LoadString failed, Error 15105, (0x00003B01)}
What's up with qwinsta on Windows 7?
The problem is that qwinsta.exe is not actually located in C:\Windows\System32. It is actually found in
C:\Windows\winsxs\amd64_microsoft-windows-t..commandlinetoolsmqq_31bf3856ad364e35_6.XX.XXX.XXXX_none_XXXXXXXX\qwinsta.exe
Using the above path (or a softlink to the same) will run qwinsta.exe as it exists on any machine, and will not require you to copy the executable to your home directory.
The error message {Message(): LoadString failed, Error 15105, (0x00003B01)} is about the Multilinugal User Interface (localization) system not being able to find error message localization information for the program being run (see System Error Codes). In this case, it appears that the cygwin shell does not provide qwinsta.exe with the information it needs to find qwinsta.exe.mui in your language's locale folder (usually C:\Windows\System32\en-US or whatever your locale happens to be). Looking into this folder is somewhat misleading, as explorer will show the file in this directory, but when you run ls /cygdrive/c/Windows/System32/en-US, there is no qwinsta.exe.mui file. I suspect this has something to do with the new linking structure in NTFS (see mklink command), but I haven't figured out how to fix this part of the problem yet.
Solved:
First, go to C:\Windows\winsxs\amd64_microsoft-windows-t..commandlinetoolsmqq_31bf3856ad364e35_6.1.7600.16385_none_851e6308c5b62529
(Copy and pasting that location works just as well as manually finding it.)
You should find three files: Msg.exe , Quser.exe, and qwinsta.exe .
Copy these files to your C:\Windows\system32 folder
Next, go to C:\Windows\winsxs\amd64_microsoft-windows-t..etoolsmqq.resources_31bf3856ad364e35_6.1.7600.16385_en-us_7bef78d9f4a6a8ac
You should find three similarly named files, except these will end with .mui.
Copy all three of these files to your C:\Windows\system32\en-US folder.
Now try running the msg program. It should work without issue.
Windows 10
Following on from Erutan2099's answer, for Windows 10 it's a little trickier, since the files are compressed (binary delta compression, file signature 44 43 53 01). Trying to use them as is throws an Unsupported 16-Bit Application error:
The program or feature "\??\C:\Windows\System32\msg.exe" cannot start or run due to incompatibility with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available.
A specific tool has been made to decompress such files: SXSEXP (this post pointed me in the right direction)
Usage:
> sxsexp64.exe msg.exe expand\msg.exe
Processing target path msg.exe
msg.exe => expand\msg.exe
File size 12602 bytes
DCS_HEADER found.
NumberOfBlocks 1
UncompressedFileSize 26112
DCS_BLOCK #1
Block->CompressedBlockSize 0000312A
Block->DecompressedBlockSize 00006600
Operation Successful
> sxsexp64.exe msg.exe.mui expand\msg.exe.mui
Processing target path msg.exe.mui
msg.exe.mui => expand\msg.exe.mui
File size 2150 bytes
DCS_HEADER found.
NumberOfBlocks 1
UncompressedFileSize 7680
DCS_BLOCK #1
Block->CompressedBlockSize 00000856
Block->DecompressedBlockSize 00001E00
Operation Successful
These decompressed files can now be copied to C:\Windows\System32 and C:\Windows\System32\en-US respectively.
Example:
> msg * Hello, World!