Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.6

[Corinna Vinschen]

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.
> >>>The -L option can just go away.
> >>I disgree.
> >>
> >>Why not keep the old behavior of -l/-L for user names of current machine for
> >>those uses cases which rely on it?
> >You are always free to change the passwd/group files manually:
> >
> >   $ mkpasswd -l | sed -e 's/^[^:]*+//' > /etc/passwd
> 
> Of course, and it is good that this is still possible. But this would
> require that all existing scripts relying on old behavior need to be
> changed.
> 
> I still don't understand why this backward compatibility break of "mkpasswd
> -l" was mandatory.
> 
> Most *-config scripts using "mkpasswd -l -u USER" may need to be changed.

Definitely.  The change is inevitable since most scripts using mkpasswd
or mkgroup do so to create entries in /etc/passwd and /etc/group.  But
this doesn't make sense anymore, or if so, only marginally so.

> Local scripts from Cygwin users which use "mkpasswd -l" may need to be
> changed.

They are not supposed to use mkpasswd anymore since they don't need it,
only in very special circumstances.  And then I expect that they will
have to change the created files manually anyway.

> Scripts tested by maintainers only outside a domain may no longer
> work inside a domain.

Hang on.  If you think this through, what is the supposed end result?
What's the naming scheme you're proposing for local and domain accounts?

The default is supposed to be not using the passwd and group files
anymore.  The account databases are not maintained by Cygwin, they are
maintained by the outside Windows world.  In multi-domain environments,
collisions will occur if the naming scheme doesn't take the domain into
account.  Local accounts may (well, do) collide with domain accounts.

What you say here sounds like the existing naming scheme (just use the
user name and note it in /etc/passwd) is the one which we have to keep
for backward compatibility, at least as default.

> An IMO better way would be to keep the old "mkpasswd -l" behavior and invent
> a new option for the output with the new non-domain/domain prefix handling.
> 
> Then  a user would be able to "opt-in" for "local users of a domain machine
> always have a prefix" by
>   $ mkpasswd --the-new-local-option > /etc/passwd
> or even simpler:
>   $ > /etc/mkpasswd
> 
> A user could "opt-out" by simply keeping all everything as-is for now :-)

Which means, everybody opts out be default.  The new default is the
old default and nobody uses the "db" method since /etc/passwd and
/etc/group files are "good enough".

> This IMO would provide a much smother migration path.

IMHO this would not provide a migration path at all.  It would just
cement the status quo.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpaS6Xb7sM4d.pgp
Description: PGP signature

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.6

[Corinna Vinschen]

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/bin/makepasswd
> /usr/bin/nfs-server-config
> /usr/bin/pure-ftpd-config
> /usr/bin/ssh-host-config

This is a surprisingly low number.  I'm relieved.

ssh-host-config is fixed in the meantime, patches are (mostly) upstream.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpWhxS3yi2ZW.pgp
Description: PGP signature

Re: TEST RELEASE: Cygwin 1.7.33-0.7

[Corinna Vinschen]

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 wrote:
> > > > On Thu, Nov 6, 2014 at 10:52 AM, Corinna Vinschen wrote:
> > > > > Hi Cygwin friends and users,
> > > > >
> > > > >
> > > > > I just released a 7th TEST version of the next upcoming Cygwin
> > > > > release, 1.7.33-0.7.
> > > > >
> > > >
> > > > I discovered that /usr/bin/cron-config which is part of the cron
> > > > package will need to be updated as it attempts to parse /etc/group .
> > >
> > > Right, it should use getent instead.  Pierre?
> > 
> > Right, and ditto for exim config and postinstall How much time do I have?
> > 
> > Now cron-config checks if a username appears multiple times in passwd.
> > Typically one instance is a domain id and the other one is a local id.
> > That causes havoc with cron
> > It happens fairly frequently; there was even such a "bug report" recently.
> > 
> > How does getent handle that case? Is it detectable from a config file?
>  
> Corinna
> 
> 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 (local) privileged
> username will change.

Yes.  Is there a way to accommodate that?  Maybe a postinstall script
checking for existing user cron files and renaming them if required?

The privileged user name shouldn't matter much after configuration.

