This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: win7 specific probs; examples; and poor solutions

2009/11/21 Linda Walsh:
>>> I still haven't figured out why -- but the values for cygdrive prefix
>>> won't stay stored.
>> That's because you now have to set it in /etc/fstab to make it
>> permanent, e.g.:
>> none /mnt cygdrive binary 0 0
> ÂI did THAT, as part of my debugging. ÂI copied over the line from my
> working XP config:
> Ânone / cygdrive binary,posix=0,user 0 0
> onto my non working Win7 config -- and it had no effect on newly started
> copies of a shell (either using minTTY or console2).

So what happened instead? Did the prefix remain /cygdrive?

Please attach cygcheck output as described at so people can have a look at what's
wrong with that install.

> I saw a section for "The Cygdrive Path Prefix", but didn't see any option
> to reset it. ÂSo I copied the working line (that I didn't create. ÂMaybe
> "mount -c" created it, but that's a guess

I think that line would have been created by setup-1.7.exe when
converting your 1.5 install. In 1.5, the cygdrive prefix was stored in
the registry.

>>> This is related to my initial complaint about the full-screen effect on
>>> setup.
>>> Setup WASN'T storing my choice -- it was blowing up to full each time.
>>> Then, ... it didn't. ÂGuess it decided to store it.
>> cgf recently implemented that.
> ÂI read that he did that -- but that doesn't explain why it worked on my
> XP machine, but not on my Win7 machine that was installed from the same
> install base.

FWIW, it's fine working on Win7 here. Any chance you're using an older
version of setup-1.7.exe?

> ÂNo waiving of hands was necessary. ÂBut a concrete example (using
> find+file to look text files under /prog/vim (/Program Files (x86)/Vim)
> and running dos2unix on each did run -- and 'vi' at cmd prompt worked.
> But later (yesterday, vi and cmd prompt gave CRLF related errors again. ÂI
> reran the conversion, differently, and it worked again.
> ÂI use VIMRUNDIR="C:/Prog/Vim", in my environment. ÂThis stems to a need
> for 'GVim' to know it's RUNTIME dir regardless of how it is invoked.
> ÂIn order for 'GVim' to effectively replace 'notepad' for all things
> text, it needs to have a link in /Windows/system32/. ÂUnfortunately, when
> invoked from there, it can't find it's RUNTIMEDIR. ÂSo I set the global
> var.
> ÂBUT, that created a problem for 'vim' under cygwin when I did edits in
> a cmd window -- as it would pickup the runtime dir in C:/Prog/Vim.
> Fortunately, the Win-version of Gvim is advanced enough to handle
> line-endings of CRLF OR LF -- so I convert all of the text files in the
> Win-version of 'Vim/Gvim' from "CRLF" to "LF". ÂThen all I need to do is
> keep the versions syncronized in major point release, and the cygwin-vim
> and Win-Gvim, can share config files.
> ÂThey also share my home dir's .vimrc, .gvimrc, and .vimdir.
> ÂIn order to not have interference with cygwin's gvim, I rename it to
> "xvim" as it uses "X". ÂI sometimes use it for it's better international
> character support. Âthe Windows Gvim is broken when it comes to handling
> non-monospaced character fonts (unicode) while the Cygwin X version
> handles them.
>>> unfortunately, it looks like I had part of my registry disappear as
>>> well -- the part having to do with HARDWARE appears to be missing --
>>> can't find the file it maps and going to the key gives a file-not found
>>> message.
>> /proc/registry/HKEY_LOCAL_MACHINE/HARDWARE looks fine here.
> ---
> Â Yes. ÂI'm happy for you. ÂAnd when did you first use something above
> 'XP'? Â(vista or Win7?) ÂI'm still in the 'oh frack, I did what?!' stage.

About three years ago I guess.

$ uname -a
CYGWIN_NT-6.1-WOW64 Tobermory 1.7.0(0.218/5/3) 2009-11-19 10:07 i686 Cygwin

> ÂSome suggest using the bogus string Â"C.utf-8", but that isn't a valid
> locale (yet). ÂI could use that, but it would cause compatibility with
> many non-broken apps that expect *valid* language strings.

And what's stopping you from setting it to "en_US.UTF-8" or whatever?


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]