For some external program (not all), I want the program running independently outside Emacs, after executing the command. In another word, if I close Emacs, the external program can still run.
PS: my operating system is windows.
I think (w32-shell-execute "start" "myprog" "args") should do the trick.
Related
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).
I installed amazonCLI, as well as Cygwin, and changed the Path env variable to:
%SystemRoot%\System32\Wbem;C:\Program Files\Prio;C:\Program
Files\Diskeeper Corporation\ExpressCache\;C:\Program
Files\Amazon\AWSCLI\;C:\cygwin64\bin
When I open the command prompt, first of all it is directly pointing to
C:\Users\Stephane
(which I think is weird). And then when I input something like 'ls', the return error is:
'ls' is not recognized as internal or external command, operable program or batch file
Can you please help me know what I am doing wrong?
Thanks
From the error message you got, it's evident, that you are trying to execute Cygwin's commands from the Windows Console. That's also the reason, why it's executed in your Windows' profile directory instead of the Cygwin's one.
You should read the basics about using the Cygwin first, because it seems you don't know what Cygwin exactly is and how to use it. Maybe you don't need the Cygwin at all, it depends on what you need to accomplish. The is for example GnuWin tool set or UnxUtils, which are just a sets of standalone GNU tools compiled for Windows. Cygwin is more like system than standalone utilities. You can for example execute shell scripts under the Cygwin.
So it depends on your needs. But I simply can't imagine using Windows without Cygwin yet.
You can execute Cygwin's shell from the Windows Console, but I advice you to use MinTTY (which is in directory $CYGWIN_DIR/bin). MinTTY is a terminal emulator, which executes your Cygwin shell (bash by default).
To execute for example bash directly from the Windows Console, just execute $CYGWIN_DIR/bash.exe --login -i.
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 use gdb version 7.0 for debugging from emacs. The gdb when launched from emacs behaves slighlty differently compared with one launched from the shell. The points of differences are :-
gdb prompt, when launched from emacs doesn't recogonize the files in the current directory (from which the gdb session is launched.) This very cumbersome as when you run the application through gdb (using run), you have to give the full absolute path of the file. This is not the case when you launch the application through gdb from shell.
The arrow keys (that give the most recent commands typed on the gdb prompt), doesn't work for gdb launched from emacs. Instead, it moves the scroll up and down in the emacs gdb command prompt. Am I doing anything wrong here.. ?
Thanks and regards
since you are in a buffer, up and down move up and down in the buffer. most of the emacs shell-like buffers access the command history using "C-up" and "C-down".
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