> For now I have made the following changes to cron-config:
>   calling getent
>   checking if /etc/passwd exists
>   dealing with the extended names for privileged users (they may
>   contain a +, don't use EREs)  

I just scanned it quickly, but the change looks good.

For all of this, apart from the Cygwin-internal stuff, I'm in the same
boat as anybody else.  I'm not entirely sure about all the consequences
this change will have, and we might all be missing something crucial
during the transition.

> Do you intend to keep mkpasswd/mkgroup ?

Yes.  It's still supposed to be used if somebody needs passwd entries
for some reason.  For the details, see the preliminary documentation
at https://cygwin.com/preliminary-ug/ntsec.html
and https://cygwin.com/preliminary-ug/using-utils.html#mkpasswd
and https://cygwin.com/preliminary-ug/using-utils.html#mkgroup.

Note also the discussion with Christian starting at
https://cygwin.com/ml/cygwin/2014-11/msg00095.html

I have a potential patch in the loop which implements what I wrote here:
https://cygwin.com/ml/cygwin/2014-11/msg00121.html

> I still don't have a 64 bit system, but it's coming this year. It will
> take me some time to prepare a new cron package and get familiar with
> the new package upload procedure.  I am attaching a cron-config diff.
> Feel free to update the 32 and 64 bit cron packages if you want that
> done quickly.  cronbug does not seem to require any changes.

Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpAA9FoiiUm4.pgp
Description: PGP signature

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.8

[Corinna Vinschen]

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's a pointer
> >   into the DSO's address space.
> >   This fixes: https://cygwin.com/ml/cygwin/2014-11/msg00122.html
> >
> >   If you don't build applications or DLLs with Cygwin, you can safely
> >   ignore this change.
> >
> >
> > If you want to help testing this new release (which I seriously hope
> > for), you can find it in your setup-x86.exe or setup-x86_64.exe as
> > "test" release.
> >
> >
> >
> I take it from now on it should be OK to take the default for 
> 
> __cxa_atexit
> 
> when configuring to build gcc.  Thanks for explanation.
> I'm repeating some tests with 1.7.33-0.8 and gcc/gfortran 4.9.2-1
> 
> no surprises, thanks (following segfault apparently unchanged, running with 
> AV and Defender disabled, but failure not seen with gfortran 5.0):
> 
> Program received signal SIGSEGV: Segmentation fault - invalid memory 
> reference.
> 
> Backtrace for this error:
> 1181925 [main] profile_omp 3684 fixup_mmaps_after_fork: ReadProcessMemory 
> failed
>  for MAP_PRIVATE address 0x6FE5FC6, Win32 error 998

This probably means that there's an mmap'ed memory region which Cygwin
has in its bookkeeping list, but which doesn't exist in the parent
process anymore.  The problem here is that it's totally unclear how
something like this could have happened.

> 2248013 [main] profile_omp 3684 
> C:\users\tim\tim\tim\src\campbell\Profile_send_3
> Nov14\profile_omp.exe: *** fatal error in forked process - 
> recreate_mmaps_after_
> fork_failed
> 3891395 [main] profile_omp 3684 cygwin_exception::open_stackdumpfile: Dumping 
> st
> ack trace to profile_omp.exe.stackdump
>   6 [main] profile_omp 1992 fork: child -1 - forked process 3684 died 
> unexpe
> ctedly, retry 0, exit code 0x100, errno 11
>   11849 [main] profile_omp 1992 cygwin_exception::open_stackdumpfile: Dumping 
> st
> ack trace to profile_omp.exe.stackdump

Does that happen under Cygwin 1.7.32 as well?  Can you create a simple
testcase, preferredly in plain C, which allows to reproduce this?


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgp3M17yvql2l.pgp
Description: PGP signature

Re: [ANNOUNCEMENT] Updated: sqlite3-3.8.7.1-1 for Cygwin/Cygwin64

[Jan Nijtmans]

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 much!

sqlite3-3.8.7.1-2 for Cygwin (i686 only) is available now with this fix
(SetDllDirectoryW was used for Cygwin too, so this might have had
an undesired side effect, even though I am not aware of any).

win32/win64 dll's using the same amalgamation sources are available here:
   
those dll's should be usable for msys2 as-is (if there is something wrong
with that, please let me know).

Regards,
Jan Nijtmans

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: sqlite3-3.8.7.1-1 for Cygwin/Cygwin64

[Corinna Vinschen]

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.
> > Here is the patch to fix this issue:
> 
> Thank you very much!
> 
> sqlite3-3.8.7.1-2 for Cygwin (i686 only) is available now with this fix
> (SetDllDirectoryW was used for Cygwin too, so this might have had
^^^
What for?  This should not be necessary.

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).

Ultimately a Cygwin application should not have to call Win32 functions,
except if there's really no way around it.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpQq9IHppSSL.pgp
Description: PGP signature

Re: [ANNOUNCEMENT] Updated: sqlite3-3.8.7.1-1 for Cygwin/Cygwin64

[Jan Nijtmans]

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).
>
> Ultimately a Cygwin application should not have to call Win32 functions,
> except if there's really no way around it.

I'm fully aware of that. But until my patches to the "unix-cygwin" VFS
are not accepted upstream I like to keep the "win32" VFS working
as well. So people can choose whether they like the Win32 way
or the Cygwin way, both simply work.

Regards,
   Jan Nijtmans

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.8

[Corinna Vinschen]

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 now understands *any* DSO handle value, as long as it's a pointer
> > >   into the DSO's address space.
> > >   This fixes: https://cygwin.com/ml/cygwin/2014-11/msg00122.html
> > >
> > >   If you don't build applications or DLLs with Cygwin, you can safely
> > >   ignore this change.
> > >
> > >
> > > If you want to help testing this new release (which I seriously hope
> > > for), you can find it in your setup-x86.exe or setup-x86_64.exe as
> > > "test" release.
> > >
> > >
> > >
> > I take it from now on it should be OK to take the default for 
> > 
> > __cxa_atexit
> > 
> > when configuring to build gcc.  Thanks for explanation.
> > I'm repeating some tests with 1.7.33-0.8 and gcc/gfortran 4.9.2-1
> > 
> > no surprises, thanks (following segfault apparently unchanged, running with 
> > AV and Defender disabled, but failure not seen with gfortran 5.0):
> > 
> > Program received signal SIGSEGV: Segmentation fault - invalid memory 
> > reference.
> > 
> > Backtrace for this error:
> > 1181925 [main] profile_omp 3684 fixup_mmaps_after_fork: ReadProcessMemory 
> > failed
> >  for MAP_PRIVATE address 0x6FE5FC6, Win32 error 998
> 
> This probably means that there's an mmap'ed memory region which Cygwin
> has in its bookkeeping list, but which doesn't exist in the parent
> process anymore.  The problem here is that it's totally unclear how
> something like this could have happened.
> [...]
> Does that happen under Cygwin 1.7.32 as well?  Can you create a simple
> testcase, preferredly in plain C, which allows to reproduce this?

The only reason I can think of would be the fork synchronization between
parent and child allowing the parent to unmap memory before the child
copied it.

However, I fail to reproduce this with default application means:

