Heading says it all really. Using Windows 7 and latest stable gvim, whenever I save (:w) a file it's marked executable. I'm doing cross-platform development and it'd be nice if this didn't happen.
#sceptics: The flag of the files are indeed set as executable. Do a ls -al before and after re-saving the file to observe the issue. (install cygwin, or may be other *nix emulations)
#OP: the question have been raised several times in the past. I don't remember the conclusion on the subject. You should search vim mailing-lists archives (vim_use and vim_dev).
May be you can try to add an hook to your RCS (if it supports that) to proceed to a chmod -x on file extensions that does not correspond to an executable (*.h, *.cpp, *.vim, ...), or on files that do not contain a shebang (unlike perl, I don't know if python source files may contain a shebang)
Related
My organization has a group policy in effect that will only allow executable programs to reside under the Program Files (or Program Files X86) directory. Obviously, these directories are not writable by normal users. I have access to local admin rights, so I can install things there if I want. But of course it doesn't make sense to put the whole cygwin tree there, since users need to be able to write to /home, /tmp, etc. I am thinking I might be able to do something with links, maybe install to c:\cygwin, then move just the /bin directory under Program Files and create a hard link to it?
Has anyone run into a similar situation and come up with an elegant solution? This is Win 7 Enterprise.
Prior to Cygwin 1.7.34, solving such problems required a fair bit of hoop-jumping,¹ but now it's easy:
If you haven't installed Cygwin yet, do so.²
If you have Cygwin installed already and you started with a version of Cygwin prior to 1.7.34, move /etc/passwd and /etc/group out of the way,³ then upgrade to the current version.
Start the Cygwin Terminal.
Open Cygwin's /etc/nsswitch.conf in your favorite text editor.⁴ Add a line like this:
db_home: /%H
That's it! When you next re-start Cygwin, it will treat your Windows profile directory as your Cygwin home directory.⁵ This means you will have useful sub-folders like Desktop and Downloads as sub-folders, which matches the way OS X and a lot of desktop Linuxes work.
Some people might not want these two directories to be treated as equivalents. You can choose any path scheme you like. For example, you could change it to /cygdrive/c/Users/%U/cygwin to put your Cygwin home folder into a cygwin subdirectory of your Windows profile directory.
This new feature of Cygwin is very powerful and can do a lot more than I show here. For example, you can change a Cygwin user home directory via AD instead, if you like. See that documentation for details.
You might also want to rearrange a few other elements of the Cygwin path scheme. You can do so by editing Cygwin's /etc/fstab file. You probably want to move /tmp, /usr/tmp, and /var/tmp to a directory that non-admin users can write to, for one thing:
c:/tmp /tmp ntfs auto 0 0
c:/tmp /usr/tmp ntfs auto 0 0
c:/tmp /var/tmp ntfs auto 0 0
This will let you install (and later update) Cygwin as an Administrator while still letting unprivileged users run Cygwin. This makes Cygwin behave more like Linux or Unix. Since most software in the Cygwin package repository comes from that world, you can count on it to behave correctly under such a scheme.
Footnotes:
The first version of this answer tells you how to do an equivalent thing with older versions of Cygwin.
Cygwin doesn't care where you install it, so if the default doesn't work for you, feel free to change it. Some ideas:
C:\Program Files\Cygwin
C:\Users\jeremy\Cygwin
D:\cygwin
Cygwin will remember your choice on subsequent updates.
If you don't move these files out of the way, they interfere with the solution we build above. This part of Cygwin is complex enough to deserve a whole section in the Cygwin user manual. Hint. :)
Cygwin installs a stripped-down version of the Vim text editor by default.
If you don't like vi, there are many other text editors in the Cygwin package repository.
If you do like vi, I suggest installing the full version of Vim, then adding alias vi=vim to your ~/.bashrc.
You can also use a native Windows GUI text editor. Cygwin's /etc/nsswitch.conf parser appears to cope with DOS line endings.
The Cygwin DLL is building this path from the %HOMEDRIVE% and %HOMEPATH% environment variables, then converting it to POSIX form.
First of all, I would like to apologize if I'm on the wrong stackexchange network, and secondly, sorry if I'm overlooking something simple.
I was moving files from my old hard drive from an old PC when I came across several password protected ZIP Files. However, since those files were a bit old, I forgot the passwords already. I tried every password I could come up with but I still came up empty. After several google searches, I found this tool/utility for Mac OS X that could help me. So I go to the downloads page and download the Mac OSX utility tool and the source code.
However, I am having problems executing the make command for the file. It says on the downloads page:
If you are using linux or another unix, you need to download the source code, uncompress it and type "make" to compile the utility.
So far, what I've tried is
$make /Users/myname/Downloads/aapr-0.01-source/Makefile
I have also tried the other files in the source folder but nothing worked. After that, I'm pretty much blank. I tried double clicking the aapr file in the utility download for Mac (which is a Unix Executable) and it opens a new terminal window displaying the commands and such. Also, doing $aapr [options] [filename] only shows me -bash: aapr: command not found. I also updated XCodes command line tools.
Sorry if I'm missing out on something very basic, I don't usually use the terminal on the OS X.
Try running
cd /Users/myname/Downloads/aapr-0.01-source
make
A Makefile contains rules for building files from other files but it is based on paths and contents, etc. which depend on your current location. So generally you need to be in the directory of the project for it to work.
Edit (copied from my comment):
To execute a command from a specific location (that isn't in the normal $PATH) you need to specify a path for it. So something like /bin/bash or ./aapr (where ./ means the current directory).
I've tried runemacs --user d:\path\to\init\.emacs but it gives
Error (initialization): Invalid user name d:\path\to\init\.emacs
I mean custom file in custom location like on my pendrive etc. and not in my default locations in user folder. I try to create a cmd files with corresponding inits for different configuration.
I am guessing that your end goal is to run Emacs from a USB drive which you can carry around. There are two ways to have Emacs start with a different init file:
(1) the -q --load way
This is simply to run
emacs -q --load path-to-your-init.el
which starts Emacs without any initialization, then loads path-to-your-init.el
Gotchas of this way: in this case, Emacs doesn't really consider the el file to be an init file, in fact, Emacs hasn't gone through initialization at all, which means the following post-initialization steps are skipped:
enabling packages, that is, evaluating (package-initialize)
running hook after-init-hook, that is, evaluating (run-hooks after-init-hook)
You may have to add post-initialization stuff in your alternate init file.
Also, Customize interface won't let you save settings if Emacs is started with -q option.
(2) the HOME way
Create my-emacs.bat with contents:
set HOME=%~dp0
C:\path-to-your\Emacs\bin\runemacs.exe --xrm "emacs.Background: light green"
When you click on that bat file, Emacs creates folder named .emacs.d not in your usual user directory, but in where the bat file is. You can put your own init.el in that .emacs.d folder. With this Emacs, evaluating (find-file "~/.emacs.d/init.el") opens your own portable init.el and not the init file in your usual user directory. You may want to delete the --xrm "emacs.Background: light green" part, I include that because I always forget which Emacs is which.
Gotchas: this Emacs has its own package directory in its own .emacs.d directory. That may or may not be what you want. If you want to share the package directory, you can change package-user-dir or create a symbolic link to the to-be-shared package directory using Link Shell Extension.
Somethings to consider for running Emacs on a USB drive:
Emacs outsources some of its features to external tools. Grepping and comparison are outsourced to grep and diff, so you probably have installed at least GnuWin32 Grep and GnuWin32 DiffUtils on your system. And part of spell checking is outsourced to aspell, which is also a separate install. Encryption is outsourced to GPG, so Gpg4Win another separate install. For your portable Emacs to have all those features, all those external tools should be on your USB drive as well. Fortunately, GnuWin32 and aspell are portable-friendly. I don't know if GPG is. The dependency to external grep may be eliminated if you manage to make versions of lgrep and rgrep that only depend on eshell's own grep, but it seems nobody has done it, so making such lgrep/rgrep is to boldly go where no man has gone before.
You can get help on all of the emacs options by typing emacs --help on the command line. That help shows that --user expect the name of a user, not the path to an elisp file.
To load a lisp file at startup you can use the --load option:
$ emacs --help
...
--load, -l FILE load Emacs Lisp FILE using the load function
...
If you want to prevent your default init file from loading, you can use this option:
$ emacs --help
...
--no-init-file, -q load neither ~/.emacs nor default.el
...
I have a MacVim setup on my OSX machine so that the default Vim application (ie: /usr/bin/vim) is actually a symbolic link to the command-line version of Vim that ships with MacVim (ie: /Applications/MacVim.app/MacOS/vim), as it provides some key benefits over the stock Vim that ships with OSX10.6.
I periodically need to prepare a diff between a set of files, and export it into a colorful side-by-side-view HTML file. This is commonly achieved via:
vim -d file1 file2
(Within Vim): toHTML
The problem with this is that I have to manually check out the HEAD revision and a specific revision of the two sets of files, and do this operation for each pair of files. This is very time consuming.
Is it possible to have the results of svn diff command piped into Vim so I can have a colorful side-by-side-view diff for an entire directory (ie: the PWD), as opposed to just the unified diff view?
I have found several Vim scripts and bash scripts that attempt to achieve this, but there are two key problems:
I wish to explicitly call vim -d as the diff tool, and not vimdiff, as the MacVim application does not appear to ship with vimdiff, so I would be using the wrong version of Vim when launching the application
I wish to have multi-file diffs generated against an entire directory recursively, as opposed to just one or two files at a time.
If this is not feasible, I could likely create a bash script that more-or-less achieves this, but I'd like to avoid putting together a hacked/unreliable script if there is a more effective means of doing this.
Thank you.
vimdiff is merely an alternate name for vim. The binary checks to see how it's launched and determines its behavior accordingly. (That's why there isn't a different file for gvim and vim also.)
On my Mac OS and Linux machines I created a ~/bin directory, and then inside it created soft-links from the various names to my macvim binary. I put ~/bin very early in my path.
I'm not at work where I could check to make sure, but I think you can change the default SVN diff to point to vimdiff in ~/.subversion/config. Look for the diff-cmd section. https://stackoverflow.com/a/9604604/128421 might give you some useful information too.
You can try my aurum plugin, it ships with :AuVimDiff command which is as well capable of viewing all changes in a multiple tabs with vimdiff split:
AuVimDiff full HEAD 300
and get diffs between two revisions without you having to checkout them manually:
AuVimDiff file file1 HEAD 300
(file file1 part is optional, it will open diffsplit with current file if omitted. All revisions are also optional, for subversion specifying one revision is diffing it with file in the working directory and specifying no revisions is like svn diff: between BASE and working directory.)
300 here is just an example revision.
I have since resolved this fully in another, more recent post of mine. Posting a backtrack URL to it for future readers:
VIM - Passing colon-commands list via command-line
Is there some sort of general pathname-rewriting/normalizing facility I can exploit in Emacs to allow source files in compile-mode to be translated to local paths based on remote paths? I was hoping to use symbolic links, but that's not working for me in Windows.
I'm running GNU Emacs 23.1.1, and have tried cygwin-mount and w32-symlinks.el (with (customize-option 'w32-symlinks-handle-shortcuts)); I can't get open-file/dired/completions OR compile-mode next-error to follow either windows shortcuts or cygwin symlinks.
I'm remotely compiling (over ssh) and the warnings/errors give filenames where a prefix of the absolute pathnames (e.g. /nfs/topaz) on the remote host needs to be replaced with a different path (z:/, in fact), which I was hoping to do with symbolic links.
/ does go to (gets tab-expanded to in emacs) c:/cygwin and ~ to z:/ (my $HOME).
What I'm hoping for is either: a fix for symlink resolution (tab completion or opening a windows shortcut gets me the .lnk file and not what it points to), or the ability to supply a list of rewrites for prefixes of pathnames. Junctions aren't an option because the replacement path I want is on a different drive (it's also a Samba mount).
Here's a partial solution:
(custom-set-variables '(compilation-search-path (quote (nil "z:/dir1" "~/dir2"))
etc. Of course, I have to add dozens of paths, but it's a huge improvement (next-error actually works now!)
This is also useful in other complicated build environments: I use OpenWRT, and the build process copies (or extracts) source code to a separate build directory in which compilation occurs. So naively following file names in the emacs compilation buffer leads to edit the temporary copies, not the originals. Dangerous.
After re-reading a few times, I still am not quite sure what your situation is -
Are you compiling remotely and editing locally? If so, it seems like you should try doing both tasks on the same machine, or maybe try tramp mode in emacs. I just don't see an easy way to translate a remote path to a local one.