I've cloned it but I didn't find any .exe file, Nor do i see it in programs list in Control Panel of windows. I'am a bit confused as to what cloning means. I know that there is direct download .exe file on vim.org website. Its for sure that I'am beginner for all these. Please help. Thanks for the help in advance.
reading the "installation" section found in the README.md of the vim repo, you can see the filenames containing the instructions that will help you with the installation, depending on your OS.
README_ami.txt Amiga
README_unix.txt Unix
README_dos.txt MS-DOS and MS-Windows
README_mac.txt Macintosh
README_haiku.txt Haiku
README_vms.txt VMS
So, for the full information I suggest you go to those files, or go to the vim website where there is also good information about the installation.
Anyway, I will briefly explain below the information that those files and the vim website say for most common operating systems
If you're on Unix:
git clone https://github.com/vim/vim.git
cd vim/src
make
If you're on Mac
The Macintosh binaries are not on the Vim ftp site. They are produced by a few Macintosh lovers. Often they lag behind a few versions.
MacVim has more a Mac look and feel, is developed actively and most people prefer this version. Most of MacVim was made by Björn Winckler.
MacVim can be downloaded here: link
Or if you prefer, here is the MacVim homepage.
If you're on Windows:
The next instructions were copied from here.
Option A: Using the self-installing .exe
Go to vim.org/download.php and click on self-installing executable (or just click here) and follow the prompts.
Watch out for:
When an existing installation is detected, you are offered to first remove
this. The uninstall program is then started while the install program waits
for it to complete. Sometimes the windows overlap each other, which can be
confusing. Be sure the complete the uninstalling before continuing the
installation. Watch the taskbar for uninstall windows.
When selecting a directory to install Vim, use the same place where other
versions are located. This makes it easier to find your _vimrc file. For
example "C:\Program Files\vim" or "D:\vim". A name ending in "vim" is
preferred.
After selecting the directory where to install Vim, clicking on "Next" will
start the installation.
Option B: Using .zip files
Go to the directory where you want to put the Vim files. Examples:
cd C:\
cd D:\editors
If you already have a "vim" directory, go to the directory in which it is
located. Check the $VIM setting to see where it points to:
set VIM
For example, if you have
C:\vim\vim82
do
cd C:\
Binary and runtime Vim archives are normally unpacked in the same location,
on top of each other.
Unpack the zip archives. This will create a new directory "vim\vim82",
in which all the distributed Vim files are placed. Since the directory
name includes the version number, it is unlikely that you overwrite
existing files.
Examples:
pkunzip -d gvim82.zip
unzip vim82w32.zip
You need to unpack the runtime archive and at least one of the binary
archives. When using more than one binary version, be careful not to
overwrite one version with the other, the names of the executables
"vim.exe" and "gvim.exe" are the same.
After you unpacked the files, you can still move the whole directory tree
to another location. That is where they will stay, the install program
won't move or copy the runtime files.
Change to the new directory:
cd vim\vim82
Run the "install.exe" program. It will ask you a number of questions about
how you would like to have your Vim setup. Among these are:
You can tell it to write a "_vimrc" file with your preferences in the
parent directory.
It can also install an "Edit with Vim" entry in the Windows Explorer
popup menu.
You can have it create batch files, so that you can run Vim from the
console or in a shell. You can select one of the directories in your
$PATH. If you skip this, you can add Vim to the search path manually:
The simplest is to add a line to your autoexec.bat. Examples:
set path=%path%;C:\vim\vim82
set path=%path%;D:\editors\vim\vim82
Create entries for Vim on the desktop and in the Start menu.
That's it!
Vim is open source software, and its source code, i.e. all the technical files that make up Vim is (nowadays) hosted at GitHub.
Cloning that repository means you'll download all of those files to your computer (and with Git as the underlying revision control system, you'll even get the full history of all changes ever done). As Vim supports a very big set of very diverse platforms (Windows, Linux, Mac, ...), the repository itself does not (and should not) contain pre-built binaries, nor a full installer that most users expect to run. So, unless you have the intention to actively contribute to Vim by submitting bug fixes or enhancements, you don't need to clone or do anything with GitHub. If you do want to get technical, src/INSTALLpc.txt contains the instructions for building Vim on Windows. This includes choosing a compiler, installing it and the required dependencies, configuring the build, building, and then finally copying the files to a permanent location on your PC, either manually or by building and then running an installer.
For plain passive consumption of Vim (which is rewarding in itself, but may even lead you to eventually also programming it), the Downloading Vim page on vim.org has all the information that you need, with links to the most popular installers right at the top.
a word on versions
For a casual user, using the latest stable version is recommended; this is 8.2 right now; gvim82.exe is a corresponding installer for Windows. This offers the best compromise between stability and latest features. In the case of Vim, expect a new release roughly every year.
You'll also find development builds (something like 8.2.0740); these usually function as well and have the very latest features under development, but often are less stable. I would use these only if you really need a leading-edge feature, or want to report a bug. You should then probably update very frequently, and from there it's only a small step to actually cloning the repository and building everything on your own!
Related
I have been running berrybrew on Windows
(here's the home page and GitHub repository).
I'm having some trouble with it and I want to uninstall and reinstall it, but I can't figure out how to do that.
I am hoping it is as simple as just deleting the directory where it was installed and C:\berrybrew, which is where it seems to keep files, but I don't know for sure. The instructions contain installation instructions, but no uninstallation instructions.
Disclaimer: berrybrew author here...
To uninstall and return your system back to default:
berrybrew off
berrybrew unconfig
then delete the directory you downloaded it to, as well as the installation directory (by default, C:\berrybrew)
Edit your PATH variable to remove any entries that start with C:\berrybrew (or the base install directory if you've changed it from the default). One of the path entries will point to C:\berrybrew\bin, and there may be one more that points to the currently in-use Perl installation (also under C:\berrybrew\...). Technically speaking, there shouldn't be any after the first two commands are run, but one should always verify
Essentially, there's really nothing to "uninstall". It comes down to removing $ENV{PATH} ie. specific environment variables that point to a) berrybrew.exe binary itself, and b) the Perl installation that you last used.
I will update the documentation to provide more clarity in this regard.
I am working in a team that is developing Android software. Some team members use Windows, some use Macs, and I have been known to use Linux. Everyone uses Eclipse.
Eclipse writes a file called project.properties; here's an example. The important part is the last three lines, the android library reference paths.
# This file is automatically generated by Android Tools.
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
#
# This file must be checked in Version Control Systems.
#
# To customize properties used by the Ant build system edit
# "ant.properties", and override values to adapt the script to your
# project structure.
#
# To enable ProGuard to shrink and obfuscate your code, uncomment this (available properties: sdk.dir, user.home):
#proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt
# Project target.
target=android-17
android.library.reference.1=../private-code/lib/SomeLibrary
android.library.reference.2=../google-play-services_lib
android.library.reference.3=../FacebookSDK
The above is what the file looks like when Eclipse on Mac or Linux writes it. When Eclipse on Windows writes it, the library reference lines are written with backslashes.
Of course on Windows, backslashes are acceptable path separators. But on Mac and Linux such paths do not work. The thing is, on Windows, forward slashes work perfectly well. So, our policy now is always to commit the file with forward slashes, so that it will work for everyone.
But this is a pain for our Windows users, and it's a pain for the rest of us when the Windows users make a mistake, so I'm looking for a technical solution. I have two ideas:
Find a setting somewhere in Eclipse on Windows, telling it to use forward slashes when saving paths in files like project.properties. (Why the heck isn't that the default?!?)
We use Mercurial, so: install some sort of "hooks" that will solve the problem.
Install a commit hook on the Windows computers, so that the file is committed into the repository with the backslashes replaced by forward slashes.
Install a pull hook on the Mac and Linux computers; so if the file gets committed with backslashes, they get fixed up by the time the files are written.
The commit hook seems cleaner, so if both are available I'd take a commit hook over a pull hook.
I found a Mercurial extension that edits tabs to spaces, which is at least sort of similar to what I want. It's complex enough that I'm a bit leery of trying to modify it into what I need.
https://www.mercurial-scm.org/wiki/CheckFilesExtension
The other strategy is to add a hook that detects backslashes in the paths, and simply aborts the commit, forcing the Windows user to fix the file by hand before committing. That would be better than nothing.
I would keep both versions in the project (as project.properties.windows and project.properties.linux) and create a symbolic link pointing to the right file depending on the OS. Call this symbolic link project.properties and let it be ignored by the version control.
Obviously the disadvantage of this setup is that when windows users update their project.properties file (which points to project.properties.windows), the linux version must be updated manually, and vice-versa, but it doesn't sound like a big deal tho, I presume you don't update this file very often.
- To create the links -
Create a file make_link.sh to setup Linux environments, with the following command:
ln -s $(readlink -m project.properties.linux) $(readlink . -m)/project.properties
Create a file make_link.bat to setup Windows environments, with the following command:
mklink project.properties project.properties.windows
You can commit those scripts as well.
We faced the similar situation due to the path of the local library varies, so after searching a while we found that the best practice to use centralized repository tools (Git for us), "Remove all eclipse dependent/Specific settings files from Repository". And that works fine for us. This way, the change to eclipse settings file will not be effecting the central repository or get committed.
When installing Enthought Canopy 1.0 using the .sh installer, it places a lot of stuff in my home folder, even though I chose a different installing location.
Part of this is some directory ~/canopy with empty folders for scripts etc. - OK on that one, even though I would rather choose a different location for this, too.
The other part is ~/Enthought/Canopy_64bit with binaries and libraries. I do not want these to be in my (backed-up) home directory.
How do I move this stuff somewhere else? I can see that there is an entry in my ~/.bash_profile and at least also in ~/Enthought/Canopy_64bit/User/pyvenv.cfg pointing to that location. But are there more?
This should be made an option during the installation.
There is no officially supported way of doing this although there is a way to do it. We aren't comfortable documenting this workaround in a public archive like stack overflow. If you can please send us a "suggestion" through Canopy's Help menu and we'll respond with the workaround.
When you install your product locally, all the needed files are stored in the machine.
When you set the features to Advertise, files will be installed locally when the user launches the application.
What happens then when yo set the features to "run-from-source"? I Googled it and was only able to find this: http://msdn.microsoft.com/en-us/library/aa367538%28v=vs.85%29.aspx
Thanks!
This is a rarely used feature of Windows Installer and I don't normally reccomend using it. It was invented back in a day when hard drives were small and the thought was you 'advertised' ( pretend install aka install source ) a feature and that when the user clicks the shortcut it would go to the source and finish the installation of the feature ( aka install local )
It just adds a lot of complexity to your servicing model. It's not worth it IMO.
When placing all installation files next to the MSI (similar to advertised installation), you can install features from source. This means that all files in these features will be used from the MSI location (they are not copied in the target folders during install).
Running from source can be used when the installer remains permanently on the target machine. So the application can use the installer directly instead of using installed files.
I've been using RCS (revision control system) from MKS Source Integrity for several old projects. I have to move to a new Windows 7 computer. The old version I have does not install on Windows 7, and a new version of the software is very expensive.
What is the best free or cheep source of RCS for Windows 7? Also, will it be compatible with MKS Toolkit which I am still going to install?
The official website for RCS has Windows 32-bit binaries, but they are dated. YMMV. http://www.cs.purdue.edu/homes/trinkle/RCS/.
Edit: I just tried the binaries (from the first zip file). They seem to work on a trivial text file.
I put them in a directory. Then I created an "RCS" directory. Then I created a text file. Then I ran "set TZ=EST" in my cmd.exe window (the tools require a timezone). Then I was able to check the text file in and out with the RCS command line tools.
Note that large files are probably not supported given the date of the binaries.
If you want the binaries to be available system wide, you have to place them in a location on your Windows PATH and set the TZ environmental variable to the zone you need in your account's environment.
RCS offers reverse merge which can be useful when you want to apply selected fixes for ECO version of your software without addition on less tested product enhancements. I was able to produce ECO version of real-time control system with several hundred fixes without the assistance of software engineers working on the next release of the product. ClearCase did not offer similar capability at the time.
We used rcs and gmake. Build scripts were written in Perl. Each ran on native Windows. I wish the idiots at the software company in Washington would use / instead of \ for file separator.
On Windows 7 64-bit SETUP32.EXE fails "not compatible with the version of Windows you're running"
My workaround:
Copy sintcm32.dll from a 32-bit machine into c:\windows\syswow64.
In Explorer, double-click a .pj file, set description to "MKS Source Integrity Project/Sandbox File" and target to "[network location]\mkssi\mkssi32.exe"
Create start menu shortcuts to "[network location]\mkssi\mkssi32.exe" etc.
Git (MSysGit) works on Windows 7 and is free. There is a learning curve associated with Git, which I think is worth it (for the benefits you get, especially regarding a distributed VCS), but some may disagree. This bundles come with bash and an ssh client (useful synchronization with remote repositories).
EDIT: For RCS specifically, there is an RCS package via Cygwin or an independent package from the Purdue RCS Homepage (the latter says "The latest PC (OS/2 DOS Win95 NT)", but I guess it might work on Windows 7, I'm fairly sure the Cygwin package works on Win 7).