#include 
#include 
#include 
#include 

int
main ()
{
  int status;
  void *addr;

  addr = mmap (NULL, 65536, PROT_READ | PROT_WRITE,
   MAP_ANONYMOUS | MAP_PRIVATE, -1, (size_t) 0);
  printf ("Address %p\n", addr);
  switch (fork ())
{
case 0: // child
  printf ("child %p\n", addr);
  break;
case -1:
  break;
default:// parent
  munmap (addr, 65536);
  wait (&status);
  break;
}
  return 0;
}


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgp9j0s3vIO44.pgp
Description: PGP signature

Re: [ANNOUNCEMENT] Updated: sqlite3-3.8.7.1-1 for Cygwin/Cygwin64

[Corinna Vinschen]

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
> > LoadLibraryEx(LOAD_WITH_ALTERED_SEARCH_PATH).
> >
> > Ultimately a Cygwin application should not have to call Win32 functions,
> > except if there's really no way around it.
> 
> I'm fully aware of that. But until my patches to the "unix-cygwin" VFS
> are not accepted upstream I like to keep the "win32" VFS working
> as well. So people can choose whether they like the Win32 way
> or the Cygwin way, both simply work.

Ok, no worries.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgppjXnpBHhXC.pgp
Description: PGP signature

Re: Ruby library infected ???

[Adam Dinwoodie]

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
> rational.so   Trojan.ADH  Pending AnalysisFile; Virus
> C:\cygwin64\lib\ruby\2.0.0\mathn\ FEDINW7X64  p.fedin Infected
> --- cut ---
>  Can anybody recheck this ?

This has previously been reported on the main list; see the below link
and its replies.

https://cygwin.com/ml/cygwin/2014-10/msg00532.html

I'm replying to the main list and CCing you in case you're not
subscribed to that; the cygwin-apps list is for package maintainers to
discuss packaging issues, not for discussing problems with a package.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: how to embed shell script within a .BAT file

[Nellis, Kenneth]

> 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
> > a way to embed a shell script inside a clickable .BAT file.
> Something like this might do.  It assumes you know the path to the Cygwin
> bin directory.  Passing in arguments would be a bit more work and would
> probably be somewhat limited unless you have a small number of possible
> arguments.
> 
> FYI, I don't have a Windows system readily available anymore, so this is
> untested.
> 
> Shelly.bat:
> 
> @echo off
> 
> rem Put Cygwin bin directory into PATH
> set PATH=C:\cygwin\bin;%PATH%
> 
> type %0 | sed "0,/^---BASH SCRIPT FOLLOWS---/ d; s/\r*$//" | bash
> goto :eof
> 
> ---BASH SCRIPT FOLLOWS---
> echo $SHELL is alive
> ^Z

Thanx to Jeremy, Andrey, and the others who responded.

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.

Andrey also suggested something that allows Windows-clickable
script files, a strict requirement, bypassing the stated, but
unnecessary requirement that it be a .BAT file, by associating 
a file type with bash. This would bypass the UNC issue, so may 
end up being the best solution for me.

--Ken Nellis

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: how to embed shell script within a .BAT file

[Achim Gratz]

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 something

PUSHD %~dp0

near the beginning of the script.  That is if you really want to have
.bat files and click on them in Explorer.  Associating the shell scripts
properly so that Explorer will hand them to Cygwin sounds like a better
solution to me.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: how to embed shell script within a .BAT file

[Andrey Repin]

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 be UNC path.
You can still start programs by full UNC path from CMD.
Though, with correct settings (see above), the point is moot.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 10.11.2014, <21:56>

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.6

[Christian Franke]

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 machine.
The -L option can just go away.

I disgree.

Why not keep the old behavior of -l/-L for user names of current machine for
those uses cases which rely on it?

You are always free to change the passwd/group files manually:

   $ mkpasswd -l | sed -e 's/^[^:]*+//' > /etc/passwd

Of course, and it is good that this is still possible. But this would
require that all existing scripts relying on old behavior need to be
changed.

I still don't understand why this backward compatibility break of "mkpasswd
-l" was mandatory.

Most *-config scripts using "mkpasswd -l -u USER" may need to be changed.

Definitely.  The change is inevitable since most scripts using mkpasswd
or mkgroup do so to create entries in /etc/passwd and /etc/group.  But
this doesn't make sense anymore, or if so, only marginally so.


OK.

What will be the behavior of the predecessor of e.g. the csih function 
csih_create_unprivileged_user if called with USER without HOST prefix, 
machine is inside of domain and the user does not exist:
- create local windows USER and require the config script to retrieve 
the actual Cygwin HOST+USER name,
- fail and tell the calling config script to retry with HOST+USER 
instead (if possible),
- create local windows USER and create a /etc/passwd entry to support a 
non-prefixed Cygwin USER in this case,

- one of the above, selected by a new option.
- ...
?



Local scripts from Cygwin users which use "mkpasswd -l" may need to be
changed.

They are not supposed to use mkpasswd anymore since they don't need it,
only in very special circumstances.


Wouldn't it be better to let mkpasswd -l simply fail with an explanatory 
error message instead of producing non-backward compatible results? Or 
at least print a warning to stderr?




   And then I expect that they will
have to change the created files manually anyway.


It depends. One of my use cases relies on non-prefixed local user names 
which match the (also non-prefixed :-) windows local user names. The 
usual duplicates with domain users (Administrator, Guest) never resulted 
in any problems.


Christian


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with accents

[Thomas Wolff]

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, check the
setting of the locale and character set in the mintty settings. ...
... they should display correctly when you "cat" the
file from cygwin.

