Corinna Vinschen cygwin.com> writes:
> > This isn't set yet in our domain, but there's another AD just for the
> > UNIX accounts (I haven't looked at how that one is structured yet).
> > There's talk about maybe unifying these two AD in the future, but I have
> > no idea how that would work.
>
>
Greetings, Yaakov Selkowitz!
>> When I implemented the new scheme I thought it a good idea to decouple
>> the Cygwin home dir from the Windows home dir. However, in the today's
>> discussion the following two arguments came up:
>>
>> - If you're using the Windows home folder setting to maintain f
Corinna Vinschen wrote:
On Nov 10 20:21, Christian Franke wrote:
Corinna Vinschen wrote:
On Nov 7 21:51, Christian Franke wrote:
Corinna Vinschen wrote:
In theory there should be only one option -l [machine], which prints the
local accounts of the current machine unprefixed (standalone machi
Greetings, Andrew DeFaria!
> On 11/10/2014 4:45 PM, Andrey Repin wrote:
>> I see literally zero reason to maintain separate, cygwin-specific "home"
>> directory.
> My reason to have a separate, cygwin-specific "home" directory is to
> have one that is shared between Cygwin and Linux.
I do that
On Nov 10, 2014, at 6:38 PM, Jeffrey Altman
wrote:
> My personal preference would be for the Cygwin Home directory to be
> created under
>
> %HOMEPATH%\AppData\Roaming\Cygwin
That’s certainly the way you’re *supposed* to do it on Windows.
There’s some value in using %USERPROFILE% for this, h
On Nov 10, 2014, at 1:52 PM, Corinna Vinschen wrote:
> Shall the "db" entries utilize the Windows home folder if it exits(*)
> and drop using the unixHomeDirectory? It seems inevitable…
Use of AD implies some level of security consciousness. The ability to write
to c:\cygwin — not just during
On Nov 10, 2014, at 9:26 PM, Yaakov Selkowitz wrote:
> On 2014-11-10 14:52, Corinna Vinschen wrote:
>>
>> Shall the "db" entries utilize the Windows home folder if it exits(*)
>> and drop using the unixHomeDirectory? It seems inevitable...
>
> If one uses the same program, one native Windows a
On 2014-11-10 22:23, Yaakov Selkowitz wrote:
Dependency order of packages: libgcc1 base-cygwin cygwin dash tzcode
libstdc++6 terminfo sed gzip libpcre1 grep libreadline7 bash
libncursesw10
[snip]
Now that I think about it, regardless of libgcc1, that still doesn't
make much sense. sed, grep,
On 2014-11-10 14:52, Corinna Vinschen wrote:
When I implemented the new scheme I thought it a good idea to decouple
the Cygwin home dir from the Windows home dir. However, in the today's
discussion the following two arguments came up:
- If you're using the Windows home folder setting to maintai
On 2014-11-04 02:59, Corinna Vinschen wrote:
On Nov 3 19:03, Achim Gratz wrote:
Dependencies are not evaluated at all when installing or running
scripts.
That's not correct. From the dependencies, setup generates a dependency
graph which is used to get a sequential order in which to call
the
On 11/10/2014 4:45 PM, Andrey Repin wrote:
I see literally zero reason to maintain separate, cygwin-specific "home"
directory.
My reason to have a separate, cygwin-specific "home" directory is to
have one that is shared between Cygwin and Linux. Windows define home
directories rarely are sha
On 11/10/2014 3:52 PM, Corinna Vinschen wrote:
> Hi,
>
>
> after a long discussion in RL today, I came to the conclusion that
> there's a major problem in the current handling of the user's home
> directory in AD environments in the new user account code when not using
> /etc/passwd files.
My p
Greetings, Corinna Vinschen!
> Up to Cygwin 1.7.32, mkpasswd (but not with -u) generated the Cygwin
> home directory by converting the SAM/AD home folder entry to POSIX
> style, if it's non-empty. Fallback is /home/$USER.
> When I implemented the new scheme I thought it a good idea to decouple
>
On Nov 10 22:18, Achim Gratz wrote:
> Corinna Vinschen writes:
> > - If your account is an AD account, the home directory is taken from the
> > RFC 2307 entry unixHomeDirectory.
>
> This isn't set yet in our domain, but there's another AD just for the
> UNIX accounts (I haven't looked at how tha
On Nov 10 21:29, Corinna Vinschen wrote:
> On Nov 10 14:53, Pierre A. Humblet wrote:
> > > > I just realized that deleting the /etc/passwd file in existing domain
> > > > systems may change usernames, which will break cron and other programs
> > > > that use files named after usernames. Also the (l
Corinna Vinschen writes:
> - If your account is an AD account, the home directory is taken from the
> RFC 2307 entry unixHomeDirectory.
This isn't set yet in our domain, but there's another AD just for the
UNIX accounts (I haven't looked at how that one is structured yet).
There's talk about may
Greetings, Andrew DeFaria!
>>> (CMD.EXE doesn't like UNC paths.) I hadn't realized that I could
>>> pipe a script into bash.
>>
>> reg ADD "HKEY_CURRENT_USER\Software\Microsoft\Command Processor" /f /v
>> "DisableUNCCheck" /t REG_DWORD /d 1
>>
>> And speaking of "doesn't like", it only don't like
Hi,
after a long discussion in RL today, I came to the conclusion that
there's a major problem in the current handling of the user's home
directory in AD environments in the new user account code when not using
/etc/passwd files.
Here's how it works and how it's documented in the preliminary
doc
On Nov 10 20:21, Christian Franke wrote:
> Corinna Vinschen wrote:
> >On Nov 7 21:51, Christian Franke wrote:
> >>Corinna Vinschen wrote:
> >In theory there should be only one option -l [machine], which prints the
> >local accounts of the current machine unprefixed (standalone machine) or
On Nov 10 14:53, Pierre A. Humblet wrote:
> > -Original Message-
> > From: Corinna Vinschen
> > Sent: Mon, 10 Nov 2014 12:09:17 +0100
> > On Nov 7 13:04, Pierre A. Humblet wrote:
> > > > -Original Message-
> > > > From: Pierre A. Humblet
> > > > Sent: Thursday, November 06, 2014 1
On 11/10/2014 10:57 AM, Andrey Repin wrote:
Greetings, Nellis, Kenneth!
(CMD.EXE doesn't like UNC paths.) I hadn't realized that I could
pipe a script into bash.
reg ADD "HKEY_CURRENT_USER\Software\Microsoft\Command Processor" /f /v
"DisableUNCCheck" /t REG_DWORD /d 1
And speaking of "doesn
> -Original Message-
> From: Corinna Vinschen
> Sent: Mon, 10 Nov 2014 12:09:17 +0100
> On Nov 7 13:04, Pierre A. Humblet wrote:
> > > -Original Message-
> > > From: Pierre A. Humblet
> > > Sent: Thursday, November 06, 2014 16:09
> > >
> > > > -Original Message-
> > > > >
Am 09.11.2014 14:38, schrieb Doug Henderson:
On 9 November 2014 03:43, Wafer CCC wrote:
Hello,
I'm french and i use cygwin on Windows 7, and I have a problem with accents.
When i tape :
net start
Accents are not correctly displayed.
If you are running cygwin in the default mintty console, c
Corinna Vinschen wrote:
On Nov 7 21:51, Christian Franke wrote:
Corinna Vinschen wrote:
In theory there should be only one option -l [machine], which prints the
local accounts of the current machine unprefixed (standalone machine) or
prefixed (domain machine), and always prefixed for a foreign
Greetings, Nellis, Kenneth!
> (CMD.EXE doesn't like UNC paths.) I hadn't realized that I could
> pipe a script into bash.
reg ADD "HKEY_CURRENT_USER\Software\Microsoft\Command Processor" /f /v
"DisableUNCCheck" /t REG_DWORD /d 1
And speaking of "doesn't like", it only don't like it's own CWD to
Nellis, Kenneth writes:
> Jeremy's solution is closest to what I was looking for; however
> I need it to work from a networked, non-drive-mapped folder.
> (CMD.EXE doesn't like UNC paths.) I hadn't realized that I could
> pipe a script into bash.
The solution to the UNC path problem is to put som
> From: Jeremy Bopp
>
> On 11/07/2014 03:26 PM, Nellis, Kenneth wrote:
> > I'm tired of creating pairs of script files: a clickable .BAT file to
> > invoke my shell script and then my shell script to do the actual work.
> > I was wondering if any of the geniuses on this list have come up with
> >
On Mon, Nov 10, 2014 at 04:04:53PM +0300, Pavel Fedin wrote:
> Today i have updated 64-bit Cygwin and my antivirus gave me an alert:
> --- cut ---
> Filename RiskAction Risk Type Original
> Location ComputerUser
> Status
> ration
On Nov 10 13:51, Jan Nijtmans wrote:
> 2014-11-10 12:55 GMT+01:00 Corinna Vinschen :
> > If this is for loading modules via dlopen, the solution should be to
> > either to add the directory to LD_LIBRARY_PATH, or enhance Cygwin if
> > it's an issue with loading dependent DLLs. We can still add
> >
On Nov 10 12:14, Corinna Vinschen wrote:
> On Nov 7 16:16, Tim Prince wrote:
> >
> > On 11/7/2014 4:11 AM, Corinna Vinschen wrote:
> > >
> > > - GCC 4.9.2-1 DLLs accidentally call __cxa_atexit with the wrong DSO
> > > handle value. This Cygwin update allows this scenario throughout.
> > > It
2014-11-10 12:55 GMT+01:00 Corinna Vinschen :
> If this is for loading modules via dlopen, the solution should be to
> either to add the directory to LD_LIBRARY_PATH, or enhance Cygwin if
> it's an issue with loading dependent DLLs. We can still add
> LoadLibraryEx(LOAD_WITH_ALTERED_SEARCH_PATH).
On Nov 10 12:36, Jan Nijtmans wrote:
> 2014-11-08 22:41 GMT+01:00 Alexpux:
> > Hi!
> > We tried to update MSYS2 sqlite3 to the same version and found that on i686
> > doesn’t work properly because the wrong calling convention is used when
> > calling GetModuleHandleW and SetDllDirectoryW.
> > Her
2014-11-08 22:41 GMT+01:00 Alexpux:
> Hi!
> We tried to update MSYS2 sqlite3 to the same version and found that on i686
> doesn’t work properly because the wrong calling convention is used when
> calling GetModuleHandleW and SetDllDirectoryW.
> Here is the patch to fix this issue:
Thank you very
On Nov 7 16:16, Tim Prince wrote:
>
> On 11/7/2014 4:11 AM, Corinna Vinschen wrote:
> >
> > - GCC 4.9.2-1 DLLs accidentally call __cxa_atexit with the wrong DSO
> > handle value. This Cygwin update allows this scenario throughout.
> > It now understands *any* DSO handle value, as long as it'
On Nov 7 13:04, Pierre A. Humblet wrote:
> > -Original Message-
> > From: Pierre A. Humblet
> > Sent: Thursday, November 06, 2014 16:09
> >
> > > -Original Message-
> > > From: Corinna Vinschen
> > > Sent: Thursday, November 06, 2014 13:51
> > >
> > > On Nov 6 13:38, Kelley Cook
On Nov 7 16:12, David Stacey wrote:
> On 07/11/2014 06:37, Christian Franke wrote:
> >Package search shows 156 usr/bin/*-config scripts. How many of these use
> >mkpasswd?
>
> The following scripts from /usr/bin invoke mkpasswd:
>
> /usr/bin/cron-config
> /usr/bin/exim-config
> /usr/
On Nov 7 21:51, Christian Franke wrote:
> Corinna Vinschen wrote:
> >>>In theory there should be only one option -l [machine], which prints the
> >>>local accounts of the current machine unprefixed (standalone machine) or
> >>>prefixed (domain machine), and always prefixed for a foreign machine.
>
37 matches
Mail list logo
