I am running a cygwin shell under windows 10 in which I start a "screen" session and under that the cygwin version of emacs (24). If I do M-xshell, it starts a cygwin (bash) shell just fine. So for most of my programming I'm happy. However, if within the cygwin shell I run "cmd" to get a "DOS prompt". I get this weird error message from emacs, "Waiting for process to die" (and some more text about hitting ctrl-g). I also get the same message, if I set the shell to be cmd by setting "explicit-shell-file-name" when I run shell. (That's actually what I tried first.)
Now, if hit C-g (perhaps twice?), the shell appears and cmd appears to be running, but I'm not certain of the state of things.
Has anyone else seen this error message? Googling for it returned nothing useful. Is there some incompatibility between the cygwin build of emacs and running cmd? Any hints on how to get around this problem?
Alternately, is there any way to send "builtin?" "DOS" commands (like MKLINK) under bash to a DOS box? How about running .cmd files? I really hate running a separate DOS box (not under emacs) and sometimes I need to do "DOS" things (and usually want the output captured in an emacs buffer).
Related
I have a small utility script called clear.bat that does some housekeeping work on my sources.
It is a .bat file so that I could easily double-click it in Windows Explorer.
Sometimes, I find it more handy to execute it from my Git bash (msysgit, if this matters).
To do this, I type
cmd
clear.bat
exit
cmd turns my Git bash into a normal cmd window where I could easily execute my batch. When I type exit, the cmd environment is terminated and I'm back in my Git bash.
Could this be achieved in an easier way?
I tried cmd /C clean.bat since the docs say
Syntax
CMD [charset] [options]
CMD [charset] [options] [/c Command]
CMD [charset] [options] [/k Command]
Options
/C Run Command and then terminate
/K Run Command and then return to the CMD prompt.
This is useful for testing, to examine variables
Edit:
Just noticed that the post is broken.
What I want is to execute clean.bat from within the Git bash without having to type the three commands above (cmd, clear.bat, exit). I just want to execute the .bat file from within my Git bash. Obvious way would be to create a separate .sh file that does the same work but this will lead to double code.
Edit 2:
When I execute cmd /C clean.bat, the Git bash turns into a plain CMD environment and only displays the prompt. The file clean.bat does not get executed. It's the same as if I just type cmd.
Also, adding a /debug switch does literally nothing. Seems like only cmd gets evaluated and all further parameters are getting ignored.
After playing around a bit more, I found the solution myself:
cmd "/C clean.bat"
does the trick. But I got no clue, why...
./clear.bat will do the trick.
The Git for Windows (msysGit has been superseded by Git for Windows1) FAQ says you have 3 options:
Run programs that have problems using the winpty utility. This allows you to keep using the nicer mintty terminal, but can become unwieldy if you need the workaround for many programs.
Modify the shortcut for Git Bash to run bash directly without mintty so it uses the default console host and configure it for "Quick Edit", reasonable size and scroll-back and suitable unicode font. You'll still have to live with the other quirks of console host.
Install and use ConEmu.
At some point, Git for windows added support for the MSYS_NO_PATHCONV environment variable, so in addition to #eckes and #AlikElzin-kilaka solutions, you can also
MSYS_NO_PATHCONV=1 cmd /c clean.bat
In general, I prefer this solution, as it allows the code to be the closest to resembling normal bash, and there are many ways to export MSYS_NO_PATHCONV depending on your preferred situation.
Note: Git for Window's bash does not support the MSYS2 environment variable MSYS2_ARG_CONV_EXCL
The other solutions
The weird quoting solution
Why does cmd "/c clean.bat" not create other errors?
It turns out argument parsing in windows does not follow the same universal rules as it does in *nix. Instead, in windows the arguments are parsed differently based on the runtime you compile against. Basically in windows, the command line arguments are passed in as "one string" and then parsed by the runtime.
See here(archive) for more explanation than you could ever want.
E.g. cmd parses arguments differently then wscript.exe
In the end, you can hopefully find something that works with this method, and it is the most "window-esque" of the three solutions
The // method
This is pretty well explained here and simple to use, but adds an extra / which does not help readability
I like start clean, it opens a new window with cmd. This method has some benefits:
cmd.exe gets a native console
the new console has a native windows character encoding (e.g. cp1251 vs utf8)
This will work and it frees the terminal too
nohup ./nucleus.bat &
less nohup.out
I just recently found out about using bash in windows. I had alot of fun installing linux programs onto my windows computer using bash and wondered how I would be able to run an automatic script so I dont have to export my display everytime I open bash.
I used to write scripts for cmd called batch scripting and I would be able to do everything cmd could do. Now that I have access to bash, I want to script a program that connects useful pieces of cmd with useful pieces of bash but I Can't find any results telling me how to call bash commands from cmd. Thank you - Zak Kaioken
When I open a file in MSYS, i.e. subl init.js the terminal hangs until I quit that process. Is there a way to run it as a separate process like in Mac terminal?
The MSYS shell is a standard unix-like shell such as bash, so if you want to run programs in the background on the shell, you need to put an & at the end of the command. This causes it to run in the background.
I would recommend reading this SuperUser question about Shell Tutorials, which has some excellent links to shell tutorials and resources.
I've searched over the web and still can't figure it out.
I apologise if this sounds like a lazy whinging cry for help -- I really am at wit's end with this one.
I have a bash script located at:
/cygdrive/k/Linux Scripts/Scripts/filter.sh
I've copied the Cygwin.bat to filter.bat, and changed it as follows:
#echo off
L:
chdir L:\Cygwin\bin
bash --login "/cygdrive/k/Linux Scripts/Scripts/filter.sh amc.txt bmo.txt"
When I run filter.bat by double-clicking on it in Windows Explorer, the console flashes open momentarily and then closes. The script is OK, because it runs from the command line in the Cygwin console.
Is there a way to debug this problem?
Try running the batch file from an already-existing Command Prompt window so you can see any error messages bash might send. I'm guessing it has a problem with "/cygdrive/k/Linux Scripts/Scripts/filter.sh amc.txt bmo.txt" -- as far as it's concerned, that's one argument rather than three. Therefore I would change it to
bash --login "/cygdrive/k/Linux Scripts/Scripts/filter.sh" amc.txt bmo.txt
I am using a bash script to run a number of application (some repeatedly) on a Windows machine through cygwin. The script contains commands to launch those applications, line by line. Most of these applications run for many minutes and many times I have observed that the i+1 th application is not being started even after i th application is completed. In such cases, if I press enter in the cygwin console on which the bash script is running, the next application starts running. Is it because of any issue with bash on cygwin? Or is it an issue with the Windows OS itself? Have any of you observed such an issue with bash + cygwin + Windows?
Thanks.
I think I have seen this before.
Instead of
somecommand
try
somecommand </dev/null
If that doesn't work, try
cmd /c somecommand
Or experiment with other redirections, e.g.
somecommand >/dev/null
Sounds like you may have a problem with your shell script encoding; DOS (and Windows) uses CR+LF line endings, whereas Linux uses LF endings. Try saving the file as LF.
What might also be going on:
When I was running Cygwin on a school laptop, I encountered a dramatic slowing of shell scripts vs. when they were running in a native Linux environment. This was especially apparent when running a configure script from GNU Autotools.
Check your path for slow drives. (From the Cygwin FAQ):
Why is Cygwin suddenly so slow?
If suddenly every command takes a very long time, then something is probably attempting to access a network share. You may have the obsolete //c notation in your PATH or startup files. Using //c means to contact the network server c, which will slow things down tremendously if it does not exist.
You might also want to check whether you have an antivirus program running. Antivirus programs tend to scan every single executable file as it is executed; this can cause problems for even simple shell scripts that run hundreds or even thousands of individual programs before they run their course.
This mailing list post outlines what is needed to pseudo-mount the main /usr/bin directory as cygexec. I'm not sure what that does, but I found it helped.
If you're running a configure script, try the -C option.
Hope this helps!
Occasionally, I'll get this behaviour because I have accidentally deleted the 'she-bang' at the top of the script, that is, deleted the #!/bin/bash on the first line of the script.
It's even more likely for this to happen when a parent shell script calls a child script that has the she-bang missing!
Hope this helps.
A bit of a long shot, but I have seen some similar behaviour previously.
In Windows 2000, if any program running in a command prompt window had some of it's text highlighted by the cursor, it would pause the command running, and you had to press enter or clear the highlighting to get the command prompt to continue executing.
As I said, bit of a long shot, but accidental mouse clicks could be your issue...
Install cygwin with unix style line breaks and forget weird problems like that.
Try saving your script as "the-properly-line-broken-style" for your cygwin. That is, use the style you specified under installation.
Here is some relevant information:
https://stackoverflow.com/a/7048200/657703