Tony wrote:
You may also want/need to change the display font in mintty. I've 
found DejaVu Sans Mono has better Unicode support than the default font. 
This problem is neither related to locale settings, nor to character set 
or font settings of mintty.

Note that 'net' is not a cygwin program but a Windows program.
As such, it has its very own idea of how to configure output character 
encoding which is unrelated to cygwin locale settings.
You can try to issue 'chcp.com 65001' in the Cygwin terminal. This helps 
for *some* Windows programs but not for many. I'm not sure right now 
whether 'net' belongs to them.

--
Thomas

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: TEST RELEASE: Cygwin 1.7.33-0.8

[Pierre A. Humblet]

> -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-
> > > > > From: Corinna Vinschen
> > > > Sent: Thursday, November 06, 2014 13:51
> > > >
> > > > On Nov  6 13:38, Kelley Cook wrote:
> > > > > On Thu, Nov 6, 2014 at 10:52 AM, Corinna Vinschen wrote:
> > > > > > Hi Cygwin friends and users,
> > > > > >
> > > > > >
> > > > > > I just released a 7th TEST version of the next upcoming Cygwin
> > > > > > release, 1.7.33-0.7.
> > > > > >
> > > > >
> > > > > I discovered that /usr/bin/cron-config which is part of the cron
> > > > > package will need to be updated as it attempts to parse /etc/group
.
> > >
> > > > Right, it should use getent instead.  Pierre?
> > 

> > 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 (local) privileged
> > username will change.

> Yes.  Is there a way to accommodate that?  Maybe a postinstall script
> checking for existing user cron files and renaming them if required?

That's possible but it must be a postinstall than runs when an updated
Cygwin is installed (or deinstalled), not when cron is, except if we try to
synchronize both.

> The privileged user name shouldn't matter much after configuration.

Agreed, but see below

