I remember that when I first installed cygwin I could open files form my home directory using Windows applications. For example, I had Emacs installed in Windows and I could just do runemacs ~/some_file.txt. I had run out of space and had to move my cygwin installation to a different drive. Ever since then, I seem to have mucked up my installation and I can't use Windows applications like this anymore.
I have removed cygwin completely and re-installed it in C:\cygwin as before, but the problem remains.
I see that for some reason ~ gets expanded to C:\home\Tudor instead of C:\cygwin\home\Tudor.
Does anyone know how I could get this to work again?
Non-Cygwin Windows applications are not aware of your Cygwin root or home directory.
Emacs is a special case. It was originally developed on UNIX, and it uses UNIX-like syntax for some things.
According to your latest comment, Emacs expands ~ to C:\Users\Tudor. That's your Windows home directory, not your Cygwin home directory.
You can also install a Cygwin version of Emacs, which, like any Cygwin application, will expand ~ to your Cygwin home directory.
If you invoke a Windows application from a Cygwin shell, then the shell, not the Windows application, will expand ~ to your Cygwin home directory, expressed in Cgywin syntax. For example, assuming runemacs is a non-Cygwin application, if I run:
bash$ runemacs ~
then the shell expands the ~, so it's equivalent to (assuming my user name is Tudor):
bash$ runemacs /home/Tudor
runemacs will probably treat /home/Tudor as equivalent to \home\Tudor, which would be equivalent to C:\home\Tudor if the current drive is C:.
If you type Ctrl-X Ctrl-F from within Emacs to open a file, then Emacs will interpret ~ according to whatever rules it follows internally; those rules aren't likely to recognize Cygwin unless you're running a Cygwin version of Emacs or Emacs itself has some special-case code to handle Cygwin paths.
Related
Well the idea goes as followed,
I have a bash file for linux, there I obviously run it by making ./my_run.
The problem is I'm in windows so I downloaded and installed cygwin.
I added cygwin bin to the Enviromental Variables and check that at least "ls" works so I guessed I did it well.
When I try to run it with the cmd it displays:
'.' is not recognized as an internal or external command,
operable program or batch file.
As if the cygwin variables were not correctly installed (as I said I tried ls and works).
Then I tried it directly with cygwin and when doing the ./my_run I got it to work right.
So how is that I can use some commands like ls but when doing ./ it doesn't work on the cmd? How can I fix this?
Well, cygwin is only a shared library and a lot of stuff (the programs) using it (read Cygwin doc). cygwin.dll changes internally path resolution / chars to allow you to say ./my_script and converts it to .\my_script before doing the actual windows call, it also adds the proper extension to executables to allow it to execute windows binaries. This magic persists as long as you use it. cmd.exe is a Microsoft Windows command shell that is completely unaware of Cygwin's shared library and by that reason it doesn't use it, so it will not call it for path translation, even if you populate the environment of zetabytes of stuff. When you run in Cygwin terminal, you are running bash shell, which is a Cygwin executable, linked to cygwin.dll. It manages to use Cygwin library for all the unix system call emulations, so when you pass it e.g. to exec("./my_script", ...);, it internally converts that to try for ./my_script, then .\my_script, ./my_script.exe, ... and the same for .com and .bat extensions.
This fact often makes some people to say that Cygwin is not a good, efficient, environment. But the purpose was not to be efficient (and it is, as it caches entries and makes things best to be efficient) but to be compatible.
In your example ls is a Cygwin executable that mimics the /bin/ls executable from unix systems. It uses the Cygwin library, so all path resolution will be properly made (well, under some constraints, as you'll see after some testing) and everything will work fine. But you cannot pretend all your Windows applications to suddenly transform themselves and begin working as if they where in a different environment. This requires some try and error approach that you have to try yourself. And read Cygwin documentation, it is very good and covers everything I've said here.
If you open up Cygwin and run the command there you should be fine.
I want to disable cygwin temporarily without uninstalling it (e.g. for the duration of a batch script).
I was hoping there is a simple way, e.g. an environment variable like
$> SET cygwin=OFF
or an internal cygwin command like
$> cygset off
Right now I am using a quick and dirty solution that simply invalidates the cygwin directory in the Windows path with
SET PATH=%PATH:Cygwin=%
Of course this will also corrupt other pathes that have Cygwin in it.
I found this question but it didn't help. The solution in this is what I tried but it didn't work.
I am trying to create an _vimrc file on my Windows 8 computer so that the syntax of my code in vim is 1) highlighted by default and 2) maintains indents.
I entered
echo %UserProfile%
into the command prompt and it gave me C:\Users\Username.
I used vim to create a _vimrc file in C:\Users\Username and added
set autoindent
syntax on
to it. However, these changes do not register in vim.
Most questions I could find online are for Unix where the home directory is ~. The questions that did apply to Windows said to create the file in the C:\Users\Username directory which is what I'm doing.
I tried closing and reopening my command prompt but it didn't help.
Sorry if this is a really simple question; I don't use user variables that often.
The presence of /usr/share/vim/vimrc in the output of :scriptnames indicates that you are using a version of Vim provided by some unix-like compatibility layer like cygwin instead of a regular Windows build.
From the user's perspective, the cygwin environment is completely segregated from the Windows environment and you are expected to use/customize it like you would on an actual unix-like system. Mixing Windows and "Linux" (huge quotes, here) concerns is not a very good idea in such a context.
In Vim, :echo $HOME should tell you what your $HOME is from Vim's POV.
If you are indeed using cygwin, cygwin's $HOME is usually located here from Windows' POV:
C\cygwin\home\username
while Windows' $HOME is usually located here from cygwin's POV:
/cygdrive/c/Users/username
In short…
if your Vim is a regular Windows program, the standard location for your config is:
C\Users\username\_vimrc
C\Users\username\vimfiles\
You can use both the console and the explorer to deal with those files and directories.
if your Vim is provided by cygwin, the standard location for your config is:
/home/username/.vimrc
/home/username/.vim/
You are pretty much forced to use the "Cygwin Terminal" to deal with those files and directories unless you get how those are mapped to Windows paths.
Avoid thinking in Windows terms.
I ran into a similar problem on Windows 7 and 10. VIM's installer created a default vimrc file in the installation directory (in my case c:\Program Files (x86)\Vim).
After deleting this file, VIM looks in my home directory.
I recently installed Cygwin on Windows 8.1, it works great but I can't execute file using the dot, for example "./hello.ml". I'm using the Windows's command prompt.
When I try using it, it show me that "." is not reconized. How can I make it works ?
Thanks.
You need to use the cygwin terminal or powershell instead.
The command interpreter doesn't think that your files are executable because they aren't one of the types that are recognized as binary executables. In general, Windows would use file associations from the registry to make things happen when you try to run a file. The cygwin terminal follows the unix-like convention and knows that your scripts are ml files and they are executable by using the ml interpreter, most likely from a #! at the top of your file.
cygwin64 had been running great on my Windows 7 system for several months. After rebooting this morning, it appeared to be inexplicably broken. When I started a new mintty session, rather than presenting a window with my familiar bash prompt, I got a blank window entitled -sh.exe. Sure enough, despite the lack of any sort of prompt, it was a shell window. ls, pwd, cd, and other commands worked, but my environment was a mess. Aside from the lack of a prompt, my home directory, path, and other things were messed up.
I tried the normal things. I reran cygwin setup to no avail. I completely uninstalled and reinstalled cygwin, again with no discernible effect. I rebooted a number of times during all these tries. What could cause cygwin to suddenly begin behaving so badly?
I had similar issues after installing IBM InfoSphere DataStage, which causes Cygwin to misbehave because it is setting several Windows environment that are inherited by Cygwin, and are crucial to Mintty and the shell. These variables are: SHELL, TERM, TERMCAP, and TERMINFO.
I modified my Mintty shortcut to contain the following target, and this fixed the issues:
C:\cygwin\bin\mintty.exe /bin/env -u SHELL -u TERMCAP -u TERMINFO - TERM=xterm-256color HOME=/home/username /bin/bash -i -l
The -u options are unsetting those variables, and then I'm explicitly setting TERM and HOME (make sure to use your home directory instead of /home/username).
I also had to copy my ~/.minttyrc file to /etc/minttyrc so that mintty would see it.
After digging around, I noticed that the sh.exe that was running was not in /cygwin64/bin, but was instead in \Program Files (x86)\MKS Toolkit. I did not recall installing MKS, but the date on this directory was from the previous day. The only thing I'd recently installed was the IBM InfoSphere DataStage client. It turns out, InfoSphere not only installs the MKS Toolkit, it prepends it to a number of environment variables, totally hosing cygwin.