I've downloaded and installed the GnuWin32 tools, and added the grep executables to the Emacs bin. I've also, for what its worth, added the GnuWin32 bin folder to my Path variable.
Problem is though, when I try and run with suggested grep commands, I always get:
Grep exited abnormally with code 53 at Wed Feb 24 17:16:12
For the life of me, I can't find any reference to error code 53 anywhere! :(
I've tried the exact examples on a number of websites for example, when I enter:
M-x grep <ret>
It comes up with
Run grep (like this): grep -n
Which is fine, but I have no idea of what parameters it expects. I've tried some in some tuorials, but I get error code 53 again!
One of the things I've tried is straight from the emacs wiki (http://www.emacswiki.org/emacs/GrepMode#toc2) (maybe not for the windows version though?) and it says to try this command:
M-x grep -n -e setq ~/.emacs
Which I've tried and I get:
-*- mode: grep; default-directory: "c:/[My Directory]/" -*-
Grep started at Wed Feb 24 17:30:47
grep -n -e setq ~/.emacs NUL
Grep exited abnormally with code 53 at Wed Feb 24 17:30:47
So frustrating as this is meant to be a powerful feature of Emacs and I'm really trying to learn it as I've heard good things about it!
Any help would be appreciated! :)
Andy
UPDATE
From the suggestion below, I've tried it via command line and it seems to work fine, perhaps there some config I'm missing?
UPDATE
I've found the command M-x Occur which seems to do much the same as I would image grep does. Are there many extra benefits to using grep over occur if I can't get this working?
Download the dependencies zip file and copy libiconv2.dll, libintl3.dll, pcre3.dll and regex2.dll to Emacs' bin directory.
Copy grep.exe and find.exe to Emacs' own bin directory. Emacs will then use these files over any other executables with the same name, including Windows' own find utility.
Note: if you don't use the installer, you need to download the dependencies zip file as well and copy libiconv2.dll, libintl3.dll, pcre3.dll and regex2.dll to Emacs' bin directory, otherwise you may get an "exited abnormally with code 53" error message.
EmacsWiki: Grep Mode
The exit code of 53 is possibly an OS exit code rather than a grep-specific exit code. For windows this would be "The network path was not found". Are you doing anything over a network path? Are there any missing dll's that grep needs? Can you successfully run grep on the command line?
I had a similar problem and the following worked for me.
Go to the windows console
Enter the command "set" to bring up your system variables
I had shell=c:\progra~1\rational\ration~1\nutcroot\mksnt\sh.exe
Enter "set shell=" to remove the variable
Try Emacs again
Good luck!
Related
Not that much experience programming, but I saw this open source code for one of those speed readers everyone is talking about and thought it would be cool to try to run it on my own computer.
The files are available here: https://github.com/pasky/speedread
I was wondering what exactly I should type into the command prompt to get the program running. I already have a perl interpreter on my computer. But I'm not sure how to get the program running. Sorry if this is a super noobish question.
I've tried
perl C:\speadread-master\speedread (and yes, it was on the C: drive)
I got the error:
Use of encoding pragma is deprecated at C:\speadread-master\speedread line 39.
'stts' is not recognized as an internal or external command, operable program of batch file.
←[31mc←[0←[K
I also tried (because it appears in the gifs on github)
~/speedread$ head -n 21 tea.txt | ./speedread -w 250
I got the error:
'~' is not recognized as an internal or external command, operable program or batch file
In addition to amon's comment, wo points out a strong dependency to Unix commands/display, you also misinterpreted the head command:
~/speedread$ is a Unix command prompt, with ~ refering to your HOME directory (USERPROFILE in Windows). You are not supposed to type it.
The actual command is:
head -n 21 tea.txt | ./speedread -w 250
Adn you have an head.exe (Windows version of the unix command head) in your git msysgit distribution (bin/head.exe).
I installed EPD Free 7.3.2 and it was running fine until I wanted to modify PATH to point to where my Python scripts are. I gave up on that and reverted back to my original .bash_profile file.
# Setting PATH for EPD_free-7.3-2
# The orginal version is saved in .bash_profile.pysave
PATH = "/Library/Frameworks/Python.framework/Versions/Current/bin:${PATH}"
export PATH
When launching terminal, I get this:
Last login: Thu Jan 3 08:50:20 on ttys000
-bash: PATH: command not found
However, I am able to run iPython and all the libs that come with EPD w/o problems. Anybody knows what the problem is with "PATH: command not found"?
The spaces around the = are a problem. Use this assignment:
PATH="/Library/Frameworks/Python.framework/Versions/Current/bin:${PATH}"
You need to remove the spaces around =:
PATH="/Library/Frameworks/Python.framework/Versions/Current/bin:${PATH}"
Otherwise you're trying to run the (non-existent) command PATH with = and "/Library..." as its arguments.
I'm having trouble getting 256 colors to work using emacs 23.1.1 connecting using PuTTY and screen. Server is running CentOS 5.6.
In my PuTTY config, my terminal-type string is set to xterm-256color. In my .screenrc I have term xterm-256color Once in screen tput colors gives me 256, echo $TERM gives me xterm-256color, but once I start emacs M-x list-colors-display only gives me 8 colors.
Not sure what the problem is.
Thanks.
I hit the same problem.
To fix this problem, just add this to ~/.bashrc (yes,I use bash)
# -----------
export TERM=xterm-256color
export TERMCAP=
# ------------
run screen and emacs in an screen window. it's ok now.
versions:
bash-4.2.45
emacs-24.3_10
Screen version 4.00.03 (FAU) 23-Oct-06
Your ~/.screenrc should read:
term screen-256color
(this shouldn't be mixed up with xterm-256color)
Putty has a setting to allow 256 color mode. It's under Window/Colours, labeled "Allow terminal to use xterm 256-colour mode". Make sure it's checked.
After you load emacs, you can confirm the TERM value emacs is using with:
(assoc 'tty-type (frame-parameters (car (frame-list))))
It should be (tty-type . "xterm-256color").
Looking at your post and your responses to others, it sounds like your problem is... screen. To test my hypothesis, try this ...
$ wget http://www.frexx.de/xterm-256-notes/data/256colors2.pl
$ chmod 755 256colors2.pl
$ ./256colors2.pl
... if you see 256 colors in the shell, but not in screen, the problem is screen. And, even if there are other problems, you are going to have to fix screen in order to have any hope of seeing 256 colors in emacs ;)
I recently fixed this situation for myself on a system where I don't have sudo by building a personal copy of screen. Screen is small and it is no big deal to do ... and, IMHO, emacs w/256 colors is well worth the bother.
On Linux 2.6.x I did this:
$ wget ftp://ftp.gnu.org/gnu/screen/screen-4.0.3.tar.gz
$ tar -xf screen-4.0.3.tar.gz
$ cd screen-4.0.3
$ ./configure --prefix=$HOME --enable-colors256
$ make
$ make install
Test the new screen out with ...
$ ~/bin/screen
$ ./256colors2.pl
... if it works, put this in your ~/.bashrc:
PATH=~/bin:$PATH ; export PATH
The screen I ended up with reports being an earlier version ...
$ ~/bin/screen -v
Screen version 4.01.00devel (GNUdf0777e) 2-May-06
... than the version on my system:
$ /usr/local/bin/screen -v
Screen version 4.00.03 (FAU) 23-Oct-06
But while they both claim to support 256 colors...
$ tput colors
256
Only the new build really does. Yeah!
I had similar difficulties, I believe both of these lines were required for screen, putty, and emacs to get along with 256 colors.
termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'
term xterm-256color
You may also need this line too.
defbce "on"
Speak up if that's still not enough.
Try using emacs in daemon mode instead (emacs --daemon), and open emacsclients (emacsclient -t) instead of using screen/tmux. This will give you one less variable to handle in debugging this.
I was having a similar problem with putty and screen, though not using emacs. Following ataylor's response, I went to Window/Colours in Putty. In there I found and checked 'Use system colours'. This fixed my issue.
I have code on a compute node of a cluster. I can't ssh directly to the compute node so I first set up an ssh tunnel with
ssh -f cluster.master.node -L 2222:cluster.compute.node:22 -N.
Next I visit the file with
C-x C-f /ssh:user#localhost#2222/path/to/blah.c.
Finally I do
M-x gdb.
In emacs 23 I would do
Run gdb (like this) gdb --annotate=3/ssh:localhost#2222:/path/to/program
but documentation for the gdb function in emacs 24 says "The command-line
options should include -i=mi to use gdb's MI text interface. Note that the old "--annotate" option is no longer supported."
Running
gdb (like this) gdb --i=mi /ssh:loalhost#2222:/path/to/program
seems to work, but when I try to run the program I get "Starting program: /misc/home/joey/git/proteus/proteus /dev/pts/5: No such file or directory." The problems seems to be with the non-existent /misc/ directory prepended to the path of the executable. Even when I do a cd to /home/joey/git/proteus/ the response is "Working directory /home/joey/git/proteus (canonically /misc/home/joey/git/proteus)."
Can I remotely debug my program in Emacs 24 or should I go back to 23?
Try M-x gud-gdb RET: it will give you the old Emacs-22 behavior.
My Cygwin environment (Windows 7 O/S) has developed a strange problem. A couple of days ago I was running a perl script fine, but today I'm getting
0 [main] perl 5056 C:\cygwin\bin\perl.exe: *** fatal error - unable to remap \\?\C:\cygwin\lib\perl
5\5.10\i686-cygwin\auto\Socket\Socket.dll to same address as parent: 0x8F0000 != 0x960000
Stack trace:
Frame Function Args
0088B508 6102749B (0088B508, 00000000, 00000000, 00000000)
0088B7F8 6102749B (61177B80, 00008000, 00000000, 61179977)
0088C828 61004AFB (611A136C, 6123E0FC, 008F0000, 00960000)
End of stack trace
I tried running rebase, as advised here but the problem persists. Any answers appreciated, as I have a demo tomorrow for which this script is needed. Wasn't expecting a problem like this!
This is a semi-informed answer, as I have had similar difficulty and eventually flailed around until the problem went away.
rebaseall with no arguments will rebase all of the dll files that were installed from cygwin packages. However you will often have many other dlls from other programs you have built and installed, including from installed Perl modules with XS code, and you will need to tell rebaseall about these modules somehow.
There may be an easier way to do this, and I hope I haven't forgotten any steps, but I think I had some success doing something like this:
Get a list of all the dll's in your system that run under cygwin. Maybe something like find /bin /lib /usr /home -name \*.dll > /tmp/file1
exit all cygwin processes, open as ash or dash shell from a Windows command prompt, and run /bin/rebaseall -v > /tmp/file2. The -v switch sets a Verbose flag in rebase that lists all the files that get rebased with the default setting.
Use /tmp/file1 and /tmp/file2 to create a new file, say /tmp/file3 with the complete list of files you will want to rebase. From what I remember it is important for the system dlls (all the files in /tmp/file2) to be listed first,
Now run rebaseall -v -T /tmp/file3 (in ash, after closing all cygwin procs, etc.). Pay attention to the output. If there are error messages about rebasing some particular dll, remove that entry from /tmp/file3 and try again.
This may not solve your problem, but maybe it will get you most of the way there. If you do eventually figure it out, I hope you will come back and fill in some of the holes in this solution.
I think it is useful to point out that for most people running into this a simple "rebaseall" without any arguments seems to resolve this issue. I'll post a link to a very useful blog post from My Life, Starting up (I have no relation to that blog):
http://www.mylifestartingup.com/2009/04/fatal-error-unable-to-remap-to-same.html
The action list, (copied directly from the blog) is:
Let me tell you what you can do if you don't care what's actually happening.
1) Close out of Cygwin (and all cygwin processes).
2) Open a Windows command prompt (start -> run - > type 'cmd' or on vista : start -> type 'cmd' in the start search window)
3) Go to your cygwin bin directory. For me it is c:\cygwin\bin.
4) Type ash
5) Type '/usr/bin/rebaseall'
6) Resolve any errors (I had a warning that went unresolved and it still worked fine)
7) Reboot...and you should be good.
And if you DO care what's actually happening, read the blog entry, in addition to the answer by mob here on this same question.