> For now I have made the following changes to cron-config:
>   calling getent
>   checking if /etc/passwd exists
>   dealing with the extended names for privileged users (they may
>   contain a +, don't use EREs)  

> I just scanned it quickly, but the change looks good.

OK. Do you want to produce a test release for the crons?



> Note also the discussion with Christian starting at
> https://cygwin.com/ml/cygwin/2014-11/msg00095.html

I am fine with the prefix but there is something we should agree on about
the special 
privileged names like cyg_server.

What I did is to create an entry for them in /etc/passwd. The reason is that
the shell 
is changed to /bin/false and I don't want to deal with setting that in the
Windows 
databases (I can't test all possible variations).
Now when we create a passwd entry, we can include the prefix, as I did, or
remove it.
csih and the other similar scripts should agree on that, otherwise they may
reuse
the privileged user (based on the Windows database) but create different
passwd entries.
Of course removing the prefix can create a conflict with a cyg_server domain
user.

Pierre




--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: how to embed shell script within a .BAT file

[Andrew DeFaria]

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't like", it only don't like it's own CWD to be UNC path.
You can still start programs by full UNC path from CMD.
Though, with correct settings (see above), the point is moot.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 10.11.2014, <21:56>

Sorry for my terrible english...




I always thought it odd that MS invents UNC's then fails to support them 
properly in their own tools.


Try pushd on a UNC path...
--
Andrew DeFaria
http://defaria.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: TEST RELEASE: Cygwin 1.7.33-0.8

[Corinna Vinschen]

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 16:09
> > > > 
> > > > > -Original Message-
> > > > > > From: Corinna Vinschen
> > > > > Sent: Thursday, November 06, 2014 13:51
> > > > >
> > > > > On Nov  6 13:38, Kelley Cook wrote:
> > > > > > On Thu, Nov 6, 2014 at 10:52 AM, Corinna Vinschen wrote:
> > > > > > > Hi Cygwin friends and users,
> > > > > > >
> > > > > > >
> > > > > > > I just released a 7th TEST version of the next upcoming Cygwin
> > > > > > > release, 1.7.33-0.7.
> > > > > > >
> > > > > >
> > > > > > I discovered that /usr/bin/cron-config which is part of the cron
> > > > > > package will need to be updated as it attempts to parse /etc/group
> .
> > > >
> > > > > Right, it should use getent instead.  Pierre?
> > > 
> 
> > > 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 (local) privileged
> > > username will change.
> 
> > Yes.  Is there a way to accommodate that?  Maybe a postinstall script
> > checking for existing user cron files and renaming them if required?
> 
> That's possible but it must be a postinstall than runs when an updated
> Cygwin is installed (or deinstalled), not when cron is, except if we try to
> synchronize both.

A new cron when Cygwin 1.7.33 goes release might be a good idea.
I have already new OpenSSH and, even more important, base-cygwin
packages waiting in the backdrop.

> > The privileged user name shouldn't matter much after configuration.
> 
> Agreed, but see below
> 
> > For now I have made the following changes to cron-config:
> >   calling getent
> >   checking if /etc/passwd exists
> >   dealing with the extended names for privileged users (they may
> >   contain a +, don't use EREs)  
> 
> > I just scanned it quickly, but the change looks good.
> 
> OK. Do you want to produce a test release for the crons?

Oh please, no.  I really have a hell of a lot to do already getting my
own stuff and csih working, and it would be very helpful not having to
care for more.

> > Note also the discussion with Christian starting at
> > https://cygwin.com/ml/cygwin/2014-11/msg00095.html
> 
> I am fine with the prefix but there is something we should agree on
> about the special privileged names like cyg_server.
> 
> What I did is to create an entry for them in /etc/passwd. The reason
> is that the shell is changed to /bin/false and I don't want to deal
> with setting that in the Windows databases (I can't test all possible
> variations).

This has been done in the csih helper script as well, but we can't do
that anymore if the system doesn't use the files in /etc.

> Now when we create a passwd entry, we can include the prefix, as I
> did, or remove it.  csih and the other similar scripts should agree on
> that, otherwise they may reuse the privileged user (based on the
> Windows database) but create different passwd entries.  Of course
> removing the prefix can create a conflict with a cyg_server domain
> user.

Writing a passwd entry is only ok if the system is using the "passwd:
files"-only setting, but otherwise we should not write to passwd.  It's
not correct to rely on the existence of the file anymore.  I'm tweaking
csih accordingly.  It will create the system account (still only as
local account, never a domain account), and then it checks if
/etc/nsswitch.conf exists and the "passwd:" setting is "files"-only.
Only then it will write a passwd entry using the prefix if required.

Writing the shell for a local account to SAM is easy from bash:

  net user cyg_server /add \
/comment:""


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpFxl3LtpNIW.pgp
Description: PGP signature

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.6

[Corinna Vinschen]

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
> >prefixed (domain machine), and always prefixed for a foreign machine.
> >The -L option can just go away.
> I disgree.
> 
> Why not keep the old behavior of -l/-L for user names of current machine 
> for
> those uses cases which rely on it?
> >>>You are always free to change the passwd/group files manually:
> >>>
> >>>   $ mkpasswd -l | sed -e 's/^[^:]*+//' > /etc/passwd
> >>Of course, and it is good that this is still possible. But this would
> >>require that all existing scripts relying on old behavior need to be
> >>changed.
> >>
> >>I still don't understand why this backward compatibility break of "mkpasswd
> >>-l" was mandatory.
> >>
> >>Most *-config scripts using "mkpasswd -l -u USER" may need to be changed.
> >Definitely.  The change is inevitable since most scripts using mkpasswd
> >or mkgroup do so to create entries in /etc/passwd and /etc/group.  But
> >this doesn't make sense anymore, or if so, only marginally so.
> 
> OK.
> 
> What will be the behavior of the predecessor of e.g. the csih function
> csih_create_unprivileged_user if called with USER without HOST prefix,
> machine is inside of domain and the user does not exist:
> - create local windows USER and require the config script to retrieve the
> actual Cygwin HOST+USER name,
> - fail and tell the calling config script to retry with HOST+USER instead
> (if possible),
> - create local windows USER and create a /etc/passwd entry to support a
> non-prefixed Cygwin USER in this case,
> - one of the above, selected by a new option.

I'm not exactly sure yet.  I'm working on it, and I ripped apart the
functions dealing with this problem by handling the cygwin username and
the windows username separately.  But it's not yet finished.  In theory
you have two cases.

Either the account already exists, then the user should (probably
(grain/salt)) specify the Cygwin username, which is either prefixed or
not prefixed, dependent on the DB it will get taken from.  The script
fetches the Windows domain and username from the U-... entry in pw_gecos
then.

Or the account doesn't exist, then the username is just a name.  The
user account will be created in the local SAM and dependent on the state
of the machine, AD member or not, will be prefixed or not as Cygwin
account.

Something like that.

> >>Local scripts from Cygwin users which use "mkpasswd -l" may need to be
> >>changed.
> >They are not supposed to use mkpasswd anymore since they don't need it,
> >only in very special circumstances.
> 
> Wouldn't it be better to let mkpasswd -l simply fail with an explanatory
> error message instead of producing non-backward compatible results? Or at
> least print a warning to stderr?

But there still are cases in which using mkpasswd -l may be used.  If
somebody explicitely chooses to use "passwd: files"-only, then the
mkpasswd tool needs to generate accounts.

Is there any compromise possible which lets mkpasswd generate the
forward compatible accounts by default?  I made the change to mkpasswd
and mkgroup I outlined last week, but I deliberately didn't check it in
because I'm still hoping we find a compromise going forward.  I
understand that in your scenario you will have to use /etc/passwd for a
while longer.

But...  how many scripts would you really have to change if mkpasswd
generates prefixed names?  Alternatively, is setting some environment
variable feasible for tweaking the output of mkpasswd backward
compatible?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpLHMjl2NxYR.pgp
Description: PGP signature

Re: how to embed shell script within a .BAT file

[Andrey Repin]

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 it's own CWD to be UNC 
>> path.
>> You can still start programs by full UNC path from CMD.
>> Though, with correct settings (see above), the point is moot.

> I always thought it odd that MS invents UNC's then fails to support them 
> properly in their own tools.

> Try pushd on a UNC path...

Since migration to Win7, I'm using native symlinks, and pretty happy about it.
I still occasionally hit the UNC path here and there from old shortcuts, but
overall, it's all "local" filesystem. :b


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 10.11.2014, <23:49>

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Achim Gratz]

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 maybe unifying these two AD in the future, but I have
no idea how that would work.

> - Otherwise, if these values are empty or don't exist, your fallback
>   home directory is /home/$USER (without domain prefix).
>
> As you may have noticed, there's nothing in there taking the Windows
> home directory into account.  It's indeed not used at all by the new
> code.

I think that is generally the right idea, since mixing all the .-files
into the normal Windows home directory results in a mess, especially
when there are Windows programs ported from Unix that use the same
scheme for themselves.  What I'm doing right now is to create an
/etc/fstab.d/$USER that mounts a subdirectory of the Windows $HOME
(always a network drive for normal domain users) when I set up a new
users' machine or login on a server.  I also mount the actual Windows
home back under ~/winhome.

> Shall the "db" entries utilize the Windows home folder if it exits(*)
> and drop using the unixHomeDirectory?  It seems inevitable...

That would cause serious problems for me I think.  Keeping the home
directory pinned to /home/$USER and automounting this based on some rule
involving either or both of those entries seems a better idea in the
long run.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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
documentation at
https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-passwdinfo

- If your account is an AD account, the home directory is taken from the
  RFC 2307 entry unixHomeDirectory.

- Otherwise, if these values are empty or don't exist, your fallback
  home directory is /home/$USER (without domain prefix).

As you may have noticed, there's nothing in there taking the Windows
home directory into account.  It's indeed not used at all by the new
code.

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
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 file
  server based home directories, you typically want that these
  directories are used for Cygwin stuff as well (central administration,
  central backup).
  Having to maintain the home directories twice, once in the
  homeDirectory, once in the unixHomeDirectory entry is quite a hassle,
  especially given that unixHomeDirectory does not support variable
  substitution (e.g. "/home/%USERNAME%" won't work).

- If you're already using AD as NIS server, unixHomeDirectory is already
  used for UNIX machines.  Trying to align the unixHomeDirectory for
  Cygwin to homeDirectory for all the rest of Windows will potentially
  become impossible then.

These arguments are quite serious and it questions the "good idea" part
of this change a lot.

What do you think?

Shall the "db" entries utilize the Windows home folder if it exits(*)
and drop using the unixHomeDirectory?  It seems inevitable...


Corinna


(*) This would automatically work for SAM accounts as well because SAM
provides the same Windows home folder entry.


-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpu7vfKeFLuO.pgp
Description: PGP signature

Re: TEST RELEASE: Cygwin 1.7.33-0.8

[Corinna Vinschen]

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 (local) privileged
> > > > username will change.
> > 
> > > Yes.  Is there a way to accommodate that?  Maybe a postinstall script
> > > checking for existing user cron files and renaming them if required?
> > 
> > That's possible but it must be a postinstall than runs when an updated
> > Cygwin is installed (or deinstalled), not when cron is, except if we try to
> > synchronize both.
> 
> A new cron when Cygwin 1.7.33 goes release might be a good idea.
> I have already new OpenSSH and, even more important, base-cygwin
> packages waiting in the backdrop.

I just realized that this is hard, if not impossible to automate.
Consider that an update to Cygwin 1.7.33 leaves /etc/passwd intact
and no /etc/nsswitch.conf file will be installed.  Thus, the default
setting of "passwd: files db" will be used.  Thus, the usernames
won't change.  They *might* change if the administrator of the
system decides to remove /etc/passwd or set "passwd: db" in
/etc/nsswitch.conf, but there's no way to anticipate this move in
a postinstall script.

The easiest thing to do would probbaly be to provide a conversion
script for manual usage.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpcz1dzCoK7C.pgp
Description: PGP signature

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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 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.

If you're doing that at one point...

> > - Otherwise, if these values are empty or don't exist, your fallback
> >   home directory is /home/$USER (without domain prefix).
> >
> > As you may have noticed, there's nothing in there taking the Windows
> > home directory into account.  It's indeed not used at all by the new
> > code.
> 
> I think that is generally the right idea, since mixing all the .-files
> into the normal Windows home directory results in a mess, especially
> when there are Windows programs ported from Unix that use the same
> scheme for themselves.  What I'm doing right now is to create an
> /etc/fstab.d/$USER that mounts a subdirectory of the Windows $HOME
> (always a network drive for normal domain users) when I set up a new
> users' machine or login on a server.  I also mount the actual Windows
> home back under ~/winhome.
> 
> > Shall the "db" entries utilize the Windows home folder if it exits(*)
> > and drop using the unixHomeDirectory?  It seems inevitable...
> 
> That would cause serious problems for me I think.  Keeping the home
> directory pinned to /home/$USER and automounting this based on some rule
> involving either or both of those entries seems a better idea in the
> long run.

...it might give you similar trouble as you outline above.  As soon as
the RFC 2307 posixAccount/posixGroup scheme is utilized for Unix
machines, Cygwin's usage of unixHomeDirectory would potentially break
your modus operandi...


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgp6uPEn0QRVG.pgp
Description: PGP signature

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

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
> 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 file
>   server based home directories, you typically want that these
>   directories are used for Cygwin stuff as well (central administration,
>   central backup).
>   Having to maintain the home directories twice, once in the
>   homeDirectory, once in the unixHomeDirectory entry is quite a hassle,
>   especially given that unixHomeDirectory does not support variable
>   substitution (e.g. "/home/%USERNAME%" won't work).

> - If you're already using AD as NIS server, unixHomeDirectory is already
>   used for UNIX machines.  Trying to align the unixHomeDirectory for
>   Cygwin to homeDirectory for all the rest of Windows will potentially
>   become impossible then.

> These arguments are quite serious and it questions the "good idea" part
> of this change a lot.

> What do you think?

> Shall the "db" entries utilize the Windows home folder if it exits(*)
> and drop using the unixHomeDirectory?  It seems inevitable...

All I can say about this issue is… I told you.
I see literally zero reason to maintain separate, cygwin-specific "home"
directory.
If you want a separate environment to play with, VirtualBox is there to
accommodate your wildest dreams. (Though, Oracle is trying hard to turn people
away from using VB since 4.3.13+)


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 11.11.2014, <03:37>

Sorry for my terrible english...

Re: RFC: 1.7.33 problem with user's home directory

[Jeffrey Altman]

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 personal preference would be for the Cygwin Home directory to be
created under

  %HOMEPATH%\AppData\Roaming\Cygwin

That way the home directory is isolated from native windows applications
that might use the same file names but with different line endings
directly in %HOMEPATH%.

And, the data is within the user profile so that when accessed via
redirection or otherwise, the data is accessible on every machine the
user logs into.

Jeffrey Altman




smime.p7s
Description: S/MIME Cryptographic Signature

Re: RFC: 1.7.33 problem with user's home directory

[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. Windows define home 
directories rarely are shared

--
Andrew DeFaria
http://defaria.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Setup 2.774 texlive postinstall takes 10+ hours

[Yaakov Selkowitz]

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 scripts.  See /var/log/setup.log.full, it contains the dependency
order before starting the scripts.

Years ago we had some trouble to get the base-cygwin script running
first due to a couple of dependency loops.  And we have such loops
again, apparently.  My dependency list on 64 bit (not all packages
installed) now starts like this:

   libbz2_1 _autorebase cygwin zlib0 libpng15 ...

The worst thing AFAICS is that base-cygwin only comes after lots and
lots of other packages for some reason.

This needs some investigation.


There are two issues here:

1) upset was adding a requires: _autorebase to cygwin, which is 
incorrect because it requires dash and rebase, each of which (should) 
require cygwin (resulting in a dependency loop), not to mention that 
cygwin1.dll is never rebased.


2) Several libraries were missing requires: cygwin _autorebase, causing 
them to precede cygwin (and hence base-cygwin) in the dependency chain. 
 I still have yet to understand why for some packages the autodep works 
and for others not.  But by adding those requires to a downloaded 
setup.ini, resulting in the following:


Dependency order of packages: libgcc1 base-cygwin cygwin dash tzcode 
libstdc++6 terminfo sed gzip libpcre1 grep libreadline7 bash 
libncursesw10 info _update-info-dir libgmp10 libiconv2 libintl8 libattr1 
coreutils rebase _autorebase ...


What libgcc1 is doing there first, I still don't know (it does have a 
requires: _autorebase cygwin).


The other thing I realized is that Ports packages are missing these 
autodeps; only by chance (and that many of them depend on other distro 
libraries) do they not seem to interfere with the dependency order.


The question is, can we just make the incver_ifdep code not dependent on 
autodep, then just have cygport add these dependencies to setup.hint and 
drop the apparently fragile autodep code from upset?



Yaakov


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Yaakov Selkowitz]

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 maintain file
   server based home directories, you typically want that these
   directories are used for Cygwin stuff as well (central administration,
   central backup).
   Having to maintain the home directories twice, once in the
   homeDirectory, once in the unixHomeDirectory entry is quite a hassle,
   especially given that unixHomeDirectory does not support variable
   substitution (e.g. "/home/%USERNAME%" won't work).

- If you're already using AD as NIS server, unixHomeDirectory is already
   used for UNIX machines.  Trying to align the unixHomeDirectory for
   Cygwin to homeDirectory for all the rest of Windows will potentially
   become impossible then.

These arguments are quite serious and it questions the "good idea" part
of this change a lot.

What do you think?

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 and one Cygwin, they 
would then potentially cause conflicting/incompatible config dot-files 
in the same directory (line endings, path conventions, etc.).



Yaakov


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Setup 2.774 texlive postinstall takes 10+ hours

[Yaakov Selkowitz]

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, and bash depend on libintl8, which depends 
on libiconv2, and libreadline7 (which is required by bash) itself 
depends on libncursesw10, so that should be at least two places earlier. 
 All of those dependencies are listed in setup.hint (and hence 
setup.ini), so is there something wrong with setup itself?



Yaakov


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Warren Young]

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 and one Cygwin, they would 
> then potentially cause conflicting/incompatible config dot-files in the same 
> directory (line endings, path conventions, etc.).

That’s only true if you make Cygwin $HOME == `cygpath -u %USERPROFILE%`.  If 
you put it somewhere under AppData/…/Cygwin, any non-Cygwin program that stomps 
on that directory isn’t following the platform rules.

Not that I think the risk of this is all that great.  I find that a lot of 
Windows software that comes from the Unix/Linux world already does something 
different with RC files and such.  Common schemes are:

1. Store files under AppData/…/AppName, where they won’t conflict with Cygwin 
$HOME == %USERPROFILE%

2. Name files and directories differently, often without leading dots, 
harkening back to the FAT naming limitations.  Leading underscores are a common 
alternative here.

Care to list some native Win32 ports that *do* put their user files in 
%USERPROFILE%, using the same naming scheme as on Linux/Unix except prefixed 
$HOME?
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Warren Young]

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 installation, but during all use thereafter! — 
comes out of a world where every user is a local Administrator.

