[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
Thu Jan 8 13:34:00 GMT 2015
On Jan 7 18:41, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > > but that would produce some rather unwieldy and long paths for certain
> > > users. So, instead of specifying the users' home directory directly I
> > > would like to mount or auto-mount /home/≤user> to the actual (network)
> > > home directory.
> > Hmm. That's tricky. There's no automatism for that yet. Nsswitch.conf
> > only describes how to create the passwd entry for a user. It does not
> > add any mechanism to run at user context switch. And not everybody
> > would like to have something like that so it needs configuration.
> > I'm not opposed to stuff like that if it simplifies admin's job, but on
> > one hand we should evaluate first if there's a way to script that,
> > rather than to hardcode it into the Cygwin DLL, and on the other hand
> > it's not something I'd like to add for the first cut of 1.7.34...
> I agree that this is not something that belongs into nsswitch.conf, but
> since those mounts are working a bit differently on Cygwin than Linux I'd
> expect that in order to make some auto-mount facility available the DLL
> would need to know about it and provide at least some hooks to set them up
> correctly before any process tries to use them.
Adding a user mount should be scriptable. The actual home directory
is the next to last entry in the user's `getent passwd' output. In a
profile script, this entry can be used to generate a user bind mount
from the actual dir to /home/$USER. Then, set $HOME to /home/$USER.
AFAICS this doesn't require any additional DLL support.
> > > > - When spawning a process under another user account, merge the user's
> > > > default Windows environment into the new process' environment.
> > >
> > > I think this change pulls in additional environment variables with
> > > windows path components when starting programs via cygserver/sshd that
> > > are not a login shell (and perhaps when the user's login shell isn't
> > > bash, so that profile doesn't get run), most notably PATH, TMP and TEMP.
> > > If these variables are used later on by programs expecting a POSIX path
> > > there, then things break.
> > Did you try it? The idea was that these variables are converted to POSIX
> > on the way in...
> They aren't, but even if they were I don't think it's the right thing to do
> for some variables. Slightly edited:
Ok, I see. So where exactly is the problem? Variable which already
exist in the env are not overwritten ($PATH). Variables which only have
a meaning for Windows apps should stay in DOS notation anyway.
So what's left? TMP/TEMP/TMPDIR? If that's all, we have two choices,
either convert them, or skip them.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Cygwin