X crashes with SIGPIPE

[Henry Gebhardt via Cygwin]

Hi,

Cygwin/X crashes every few days for me. I managed to obtain a backtrace
from the last crash (attached). Server log is also included.

I have not, yet, managed to pin down the exact trigger for the crash. I
am running two graphical programs under Windows 10 WSL2 Debian: tilix
and evince.

Thank you for any help.

Best,
Henry
$ gdb --pid=`pidof /usr/bin/XWin`
GNU gdb (GDB) (Cygwin 8.2.1-1) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 2952
[New Thread 2952.0x1144]
[New Thread 2952.0x2178]
[New Thread 2952.0x22c4]
[New Thread 2952.0x95c]
[New Thread 2952.0x3958]
[New Thread 2952.0x3e88]
[New Thread 2952.0x3cdc]
[New Thread 2952.0x474]
[New Thread 2952.0x35e0]
[New Thread 2952.0x4398]
[New Thread 2952.0x2f04]
[New Thread 2952.0x40c0]
[New Thread 2952.0x3d9c]
[New Thread 2952.0x2d10]
[New Thread 2952.0xb40]
[New Thread 2952.0x138]
[New Thread 2952.0x2f38]
[New Thread 2952.0x261c]
[New Thread 2952.0x3f98]
[New Thread 2952.0xcc0]
[New Thread 2952.0x3ee0]
[New Thread 2952.0x3c08]
[New Thread 2952.0x1670]
[New Thread 2952.0x2b7c]
[New Thread 2952.0x2bf0]
[New Thread 2952.0xbc8]
[New Thread 2952.0x128c]
Reading symbols from /usr/bin/XWin.exe...Reading symbols from 
/usr/lib/debug//usr/bin/XWin.exe.dbg...done.
done.
(gdb) c
Continuing.
[Thread 2952.0x128c exited with code 0]
[New Thread 2952.0x2530]
[New Thread 2952.0x3cd4]
[Thread 2952.0x2530 exited with code 0]
[Thread 2952.0x3cd4 exited with code 0]
[New Thread 2952.0x30b4]
[New Thread 2952.0x30a0]

Thread 1 received signal SIGPIPE, Broken pipe.
[Switching to Thread 2952.0x1144]
0x00010053f250 in _XSERVTransSocketWritev (ciptr=0xbb18,
buf=0xbc10, size=-17396) at /usr/include/X11/Xtrans/Xtranssock.c:2382
2382/usr/include/X11/Xtrans/Xtranssock.c: No such file or directory.
(gdb) bt full
#0  0x00010053f250 in _XSERVTransSocketWritev (ciptr=0xbb18,
buf=0xbc10, size=-17396) at /usr/include/X11/Xtrans/Xtranssock.c:2382
No locals.
#1  0x in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.20.5.0
OS: CYGWIN_NT-10.0-18362 MT-210810 3.1.4-340.x86_64 2020-02-19 08:49 UTC x86_64
OS: Windows 10  [Windows NT 10.0 build 18362] (Win64)
Package: version 1.20.5-3 built 2019-09-06

XWin was started with the following command line:

/usr/bin/XWin :0 -multiwindow -listen tcp -nowgl -auth 
 /home/gebhardt/.serverauth.1895 

ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 1920 h 1080
winInitializeScreenDefaults - native DPI x 120 y 120
[ 78029.546] (II) xorg.conf is not supported
[ 78029.546] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information
[ 78029.546] LoadPreferences: /home/gebhardt/.XWinrc not found
[ 78029.546] LoadPreferences: Loading /etc/X11/system.XWinrc
[ 78029.546] LoadPreferences: Done parsing the configuration file...
[ 78029.546] winDetectSupportedEngines - RemoteSession: no
[ 78029.562] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL
[ 78029.562] winDetectSupportedEngines - Returning, supported engines 0005
[ 78029.562] winSetEngine - Multi Window or Rootless => ShadowGDI
[ 78029.562] winScreenInit - Using Windows display depth of 32 bits per pixel
[ 78029.578] winAllocateFBShadowGDI - Creating DIB with width: 1920 height: 1080 depth: 32
[ 78029.578] winFinishScreenInitFB - Masks: 00ff ff00 00ff
[ 78029.578] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32
[ 78029.578] MIT-SHM extension disabled due to lack of kernel support
[ 78029.578] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel
[ 78029.921] (II) IGLX: Loaded and initialized swrast
[ 78029.921] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[ 78030.109] winPointerWarpCursor - Discarding first warp: 960 540
[ 78030.109] (--) 3 mouse buttons found
[ 78030.109] (--) Setting autorepeat to delay=500, rate=31
[ 78030.109] (--) Windows keyboard layout: "0409" (0409) "US", type 4
[ 78030.109] (--) Found matching XKB configuration "English (USA)"
[ 78030.109] (--) Model = "pc105" Layout = "us" Variant = "none" Options = "none"
[ 78030.109] Rules = 

Re: What is wrong with the name excel?

[Greywolf]

On 4/17/2020 11:01, Eliot Moss wrote:
> On 4/17/2020 1:24 PM, Erik Soderquist via Cygwin wrote:
> What seems a little odd to me is this.  If I had invoked via:
> 
>     excel.exe
> 
> I would not be surprised the MS Excel would launch, because it is probably
> earlier in the path.  But the OP said he typed:
> 
>     ./excel.exe
> 
> So I am surprised, given the explicit path.  Which leads me to a background
> wondering of whether ./excel.exe has execute permission set.  If not maybe
> the search would continue, trying to find something on the path that could
> be executed?  That would surprise me a little, but I'd have to go read the
> fine print on bash, etc.