This answer I wrote on Stack Overflow is one way to solve the problem today:

http://stackoverflow.com/questions/2180/

It might not be a bad idea if Cygwin started doing this sort of thing by 
default in the future.  (Obviously for new installs only.)
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Warren Young]

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, however:

1. c:\Users\ShortName is directly analogous to /home/shortname on Linux or 
/Users/ShortName on OS X.

2. Recent versions of Windows have given up on the “My” prefix for the main 
directories within your user profile directory which happens to make them match 
the scheme used on Ubuntu, Fedora, OS X, etc.  Finger memory like “cd 
~/Desktop” will serve you better if Cygwin doesn’t bury the user directory 
underneath AppData somewhere.

You can paper over #2 with symlinks, of course, as I already do while using the 
current c:\cygwin\home scheme.  It would just be nice to avoid the need to 
create those symlinks.  Symlinks don’t always behave exactly the same as real 
directories, for one thing.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

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 without creating cygwin-specific /home.

> Windows define home directories rarely are shared

So do Linux...


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 11.11.2014, <09:26>

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.6

[Christian Franke]

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 machine) or
prefixed (domain machine), and always prefixed for a foreign machine.
The -L option can just go away.

I disgree.

Why not keep the old behavior of -l/-L for user names of current machine for
those uses cases which rely on it?

