I just installed svn client from tigris and from the command line I can do checkouts, commits merges etc.
But now I would like to use emacs for merging files or directories.
vc-merge only works when you're in a file. I can't get it to work on a directory.
There is also the command line utility and for that I would like to use the same emacs session I'm using for my (dos) shell.
From the documentation I found I need to set SVN_EDITOR to:
gnuclient, emacsclient but that doesnt work either (hitting 'e' after finding conflicts reports emacsclient/gnuclient is not recognized as external editor). Putting c:\programs\emacs-23.3\bin\runemacs.exe starts a whole new emacs frame, and it doesn't show me the nice diff screen with the two conflicting files, I remember seeing when working with cvs and emacs.
I don't use the same OS as you do, but for the SVN_EDITOR part, I think what you want is emacsclientw and not emacsclient, take a look at the binaries in c:\programs\emacs-23.3\bin\. You also probably need an emacs started in server mode, the function is named server-start.
Related
I am following this tutorial where i have to run this command in order to start the zookeeper server.
./bin/zookeeper-server-start.sh config/zookeeper.properties
But the problem is this command is not working properly. I found that .sh file is bash file that required cygwin. I have installed it and then run command like this
C:\cygwin64\bin\bash.exe ./bin/zookeeper-server-start.sh config/zookeeper.properties
But it is showing:
I can confirm that in bin directory the file is exsits. what i am doing wrong?
Here is my directory snapshot from where i running the command:
Note: I have successfully tested bin/windows zookeeper bat file but i want to run it through .sh file as the kafka security tutorial which i am following using this.
From your screenshot, I conclude that you are using Cygwin. So, please add the cygwin tag to your question.
As you can see from the error message, the command dirname is not found by bash, so assuming that your Cygwin installation is not broken, I assume that the PATH is not set correctly; in your setup, dirname.exe should be in C:/cygwin64/bin (please verify this).
Your usage of bash.exe is a bit unusual in that you run it directly from a Windows cmd prompt. The more common way would be to use it from the 'Cygwin Terminal', which you get created a Windows-link to, when installing Cygwin, or to use another suitable Terminal program; I'm using for instance mintty for this task (also available via the Cygwin installer).
Having said this, it is possible to run bash.exe in the way you are doing it, but you then have to ensure, that at least the PATH is set up correctly. One possibility to do this, is to add C:\cygwin64\bin to your Windows PATH, but this has the drawback, that some commands have the same name in the Windows world and in Cygwin, though they serve a completely different purpose, and this will bite you sooner or later. Another problem is that at some point, you will rely on other bash specific setups besides the PATH.
A better way to accomplish your goal is IMO to ensure, that the system wide bash-initialization files are sourced by bash. If I have to run the script from a Windows cmd prompt, I would run it by
C:\cygwin64\bin\bash.exe --login YOURSCRIPT
This will read the file (in your setup) C:\cygwin64\etc\profile before running YOURSCRIPT, so you can check, that the PATH is correctly set there, by looking at this file. In a default installation, this should be the case.
After having read this file, it will try to read the file .bash_profile in your Cygwin HOME directory, so if you need additional settings for your (non-interactive) bash-scripts, create this file and put your settings there.
I am trying to set up a development environment on Windows 10. So far I've installed Vim and Cmder (the full version with Git for Windows).
Playing around, I noticed some strange behavior which I don't understand, but I feel like it is important that I understand.
Case A
I open PowerShell
Locate the folder that contains vim.exe
Run .\vim.exe
Vim pops up and displays the default screen (VIM - Vi IMproved, version 8.1.1, etc.)
In Normal Mode I type :version to check the version number and to see where my _vimrc file is located
Vim gives me the expected output
Case B
I open Cmder and open a new PowerShell tab (I am assuming that that gives me access to the PowerShell instead of the default cmd.exe, but please correct me if I am wrong.)
NOW THIS IS WHERE IT GETS INTERESTING
If I repeat steps 2-6 exactly as in Case A, I get exactly the same result.
BUT:
If instead of locating the folder that stores vim.exe I just type in vim and hit Enter it opens Vim once again, but this time it has a tab on the bottom that says "unix". See attached images.
Out of curiosity, in Normal Mode I type :version, just like in Case A, but this time I am getting a different date in the version section, a different selection of options, and a different Unix-like path to the vimrc file which in now .vimrc instead of _vimrc.
What gives? My guess is that Git for Windows that came with Cmder is simulating a Unix environment and accessing a different Vim version that was compiled for Unix?
If this is true, then could you help me make sense of this Windows/Unix environment duality? Do I now have two HOME folders, two copies of the vimrc file, and two copies of who knows what else? What is simulating this Unix environment - Cmder?
Thanks!
I don't have experience with Cmder, but I use Git for Windows a lot.
Git for Windows comes with some Unix utilities and uses Cygwin which is Unix emulator for running those. Vim is among them as default text editor for commit messages, etc. So it might be it.
I tried to reproduce this on my machine. but I cannot reproduce what you are seeing. Nonetheless I found the vimrc file for the Vim you are probably using in the second case.
It is in <Cmder-dir>\vendor\git-for-windows\etc\vimrc.
You have two different versions of Vim installed, and depending on the environment you start it from, one or the other gets selected. Git (as a tool that initially was developed on and for Linux) typically brings with it a set of Windows-ports.
You can check what Vim binary is used (respectively) from within Vim via
:echo v:progpath
Whether you live with this duplication or try to consistently use one Vim instance is up to you. It looks like the Vim that accompanies Git has more Unix-centric settings; it might be good to keep that to avoid interoperability issues.
You definitely don't need to clone your whole Vim configuration - as long as you stick to Unix-style (LF) line endings, it can be understood by any Vim. By setting the HOME environment variable (but that may affect other programs!), you can make Vim use the same location. Else, you could give one Vim config location a small .vimrc that just corrects 'runtimepath', and then :sources the "real" vimrc from the other location.
Not long ago I found out a precious thing which comes with the git install:
http://git-scm.com/download/win
From git's bin folder on the command line you have almost a linux console available. Commands like curl, touch, kill, ssh, grep and lots of others. The problem is that when you move out of the bin folder, of course they become unavailable. Is it possible somehow to make these commands available globally from the windows command line?
Use this one Git Shell from Github
Has some cool git features in it, much better than default windows command prompt.
Few good points are:
Tab completion
Prompt for current branch
Colors highlighting
You simply add the full path to you "bin" folder (e.g. c:\git\bin\) into Windows "PATH" environmental variable.
As opposed to repeating how to do that here, plenty of help on the web.
http://www.computerhope.com/issues/ch000549.htm
Note: you may need to close and re-open the command window you are in if you add through the control panel.
I dont really understand whats going on and cant see the difference:
I'm downloaded the base64.exe for creating base64 text under windows. i copied it to C:\Windows\ because its in the %PATH% variable.
Now i want to try it: echo Hello | base64 works great. Okay i dont need to append .exe and as far as i know i dont need to do it also with .bat and .com files.
But now i have some cygwin tools installed and for example tried which base64, which doesnt work, because it says that base64 is not in path. Then i typed in which base64.exe and got C:\Windows.
So my question is now: when i need to use .exe and when i dont? Is it only when i'm using cygwin tools that i need to append .exe?
Cygwin is a shell which emulates UNIX behaviour. UNIX doesn't know anything about .exe, thats why Cygwin can't find base64.exe. Under UNIX, binaries are stored without an extionsion added to their filename, e.g. just base64.
Windows CMD automatically appends .bat, .com, .exe and the like to your file names. Cygwin does not. So if you are using a linux shell you have to append it manually.
Since Cygwin is aware that it always runs under Windows it might append .exe if you want to perform certain actions in the shell itself (e.g. opening a file), to behave more friendyl to Windows users who expect this behaviour. However programs running under Cygwin might not integrate those features since they were mainly devoloped for usage under UNIX. That could be a reason why which base64 fails.
I want to set an alias to my installation of firefox so I can easily start a web page, the problem is that I dont want the script to be system dependent.
Namely I want it to be able to run on a linux distribution where the command to start firefox is already mapped to 'firefox' and can easily be run that way through bash, but on my windows machine I cant seem to get it to assign to the same variable.
I saw that I could set it to '%firefox%' via the set command but that's not quite what I want.
I believe creating aliases is possible on a windows environment because the version of svn that I use auto-installed and was able to assign itself to 'svn'. Anyone know what was involved in them being able to get their alias working, or a similar way to alias a command?
If you include your Firefox path in the %PATH% environment variable, you can start FF with "firefox". Under Windows, you should edit the system-wide settings (see this link).
AFAIK, there is nothing similar to aliases under DOS/Windows (except the %firefox% way you mentioned, too). The 'svn' command you talked about most likely is the same thing, a 'svn.exe' and its path included to %PATH%.
This is a bit restrictive, as you can only use the original filename to launch a program, but you can work around this by creating a batch file in the program's path that launches the program, f.e. a FF.BAT that contains "firefox %1".
Alternatively, you can place a batch file in a path that already is in %PATH%, f.e. the Windows directory. That way, you don't have to modify %PATH%.