If it didn't find it in the path at all, one expects (in a reasonable
environment) that the complaint "Command not found" would issue.

> 
> Regards - Eliot Moss
> -- 
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:    https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

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

Re: cygwin gfortran segfaulting on valid write statements

[Brian Inglis]

On 2020-04-17 17:33, Charles Russell wrote:
> On 4/17/2020 2:46 PM, Brian Inglis wrote:
> 
>> Try running under strace:
>>
>> $ strace -o prog.strace prog -options... args...
>>
>> or gdb:
>>
>> $ gdb prog
>> (gdb) run -options... args...
>> SEGV diagnostics
>> (gdb) bt
>> (gdb) q
>>
>> and attach or paste all output.
> 
> The following is the case where I got an error message. Not actually a 
> segfault.
> (Sorry, I'm not a programmer.) The executable, gdb, and strace all produce the
> same output:
> ---
> At line 889 of file cgcrez.f (unit = 6, file = 'stdout')
> Fortran runtime error: Missing initial left parenthesis in format
> ^

> Here is the indicated line, using list mode in vim to show that there are no
> unexpected nonprinting characters:
> 
>  887   write(6,'(i6,1p3e9.2,x,e9.2,x,0pf6.3,x,1p2e10.2,''@'')')$
>  888  &   iter, reldf,reldb,$
>  889  &   gnorms, x1min, -cosag, beta(1),beta(np)$
>  890 $
> 
> This code compiled and ran on cygwin in the past, and checks out now in debian
> stable.
> 
> In my other case, which I may or may not be able to find again, the program
> failed with no explicit error message like the one above. Stepping through 
> with
> gdb showed that it was also crashing in a valid write statement.

Do you perhaps need an extra pair of parentheses to repeat the formatted output,
perhaps from the second specifier, as you have 5 variable format specifiers and
8 variables?
Showing a bit more context with all variable declarations would help, and you
can use cat -A (== -vET) to show non-printing characters e.g.

$ egrep -nw 'iter|reldf|reldb|gnorms|x1min|cosag|beta|write' cgcrez.f | cat -A

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: What is wrong with the name excel?

[Andrey Repin]

Greetings, Gerlach van Beinum!

> I made a program to read a csv file from Excel. I called it excel.c
> and it made an executable excel.exe
> If irun that executable with:
> ./excel.exe
> nothing happens, i.i. no output.

> If I rename it to a.exe it runs OK.

> What about this name excel??

> My Cygwin version is up-to-date.

Unable to repro'd.
Win7 and Win10 1909.


-- 
With best regards,
Andrey Repin
Saturday, April 18, 2020 3:01:28

Sorry for my terrible english...

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

Re: cygwin gfortran segfaulting on valid write statements

[Charles Russell]

On 4/17/2020 2:46 PM, Brian Inglis wrote:


Try running under strace:

$ strace -o prog.strace prog -options... args...

or gdb:

$ gdb prog
(gdb) run -options... args...
SEGV diagnostics
(gdb) bt
(gdb) q

and attach or paste all output.


The following is the case where I got an error message. Not actually a 
segfault. (Sorry, I'm not a programmer.) The executable, gdb, and strace 
all produce the same output:

---
At line 889 of file cgcrez.f (unit = 6, file = 'stdout')
Fortran runtime error: Missing initial left parenthesis in format

^

Error termination. Backtrace:
#0  0x in ???
#1  0x in ???
#2  0x in ???
#3  0x in ???
#4  0x in ???
#5  0x in ???
#6  0x in ???
#7  0x in ???
#8  0x in ???
#9  0x in ???
#10  0x in ???
#11  0x in ???
#12  0x in ???
#13  0x in ???
--
Here is the indicated line, using list mode in vim to show that there 
are no unexpected nonprinting characters:


 887   write(6,'(i6,1p3e9.2,x,e9.2,x,0pf6.3,x,1p2e10.2,''@'')')$
 888  &   iter, reldf,reldb,$
 889  &   gnorms, x1min, -cosag, beta(1),beta(np)$
 890 $

This code compiled and ran on cygwin in the past, and checks out now in 
debian stable.


In my other case, which I may or may not be able to find again, the 
program failed with no explicit error message like the one above. 
Stepping through with gdb showed that it was also crashing in a valid 
write statement.





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

Re: cygwin gfortran segfaulting on valid write statements

[Charles Russell]

On 4/17/2020 2:39 PM, Marco Atzeri via Cygwin wrote:


in what type of statement have you the segfault ?



I recently tried building and running some old fortran code using what I 
think is the current version of cygwin gfortran (--version reports 
9.3.0) and was surprised to get a run-time error message saying that a 
format statement was missing a left parenthesis. There was no format 
error in that line (the same code ran previously on cygwin, and runs now 
on debian stable). Furthermore I would not expect to see a syntax error 
message at run time. I got around the problem by switching from cygwin 
to a debian virtual machine, but then went back for another look at 
cygwin, using different (old, tested) code. Again I hit a segfault, this 
time with no explicit message, but stepping through gdb tracked the 
error to a write statement. Copying the offending write statement into a 
simple example failed to reproduce the error.

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

Re: katomic and atomix will not run

[Eliot Moss]

On 4/17/2020 5:16 PM, Phoenix Soul via Cygwin wrote:

I decided that I was going to get katomic and atomix for cygwin, and
selected the most recent version listed.
atomix refuses to run and says:
Unable to init server: Could not connect to 127.0.0.1: Connection refused

(atomix:1495): Gtk-WARNING **: cannot open display:
katomic says:
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to
'/tmp/runtime-warri_000'
qt.qpa.screen: QXcbConnection: Could not connect to display
Could not connect to any X display.
I have already tried using source as well. I have already pinged 127.0.0.1
(localhost) to ensure that it does exist. What must be done to fix it.
Windows version is 8.1, and this is a no admin installation.


... and you have an X server already running?  Maybe some details
about that end of things will help folks help you ...

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

katomic and atomix will not run

[Phoenix Soul via Cygwin]

I decided that I was going to get katomic and atomix for cygwin, and
selected the most recent version listed.
atomix refuses to run and says:
Unable to init server: Could not connect to 127.0.0.1: Connection refused

(atomix:1495): Gtk-WARNING **: cannot open display:
katomic says:
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to
'/tmp/runtime-warri_000'
qt.qpa.screen: QXcbConnection: Could not connect to display
Could not connect to any X display.
I have already tried using source as well. I have already pinged 127.0.0.1
(localhost) to ensure that it does exist. What must be done to fix it.
Windows version is 8.1, and this is a no admin installation.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: cygwin gfortran segfaulting on valid write statements

[Brian Inglis]

On 2020-04-17 12:42, wors...@bellsouth.net wrote:
> I'm getting segfaults in valid write statements Using current cygwin gfortran
> (--version reports 9.3.0). This is with old code that runs on current debian
> stable and was running on cygwin a few years ago. I have been unable to
> construct a simple example for a bug report.

Try running under strace:

$ strace -o prog.strace prog -options... args...

or gdb:

$ gdb prog
(gdb) run -options... args...
SEGV diagnostics
(gdb) bt
(gdb) q

and attach or paste all output.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: cygwin gfortran segfaulting on valid write statements

[Brian Inglis]

On 2020-04-17 12:42, wors...@bellsouth.net wrote:
> I'm getting segfaults in valid write statements Using current cygwin gfortran
> (--version reports 9.3.0). This is with old code that runs on current debian
> stable and was running on cygwin a few years ago. I have been unable to
> construct a simple example for a bug report.
> 
> I would like to try downgrading the gfortran version, but see 6 different
> versions of gcc-fortran and 11 versions of libgfortran in the cygwin 
> repository.
> Can someone recommend a combination?

Try these in order from recent to less:

gcc-fortran 9.3.0-1 9.2.0-3 9.2.0-2 9.2.0-1 8.3.0-1 7.4.0-1
libgfortran59.3.0-1 9.2.0-3 9.2.0-2 9.2.0-1 8.3.0-1
libgfortran47.4.0-1

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: cygwin gfortran segfaulting on valid write statements

[Marco Atzeri via Cygwin]

Am 17.04.2020 um 20:42 schrieb wors...@bellsouth.net:
I'm getting segfaults in valid write statements Using current cygwin 
gfortran (--version reports 9.3.0). This is with old code that runs on 
current debian stable and was running on cygwin a few years ago. I have 
been unable to construct a simple example for a bug report.


I would like to try downgrading the gfortran version, but see 6 
different versions of gcc-fortran and 11 versions of libgfortran in the 
cygwin repository. Can someone recommend a combination?





9.3.0-1   libgfortran5
9.2.0-3   libgfortran5
9.2.0-2   libgfortran5
9.2.0-1   libgfortran5
8.3.0-1   libgfortran5
7.4.0-1   libgfortran4


in what type of statement have you the segfault ?

Regards
Marco


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

Re: What is best means of occasional communication with this mailing list now that gmane is gone?

[worsafe]

On 4/17/2020 1:46 PM, wors...@bellsouth.net wrote:
What is best means of occasional communication with this mailing list 
now that gmane is gone?




Sorry, not a problem.
"the gmane.org domain was no longer viable, and the NNTP server has now 
moved to news.gmane.io"

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

What is best means of occasional communication with this mailing list now that gmane is gone?

[worsafe]

What is best means of occasional communication with this mailing list 
now that gmane is gone?


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

Re: Two naive questions

[Brian Inglis]

On 2020-04-17 12:16, Andrey Repin wrote:
> Greetings, Stephen Carrier!
>> I remember having had the same confusion the first few times I initiated
>> threads.

> When you start a new thread, do not reply to existing threads.
> It's that simple.

Indeed - proper mail and news readers use References not Subject headers for
threading when available, so your new topic will be lost under an old thread.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

cygwin gfortran segfaulting on valid write statements

[worsafe]

I'm getting segfaults in valid write statements Using current cygwin 
gfortran (--version reports 9.3.0). This is with old code that runs on 
current debian stable and was running on cygwin a few years ago. I have 
been unable to construct a simple example for a bug report.


I would like to try downgrading the gfortran version, but see 6 
different versions of gcc-fortran and 11 versions of libgfortran in the 
cygwin repository. Can someone recommend a combination?


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

Re: What is wrong with the name excel?

[Eliot Moss]

Something that does work is to define a bash function name excel.  Within that
you could invoke an executable called myexcel, etc.  An alias probably works,
too.  Not sure about a symlink (and they come in different flavors).  But
these just paper over that weird special-ness.  Windows is odd ...

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

Re: Two naive questions

[Andrey Repin]

Greetings, Stephen Carrier!

> I remember having had the same confusion the first few times I initiated
> threads.

When you start a new thread, do not reply to existing threads.
It's that simple.


-- 
With best regards,
Andrey Repin
Friday, April 17, 2020 21:15:44

Sorry for my terrible english...

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

Re: git on mounted CIFS is it Git or Cygwin

[Andrey Repin]

Greetings, L A Walsh!

> Here it is -- feel free to pass it along:
> ---
> lsacl
> ---
>>  cat ~/bin/lsacl
> #!/bin/bash

> ## $Id: lsacl,v 1.5 2015-08-02 10:29:25-07 law Exp $
> # Version 2 -- try to work with getfacl on cygwin
> #


> shopt -s expand_aliases
> alias int=declare\ -i   sub=function  string=declare

Stopped reading st this line. And immediate "no" to anything containing this
level of trickery.


-- 
With best regards,
Andrey Repin
Friday, April 17, 2020 21:14:07

Sorry for my terrible english...

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

Re: What is wrong with the name excel?

[Tony Richardson via Cygwin]

On Fri, Apr 17, 2020 at 1:02 PM Eliot Moss  wrote:

> On 4/17/2020 1:24 PM, Erik Soderquist via Cygwin wrote:
> > On Fri, Apr 17, 2020 at 7:11 AM Gerlach van Beinum wrote:
> >>
> >> I made a program to read a csv file from Excel. I called it excel.c
> >> and it made an executable excel.exe
> >> If irun that executable with:
> >> ./excel.exe
> >> nothing happens, i.i. no output.
> >>
> >> If I rename it to a.exe it runs OK.
> >>
> >> What about this name excel??
> >
> > I believe this is actually a Windows issue; Windows recognizes
> > "excel.exe" as 'a Microsoft package' and intercepts the call to launch
> > the program, though I would expect Microsoft Excel to launch rather
> > than 'nothing happening'
> >
> > I've had this problem before on hosts that did not even have Cygwin
> > installed when the executable file name matched an existing 'Microsoft
> > package'
>
> What seems a little odd to me is this.  If I had invoked via:
>
>  excel.exe
>
> I would not be surprised the MS Excel would launch, because it is probably
> earlier in the path.  But the OP said he typed:
>
>  ./excel.exe
>
> So I am surprised, given the explicit path.  Which leads me to a background
> wondering of whether ./excel.exe has execute permission set.  If not maybe
> the search would continue, trying to find something on the path that could
> be executed?  That would surprise me a little, but I'd have to go read the
> fine print on bash, etc.
>
> Regards - Eliot Moss
>

I am surprised but, I see the same behavior.   No output from an executable
called excel.exe.  winword.exe appears to be another "special" name.

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

Re: What is wrong with the name excel?

[Eliot Moss]

On 4/17/2020 1:24 PM, Erik Soderquist via Cygwin wrote:

On Fri, Apr 17, 2020 at 7:11 AM Gerlach van Beinum wrote:


I made a program to read a csv file from Excel. I called it excel.c
and it made an executable excel.exe
If irun that executable with:
./excel.exe
nothing happens, i.i. no output.

If I rename it to a.exe it runs OK.

What about this name excel??


I believe this is actually a Windows issue; Windows recognizes
"excel.exe" as 'a Microsoft package' and intercepts the call to launch
the program, though I would expect Microsoft Excel to launch rather
than 'nothing happening'

I've had this problem before on hosts that did not even have Cygwin
installed when the executable file name matched an existing 'Microsoft
package'


What seems a little odd to me is this.  If I had invoked via:

excel.exe

I would not be surprised the MS Excel would launch, because it is probably
earlier in the path.  But the OP said he typed:

./excel.exe

So I am surprised, given the explicit path.  Which leads me to a background
wondering of whether ./excel.exe has execute permission set.  If not maybe
the search would continue, trying to find something on the path that could
be executed?  That would surprise me a little, but I'd have to go read the
fine print on bash, etc.

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

Re: Two naive questions

[Stephen Carrier]

On Fri, Apr 17, 2020 at 07:10:51AM +0200, Marco Atzeri via Cygwin wrote:
> Am 16.04.2020 um 22:21 schrieb Fergus Daly via Cygwin:
> > I've been reading/writing to this list since 2001 or maybe earlier and have 
> > only just Subscribe'd. Mainly because I have been aware when contributing 
> > to a thread I have always broken it by not using Follow-up properly, just 
> > artificially including the title prefix Re: in what is essentially a new 
> > post. Having Subscribe'd, I'm no clearer how to do this properly.
> > 1. Please can somebody point me to an instruction?
> 
> usually it is just reply to the list on your mail program.

And edit the subject line as well.  There is a mail header "In-Reply-To"
that should be blanked as well to avoid misleading any mechanism that
makes use of it.

I remember having had the same confusion the first few times I initiated
threads.

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

Re: What is wrong with the name excel?

[Csaba Ráduly via Cygwin]

Hi Gerlach,

On 17/04/2020 13:10, Gerlach van Beinum via Cygwin wrote:

I made a program to read a csv file from Excel. I called it excel.c
and it made an executable excel.exe
If irun that executable with:
./excel.exe
nothing happens, i.i. no output.


Try running it under gdb. You should get a better description than "no output".



If I rename it to a.exe it runs OK.

What about this name excel??


It's used by a fairly popular application published by a legacy software vendor 
headquartered in Redmond, Washington.




My Cygwin version is up-to-date.



I believe it when I see it (the output of cygcheck -s -r -v, attached to the 
email).

Csaba
--
You can get very substantial performance improvements
by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler
So if you're looking for a completely portable, 100% standards-conformat way
to get the wrong information: this is what you want. - Scott Meyers (C++TDaWYK)
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Two naive questions

[Brian Inglis]

On 2020-04-17 05:17, Fergus Daly via Cygwin wrote:
>>> usually it is just reply to the list on your mail program.
> Yeah, I now see how it all works. Thank you.

When Reply List doesn't work, pick Reply All and trim the To and Reply To
addresses to just the list address, and maybe a CC to what may be a
non-subscriber if you don't recognize them.

>>> Cygwin is a guest on it, we are not the maintainers.
> Understood. Thank you.

> On 17 April 2020 06:11, Marco Atzeri wrote:
> Am 16.04.2020 um 22:21 schrieb Fergus Daly via Cygwin:
>> I've been reading/writing to this list since 2001 or maybe earlier and
>> have only just Subscribe'd. Mainly because I have been aware when 
>> contributing to a thread I have always broken it by not using Follow-up 
>> properly, just artificially including the title prefix Re: in what is
>> essentially a new post.
>> Having Subscribe'd, I'm no clearer how to do this properly.
>> 1. Please can somebody point me to an instruction?
> usually it is just reply to the list on your mail program.
>> 2. Since when the new look provided by
>> https://cygwin.com/pipermail/cygwin/ ?
> new server for sourceware.org with new software in March
> https://sourceware.org/sourceware-wiki/MigrationStatus/
> Cygwin is a guest on it, we are not the maintainers.
>> Is there a way to default to the "legacy" look provided at, say,
>> https://sourceware.org/legacy-ml/cygwin/2019-04/
>> but not obviously available today (even by changing 2019 to 2020 in the
>> line above)?
>> (I've looked for what I had assumed would be a long conversation on this 
>> change, but cannot find anything.)

Infrastructure issues are dealt with on:

https://sourceware.org/mailman/listinfo/overseers

and the move/migration was dealt with under:

https://sourceware.org/pipermail/overseers/2020q1/thread.html
(#start and #end anchors go to oldest and newest posts)

starting:

https://sourceware.org/pipermail/overseers/2020q1/016620.html

You can find mentions of overseers in some sourceware pages.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: What is wrong with the name excel?

[Erik Soderquist via Cygwin]

On Fri, Apr 17, 2020 at 7:11 AM Gerlach van Beinum wrote:
>
> I made a program to read a csv file from Excel. I called it excel.c
> and it made an executable excel.exe
> If irun that executable with:
> ./excel.exe
> nothing happens, i.i. no output.
>
> If I rename it to a.exe it runs OK.
>
> What about this name excel??

I believe this is actually a Windows issue; Windows recognizes
"excel.exe" as 'a Microsoft package' and intercepts the call to launch
the program, though I would expect Microsoft Excel to launch rather
than 'nothing happening'

I've had this problem before on hosts that did not even have Cygwin
installed when the executable file name matched an existing 'Microsoft
package'

-- Erik
--
"I do not think any of us are truly sane, Caleb. Not even you. Courage
is not sanity. Being willing to die for someone else is not sanity."
... "Love is not sane, nor is faith." ... "If sanity lacks those
things, Caleb, I want no part of it."

-- Alexandria Terri in "Weaving the Wyvern" by Alexis Desiree Thorne
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH 2/2] cygheap_pwdgrp: Don't keep old schemes when parsing nsswitch.conf

[Corinna Vinschen]

On Apr 17 11:31, David Macek via Cygwin-patches wrote:
> The implicit assumption seemed to be that any subsequent occurence of
> the same setting in nsswitch.conf is supposed to rewrite the previous
> ones completely.  This was not the case if the third or any further
> schema was previously defined and the last line defined less than that
> (but at least 2), for example:
> 
> ```
> db_home: windows cygwin /myhome/%U
> db_home: cygwin desc
> ```
> 
> Let's document this behavior as well.
> ---
>  winsup/cygwin/uinfo.cc | 5 +++--
>  winsup/doc/ntsec.xml   | 5 +
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
> index 227faa4248..a4fcc33d8d 100644
> --- a/winsup/cygwin/uinfo.cc
> +++ b/winsup/cygwin/uinfo.cc
> @@ -793,9 +793,10 @@ cygheap_pwdgrp::nss_init_line (const char *line)
>   scheme = gecos_scheme;
> if (scheme)
>   {
> -   uint16_t idx = 0;
> +   for (uint16_t idx = 0; idx < NSS_SCHEME_MAX; ++idx)
> + scheme[idx].method = NSS_SCHEME_FALLBACK;
>  
> -   scheme[0].method = scheme[1].method = NSS_SCHEME_FALLBACK;
> +   uint16_t idx = 0;

Hmmm.  This `idx' usage is a bit puzzeling.  Here's a counter-proposal:

diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
index 57d90189d390..9521a973803e 100644
--- a/winsup/cygwin/uinfo.cc
+++ b/winsup/cygwin/uinfo.cc
@@ -793,12 +793,12 @@ cygheap_pwdgrp::nss_init_line (const char *line)
scheme = gecos_scheme;
  if (scheme)
{
- uint16_t idx = 0;
+ for (uint16_t idx = 0; idx < NSS_SCHEME_MAX; ++idx)
+   scheme[idx].method = NSS_SCHEME_FALLBACK;
 
- scheme[0].method = scheme[1].method = NSS_SCHEME_FALLBACK;
  c = strchr (c, ':') + 1;
  c += strspn (c, " \t");
- while (*c && idx < NSS_SCHEME_MAX)
+ for (uint16_t idx = 0; *c && idx < NSS_SCHEME_MAX; ++idx)
{
  if (NSS_CMP ("windows"))
scheme[idx].method = NSS_SCHEME_WINDOWS;
@@ -829,7 +829,6 @@ cygheap_pwdgrp::nss_init_line (const char *line)
}
  c += strcspn (c, " \t");
  c += strspn (c, " \t");
- ++idx;
}
  /* If nothing has been set, revert to default. */
  if (scheme[0].method == NSS_SCHEME_FALLBACK)

If that's ok with you I check it in as your patch.

Can you please send the 2-clause BSD waiver per
https://cygwin.com/contrib.html to this list, too?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: [PATCH 1/2] cygheap_pwdgrp: Don't invent undocumented defaults in nsswitch.conf

[Corinna Vinschen]

On Apr 17 11:30, David Macek via Cygwin-patches wrote:
> ---
>  winsup/cygwin/uinfo.cc | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
> index 57d90189d3..227faa4248 100644
> --- a/winsup/cygwin/uinfo.cc
> +++ b/winsup/cygwin/uinfo.cc
> @@ -831,12 +831,6 @@ cygheap_pwdgrp::nss_init_line (const char *line)
> c += strspn (c, " \t");
> ++idx;
>   }
> -   /* If nothing has been set, revert to default. */
> -   if (scheme[0].method == NSS_SCHEME_FALLBACK)
> - {
> -   scheme[0].method = NSS_SCHEME_CYGWIN;
> -   scheme[1].method = NSS_SCHEME_DESC;
> - }
>   }
>   }
>break;
> -- 
> 2.26.1.windows.1

The defaults are not undocumented, see at least the source, uinfo.cc
line 629ff.  If I screwed that up somehow, the right patch is to make
sure the defaults are set right in cygheap_pwdgrp::init, rather than
removing the defaults altogether.  If it's really important, we can also
add the exact default settings to the docs.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: setup-x86_64.exe --quiet-mode issues using Management Tools

[Bill Stewart]

On Fri, Apr 17, 2020 at 1:01 AM KAVALAGIOS Panagiotis (EEAS-EXT)  wrote:

> This is the way that we are pushing the packages currently to
> end users is through software managers with silent
> installation.

My point is that "silent" doesn't mean "no visible GUI." It generally
means "the installer doesn't block" (i.e., the installation completes
without user input).

For example, the popular Inno Setup install builder
(https://www.jrsoftware.org/isinfo.php) has a "/SILENT" command line
parameter, which (if the installer is designed correctly) causes the
created installer to install the package without user input. If run in
the user's session, a GUI is still visible; it just doesn't stop to
ask for any input. If you install using a software management tool,
this usually installs in a separate session, so it doesn't matter if
there's a GUI as long as no input is required.

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

Re: Rsync frequently hangs

[Brent Epp]

Hi Andrey,

Thanks, I do have some security software running, but the rsync problem 
persists when it (the security software) is disabled.


Thanks
 - Brent

Can you expand on this?
On 2020-04-17 05:07, Andrey Repin wrote:

Greetings, Brent Epp!


I have a large collection of custom tooling that depends on rsync.  It
used to work very well, but recently, rsync has become highly unstable.
It frequently (dozens of times a day) hangs.  These are rsync executions
where the source and target are both on the same local drive.
Eventually once it times out, it reports:
      rsync: connection unexpectedly closed (0 bytes received so far)
[sender]
      rsync error: error in rsync protocol data stream (code 12) at
io.c(226) [sender=3.1.2]
No changes have recently been made to the tooling.  I just upgraded
cygwin as well, the problem persists.
I'm going to do a clean install of cygwin, but if that doesn't solve
things, what else can I do?

Check for BLODA. Although I'm still suspicious.
All I've seen so far is

rsync error: protocol incompatibility (code 2) at receiver.c(582) 
[receiver=3.1.0]
rsync error: protocol incompatibility (code 2) at io.c(1642) [generator=3.1.0]

this is a link to production VPS. It consistently hangs midway the transfer.
Like it has a clairvoyance, no matter if the upload is 1 file of 100 files,
halfway through it drops, and I have to restart the upload, then it goes to
complete success.




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

Sv: unlink does not remove named pipe

[Kristian Ivarsson via Cygwin]

> Greetings, Kristian Ivarsson via Cygwin!
> 
> > If you're creating a lot's of named pipes in main process and in
> > children and then using unlink, some of the named pipe files are not
> > removed from the file system and no error is issued, i.e. unlink
> > doesn't return -1
> 
> Open file will not be immediately removed on Windows.
> However, if the file was deleted successfully, consequent attempts at
> opening it will fail.


I guess you're right Andrey and it was just merely a delay in Windows,
because the link/file-counter seem to be 0 and it was just an observable
defect but not an practical defect (once I tested it in other ways, i.e.
fopen etc didn't act as it existed)


I'll come back if I encounter any practical/programatic problems with it

I'm sorry for not testing it properly before I did this "report"


Kristian


> --
> With best regards,
> Andrey Repin
> Friday, April 17, 2020 14:08:48
> 
> Sorry for my terrible english...


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

Re: unlink does not remove named pipe

[Ken Brown via Cygwin]

Hi Kristian,

On 4/17/2020 4:26 AM, Kristian Ivarsson via Cygwin wrote:

If you're creating a lot's of named pipes in main process and in children
and then using unlink, some of the named pipe files are not removed from the
file system and no error is issued, i.e. unlink doesn't return -1


Thanks for the report.  As usual, a test case would be helpful.

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

Re: unlink does not remove named pipe

[Andrey Repin]

Greetings, Kristian Ivarsson via Cygwin!

> If you're creating a lot's of named pipes in main process and in children
> and then using unlink, some of the named pipe files are not removed from the
> file system and no error is issued, i.e. unlink doesn't return -1

Open file will not be immediately removed on Windows.
However, if the file was deleted successfully, consequent attempts at opening
it will fail.


-- 
With best regards,
Andrey Repin
Friday, April 17, 2020 14:08:48

Sorry for my terrible english...

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

What is wrong with the name excel?

[Gerlach van Beinum via Cygwin]

I made a program to read a csv file from Excel. I called it excel.c
and it made an executable excel.exe
If irun that executable with:
./excel.exe
nothing happens, i.i. no output.

If I rename it to a.exe it runs OK.

What about this name excel??

My Cygwin version is up-to-date.

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

Re: Rsync frequently hangs

[Andrey Repin]

Greetings, Brent Epp!

> I have a large collection of custom tooling that depends on rsync.  It
> used to work very well, but recently, rsync has become highly unstable.  
> It frequently (dozens of times a day) hangs.  These are rsync executions 
> where the source and target are both on the same local drive.

> Eventually once it times out, it reports:

>      rsync: connection unexpectedly closed (0 bytes received so far) 
> [sender]
>      rsync error: error in rsync protocol data stream (code 12) at 
> io.c(226) [sender=3.1.2]

> No changes have recently been made to the tooling.  I just upgraded 
> cygwin as well, the problem persists.

> I'm going to do a clean install of cygwin, but if that doesn't solve 
> things, what else can I do?

Check for BLODA. Although I'm still suspicious.
All I've seen so far is

rsync error: protocol incompatibility (code 2) at receiver.c(582) 
[receiver=3.1.0]
rsync error: protocol incompatibility (code 2) at io.c(1642) [generator=3.1.0]

this is a link to production VPS. It consistently hangs midway the transfer.
Like it has a clairvoyance, no matter if the upload is 1 file of 100 files,
halfway through it drops, and I have to restart the upload, then it goes to
complete success.


-- 
With best regards,
Andrey Repin
Friday, April 17, 2020 13:04:33

Sorry for my terrible english...
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: setup-x86_64.exe --quiet-mode issues using Management Tools

[Andrey Repin]

Greetings, Bill Stewart!

> On Thu, Apr 16, 2020 at 2:25 AM KAVALAGIOS Panagiotis (EEAS-EXT) wrote:

>> > From: Cygwin On Behalf Of Bill Stewart
>> > On Wed, Apr 15, 2020 at 9:03 AM KAVALAGIOS Panagiotis (EEAS-EXT) wrote:
>> >
>> > > I have already requested a feature to totally remove any GUI from
>> > > silent installation:
>> > >
>> > > https://www.mail-archive.com/cygwin@cygwin.com/msg162887.html
>> >
>> > Just curious: Why does it matter whether a GUI appears or not, as long as 
>> > it
>> > doesn't block (stop for input)?
>>
>> Because the package can be sent to your machine when you are working
>> and we don't wish to disturb the users.

Since you install it as administrator, install it as a system application.
This way it is easier to integrate it with users' workflow AND your
infrastructure, and you could more easily control this integration as well as
protect it from accidental changes.

>> Everything is performed in the
>> background. Annoying popups are not welcomed. Silent installation is
>> supposed to be silent without any horns shouting in the foreground.

> If the install doesn't occur as the current user (and it shouldn't),
> the installation won't be visible anyway.

> I for one am against installers that run completely invisibly.

The problem is not the interface itself, the problem is that a user who see
a random program popped up on their screen could interrupt the installation,
intentionally or not.


-- 
With best regards,
Andrey Repin
Friday, April 17, 2020 12:59:54

Sorry for my terrible english...

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

[PATCH 2/2] cygheap_pwdgrp: Don't keep old schemes when parsing nsswitch.conf

[David Macek via Cygwin-patches]

The implicit assumption seemed to be that any subsequent occurence of
the same setting in nsswitch.conf is supposed to rewrite the previous
ones completely.  This was not the case if the third or any further
schema was previously defined and the last line defined less than that
(but at least 2), for example:

```
db_home: windows cygwin /myhome/%U
db_home: cygwin desc
```

Let's document this behavior as well.
---
 winsup/cygwin/uinfo.cc | 5 +++--
 winsup/doc/ntsec.xml   | 5 +
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
index 227faa4248..a4fcc33d8d 100644
--- a/winsup/cygwin/uinfo.cc
+++ b/winsup/cygwin/uinfo.cc
@@ -793,9 +793,10 @@ cygheap_pwdgrp::nss_init_line (const char *line)
scheme = gecos_scheme;
  if (scheme)
{
- uint16_t idx = 0;
+ for (uint16_t idx = 0; idx < NSS_SCHEME_MAX; ++idx)
+   scheme[idx].method = NSS_SCHEME_FALLBACK;
 
- scheme[0].method = scheme[1].method = NSS_SCHEME_FALLBACK;
+ uint16_t idx = 0;
  c = strchr (c, ':') + 1;
  c += strspn (c, " \t");
  while (*c && idx < NSS_SCHEME_MAX)
diff --git a/winsup/doc/ntsec.xml b/winsup/doc/ntsec.xml
index 5287845686..153ff1eac8 100644
--- a/winsup/doc/ntsec.xml
+++ b/winsup/doc/ntsec.xml
@@ -918,6 +918,11 @@ Apart from this restriction, the remainder of the line can 
have as
 many spaces and TABs as you like.
 
 
+
+When the same keyword occurs multiple times, the last one wins, as if the
+previous ones were ignored.
+
+
 
 
 The passwd: and 
group: settings
-- 
2.26.1.windows.1

[PATCH 1/2] cygheap_pwdgrp: Don't invent undocumented defaults in nsswitch.conf

[David Macek via Cygwin-patches]

---
 winsup/cygwin/uinfo.cc | 6 --
 1 file changed, 6 deletions(-)

diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
index 57d90189d3..227faa4248 100644
--- a/winsup/cygwin/uinfo.cc
+++ b/winsup/cygwin/uinfo.cc
@@ -831,12 +831,6 @@ cygheap_pwdgrp::nss_init_line (const char *line)
  c += strspn (c, " \t");
  ++idx;
}
- /* If nothing has been set, revert to default. */
- if (scheme[0].method == NSS_SCHEME_FALLBACK)
-   {
- scheme[0].method = NSS_SCHEME_CYGWIN;
- scheme[1].method = NSS_SCHEME_DESC;
-   }
}
}
   break;
-- 
2.26.1.windows.1

unlink does not remove named pipe

[Kristian Ivarsson via Cygwin]

If you're creating a lot's of named pipes in main process and in children
and then using unlink, some of the named pipe files are not removed from the
file system and no error is issued, i.e. unlink doesn't return -1

Kristian


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

Re: [PATCH] cygheap_pwdgrp: Handle invalid db_* entries correctly

[Corinna Vinschen]

On Apr 16 23:09, David Macek via Cygwin-patches wrote:
> If the first scheme in db_* was invalid, the code would think there
> were no schemes specified and replace the second scheme with
> NSS_SCHEME_DESC.
> 
> Signed-off-by: David Macek 
> ---
>  winsup/cygwin/uinfo.cc | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
> index bfcce00da0..be3c4855cc 100644
> --- a/winsup/cygwin/uinfo.cc
> +++ b/winsup/cygwin/uinfo.cc
> @@ -823,7 +823,10 @@ cygheap_pwdgrp::nss_init_line (const char *line)
> c, e - c);
>   }
> else
> - debug_printf ("Invalid nsswitch.conf content: %s", line);
> + {
> +   debug_printf ("Invalid nsswitch.conf content: %s", line);
> +   --idx;
> + }
> c += strcspn (c, " \t");
> c += strspn (c, " \t");
> ++idx;
> -- 
> 2.26.1.windows.1

Pushed.

Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

RE: setup-x86_64.exe --quiet-mode issues using Management Tools

[KAVALAGIOS Panagiotis (EEAS-EXT)]

> -Original Message-
> From: Cygwin  On Behalf Of Bill Stewart
> 
> On Thu, Apr 16, 2020 at 2:25 AM KAVALAGIOS Panagiotis (EEAS-EXT) wrote:
> 
> > Because the package can be sent to your machine when you are working
> > and we don't wish to disturb the users. Everything is performed in the
> > background. Annoying popups are not welcomed. Silent installation is
> > supposed to be silent without any horns shouting in the foreground.
> 
> If the install doesn't occur as the current user (and it shouldn't), the
> installation won't be visible anyway.
> 
> I for one am against installers that run completely invisibly.

I personally don't like stealth modifications to my system either. We are 
describing a different scenario and different needs. The users don't have admin 
rights in their machines and they have asked Cygwin to be included in the list 
of their development software. All the provided developer software so far 
includes silent installation apart from Cygwin, which you cannot call it 100% 
silent. We could also use a zip distribution for Cygwin, in fact that was our 
old deployment method, but half of the programs were able to run due to broken 
links. I know that there is a script to fix the links, but I would trust the 
setup itself better to avoid any possible issues on the users' machines.

This is the way that we are pushing the packages currently to end users is 
through software managers with silent installation. Of course, it would be far 
better to set up something like Windows Store, where the user can select 
Cygwin, launch its installation and have full control over it.

Kind regards,

Panos Kavalagios

Application Architect
CONSULIAT (under contract with the EEAS)
BA.BS.3.IS
_
Office: EEAS B100 Floor 5 Area 048
Rue Belliard 100, 1000 Brussels
Phone: +32 2 584 6017

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