You are always free to change the passwd/group files manually:

   $ mkpasswd -l | sed -e 's/^[^:]*+//' > /etc/passwd

Of course, and it is good that this is still possible. But this would
require that all existing scripts relying on old behavior need to be
changed.

I still don't understand why this backward compatibility break of "mkpasswd
-l" was mandatory.

Most *-config scripts using "mkpasswd -l -u USER" may need to be changed.

Definitely.  The change is inevitable since most scripts using mkpasswd
or mkgroup do so to create entries in /etc/passwd and /etc/group.  But
this doesn't make sense anymore, or if so, only marginally so.

OK.

What will be the behavior of the predecessor of e.g. the csih function
csih_create_unprivileged_user if called with USER without HOST prefix,
machine is inside of domain and the user does not exist:
- create local windows USER and require the config script to retrieve the
actual Cygwin HOST+USER name,
- fail and tell the calling config script to retry with HOST+USER instead
(if possible),
- create local windows USER and create a /etc/passwd entry to support a
non-prefixed Cygwin USER in this case,
- one of the above, selected by a new option.

I'm not exactly sure yet.  I'm working on it, and I ripped apart the
functions dealing with this problem by handling the cygwin username and
the windows username separately.  But it's not yet finished.  In theory
you have two cases.

Either the account already exists, then the user should (probably
(grain/salt)) specify the Cygwin username, which is either prefixed or
not prefixed, dependent on the DB it will get taken from.  The script
fetches the Windows domain and username from the U-... entry in pw_gecos
then.

