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
pgpfQzbkXXt4n.pgp
Description: PGP signature
