[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)

[Corinna Vinschen]

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.

What's better?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20150108/baa793c8/attachment.sig>