Or the account doesn't exist, then the username is just a name.  The
user account will be created in the local SAM and dependent on the state
of the machine, AD member or not, will be prefixed or not as Cygwin
account.

Something like that.


Possibly a two step process:

csih_check_unprivileged_user --allow-prefix $USER

if [ "$csih_unpriv_cygwin_username" != "$USER ]; then
  # Cygwin username has prefix
    inform user, patch configuration file, ...
fu

csih_create_unprivileged_user [ $PASSWORD ]





Local scripts from Cygwin users which use "mkpasswd -l" may need to be
changed.

They are not supposed to use mkpasswd anymore since they don't need it,
only in very special circumstances.

Wouldn't it be better to let mkpasswd -l simply fail with an explanatory
error message instead of producing non-backward compatible results? Or at
least print a warning to stderr?

But there still are cases in which using mkpasswd -l may be used.  If
somebody explicitely chooses to use "passwd: files"-only, then the
mkpasswd tool needs to generate accounts.

Is there any compromise possible which lets mkpasswd generate the
forward compatible accounts by default?  I made the change to mkpasswd
and mkgroup I outlined last week, but I deliberately didn't check it in
because I'm still hoping we find a compromise going forward.  I
understand that in your scenario you will have to use /etc/passwd for a
while longer.

But...  how many scripts would you really have to change if mkpasswd
generates prefixed names?


We could add 'sed' to /etc/passwd generating script, no problem.

The actual test scripts & tools from this use case pass local usernames 
from/to non-Cygwin programs and rely on the fact that Cygwin and Windows 
username match.


For the long term, have some cyguser, cyggroup tools (similar to 
cygpath) which convert the names would be helpful.




   Alternatively, is setting some environment
variable feasible for tweaking the output of mkpasswd backward
compatible?


Of course, yes.

Or mkpasswd -l behavior depends on nsswitch.conf setting:

passwd only: Old behavior
passwd, db: New behavior, print warning
db only: fail

Christian


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

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 file
>>server based home directories, you typically want that these
>>directories are used for Cygwin stuff as well (central administration,
>>central backup).
>>Having to maintain the home directories twice, once in the
>>homeDirectory, once in the unixHomeDirectory entry is quite a hassle,
>>especially given that unixHomeDirectory does not support variable
>>substitution (e.g. "/home/%USERNAME%" won't work).
>>
>> - If you're already using AD as NIS server, unixHomeDirectory is already
>>used for UNIX machines.  Trying to align the unixHomeDirectory for
>>Cygwin to homeDirectory for all the rest of Windows will potentially
>>become impossible then.
>>
>> These arguments are quite serious and it questions the "good idea" part
>> of this change a lot.
>>
>> What do you think?
>>
>> 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 and one Cygwin, they 
> would then potentially cause conflicting/incompatible config dot-files 
> in the same directory (line endings, path conventions, etc.).

I would imagine using one or another. But not both. Native version of the same
program usually runs better, than the one running through compatibility layer.
Then again, many programs, that have native Windows version, use native
Windows conventions (I.e. put things in %AppData% rather than clogging
%USERPROFILE% with dot-dirs.)
Out of my list of programs, only GIMP and Dia would share the config dirs, if
I would try to set up Cygwin versions of either along with native one.
And all this worth nothing, because if someone's doing something like that,
they are either know what they are doing, and prepared for the possible
outcome, or deserve everything that could happen. IMO.
Not to mention, we're discussing default configuration here. You can alter it
easily to fit your needs, Cygwin gives you all that you need to achieve it.

In short, elusive benefits of having a separate cygwin-specific "clean" homes
versus confusing disjoint of multiple places to look for single user's files,
settings, and other stuff when it comes to backups and migrating profiles.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 11.11.2014, <09:28>

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Achim Gratz]

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.
> 
> If you're doing that at one point...
> ...it might give you similar trouble as you outline above.  As soon as
> the RFC 2307 posixAccount/posixGroup scheme is utilized for Unix
> machines, Cygwin's usage of unixHomeDirectory would potentially break
> your modus operandi...

Right, that's why I think that Cygwin should always have the users home in
/home/$USER and mount that based on some rule that the administrator can
specify.


Regards,
Achim


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple