* Re: Cygwin Digest, Vol 2, Issue 48
[not found] <mailman.10707.1587224442.8982.cygwin@cygwin.com>
@ 2020-04-18 16:17 ` Stephen Quintero
2020-04-18 17:26 ` Help William de la Vega
1 sibling, 0 replies; 2+ messages in thread
From: Stephen Quintero @ 2020-04-18 16:17 UTC (permalink / raw)
To: cygwin
On Sat, Apr 18, 2020, 8:42 AM <cygwin-request@cygwin.com> wrote:
> Send Cygwin mailing list submissions to
> cygwin@cygwin.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://cygwin.com/mailman/listinfo/cygwin
> or, via email, send a message with subject or body 'help' to
> cygwin-request@cygwin.com
>
> You can reach the person managing the list at
> cygwin-owner@cygwin.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cygwin digest..."
> Today's Topics:
>
> 1. Bug with Windows 10 console (akiki@free.fr)
> 2. [ANNOUNCEMENT] Updated: neomutt-20200417-1
> (Federico Kircheis via Cygwin-announce)
> 3. Re: Bug with Windows 10 console (Thomas Wolff)
> 4. Re: setup-x86_64.exe --quiet-mode issues using Management
> Tools (Jon Turney)
> 5. open write descriptor on named pipe sometime results in
> ENOENT (sten.kristian.ivarsson@gmail.com)
> 6. Re: katomic and atomix will not run (Phoenix Soul)
>
>
>
> ---------- Forwarded message ----------
> From: akiki@free.fr
> To: cygwin <cygwin@cygwin.com>
> Cc:
> Bcc:
> Date: Sat, 18 Apr 2020 14:42:16 +0200 (CEST)
> Subject: Bug with Windows 10 console
> Hi,
> To day, all programs are upgraded permanently. A good and a bad thing.
> Windows 10, cygwin ...
> One recent upgrade, I don't target exactly which one, has broken my
> environment.
>
>
> Current versions as reported by cygcheck :
> Windows 10 Professional Ver 10.0 Build 18363
> cygwin 3.1.4-1 OK
> bash 4.4.12-3 OK
>
> I am using 2 kinds of console to interact with cygwin
> mintty : using pty as TTY
> bash under cmd : using cons as TTY
>
> These two were working correctly until recently, but now only mintty stay
> correct.
> -- in reality it's seems
> The principal difference is about Ctrl-C interaction.
> With the 2nd kind of TTY, a same program using curses, on Ctrl-c
> interrupt the program
> give me a prompt
> but the terminal stay in curses mode, ie without echo and bad new line
> I have to do "reset" (/bin/reset) to restore the terminal
>
> So the interrupt handling has changed.
> Who is responsible.
>
> I had a look about the new Window Console Legacy.
> With this new console, we saw a black screen with color bash prompt.
>
> So with bash, is it possible to work with one or other TTY mode ?
>
> Howto understand this problem and what can I do to correct it.
> mintty present some problems with my environment and because of that I use
> the second form of TTY.
>
> Sorry for my bad English.
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Federico Kircheis via Cygwin-announce <cygwin-announce@cygwin.com>
> To: cygwin@cygwin.com
> Cc:
> Bcc:
> Date: Sat, 18 Apr 2020 15:50:16 +0200
> Subject: [ANNOUNCEMENT] Updated: neomutt-20200417-1
> Version 20200417-1 of neomutt has been uploaded.
>
> The command line mail reader neomutt reached version 20200417.
>
> On GitHub it is possible to find the changelog for the new release:
> https://github.com/neomutt/neomutt/releases
>
> Federico
>
>
>
>
> ---------- Forwarded message ----------
> From: Thomas Wolff <towo@towo.net>
> To: cygwin@cygwin.com
> Cc:
> Bcc:
> Date: Sat, 18 Apr 2020 16:05:54 +0200
> Subject: Re: Bug with Windows 10 console
> Am 18.04.2020 um 14:42 schrieb akiki@free.fr:
> > Hi,
> Bonjour
> > To day, all programs are upgraded permanently. A good and a bad thing.
> > Windows 10, cygwin ...
> > One recent upgrade, I don't target exactly which one, has broken my
> environment.
> >
> >
> > Current versions as reported by cygcheck :
> > Windows 10 Professional Ver 10.0 Build 18363
> > cygwin 3.1.4-1 OK
> > bash 4.4.12-3 OK
> >
> > I am using 2 kinds of console to interact with cygwin
> > mintty : using pty as TTY
> > bash under cmd : using cons as TTY
> >
> > These two were working correctly until recently, but now only mintty
> stay correct.
> > -- in reality it's seems
> > The principal difference is about Ctrl-C interaction.
> > With the 2nd kind of TTY, a same program using curses, on Ctrl-c
> > interrupt the program
> > give me a prompt
> > but the terminal stay in curses mode, ie without echo and bad new line
> > I have to do "reset" (/bin/reset) to restore the terminal
> >
> > So the interrupt handling has changed.
> > Who is responsible.
> It might help if you tell us *which* program behaves like that.
> >
> > I had a look about the new Window Console Legacy.
> > With this new console, we saw a black screen with color bash prompt.
> >
> > So with bash, is it possible to work with one or other TTY mode ?
> >
> > Howto understand this problem and what can I do to correct it.
> > mintty present some problems with my environment and because of that I
> use the second form of TTY.
> Which problems?
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Jon Turney <jon.turney@dronecode.org.uk>
> To: The Cygwin Mailing List <cygwin@cygwin.com>
> Cc:
> Bcc:
> Date: Sat, 18 Apr 2020 15:58:11 +0100
> Subject: Re: setup-x86_64.exe --quiet-mode issues using Management Tools
> On 15/04/2020 16:02, KAVALAGIOS Panagiotis (EEAS-EXT) wrote:
> >> From: Cygwin <cygwin-bounces@cygwin.com> On Behalf Of Paul Isaacson
> >> Hello Cygwin Support,
> >>
> >> I am trying to install Cygwin silently through a management tool like
> SCCM
> >> (called Bigfix). I went through the FAQ on your website to see what
> >> commands/switches existed. I would like to install silently without any
> user
> >> interaction and so I attempted to use setup-x86_64.exe --quiet-mode and
> I
> >> get into an infinite loop for the installation. Bigfix tells me that
> the installation
> >> is waiting for user response and will not continue. It gets stuck and
> can't
> >> start/finish the installation. Is there any suggestions on what I can
> try? I also
> >> want to install a bunch of packages during the installation but thought
> I would
> >> try to start at a completely silent installation firsts.
>
> It's possible that there are bugs in setup which cause quiet-mode to get
> stuck on some error conditions.
>
> Unfortunately, there's not enough information provided to know if that's
> the case here, or fix it if it is.
>
> >> I have also checked forums as well online to see if anyone else had
> issues. I
> >> found a one forum where someone is having the same issue with no
> >> resolution found here: https://www.itninja.com/question/cygwin-realy-
> >> silent-installation-no-progress-window-with-option-to-counsel
> >
> > Welcome to the club. Unfortunately, Cygwin setup is not friendly for
> Software Managers. After a lot of research, I have ended up to the
> following command:
> >
> > ----------------
> > @echo off
> > @echo Starting Cygwin installation
> >
> > "%cd%\setup-x86_64.exe" -q -A -L -l "%cd%\cygwin-repo" -R "C:\Program
> Files\Cygwin" -P
> autoconf,automake,bash-completion,binutils,curl,emacs,git,git-svn,gnupg2,inetutils,konsole,mc,openssh,patchutils,perl,python2,python3,rsync,ruby,subversion,tcsh,tmux,unzip,vim,vim-common,wget,xinit,xlaunch,xorg-server,xorg-server-common,xorg-server-xorg,xorg-x11-fonts-dpi100,xorg-x11-fonts-dpi75,xorg-x11-fonts-Type1,xorg-x11-fonts-misc,xterm,zip
> > ----------------
> >
> > wrapped in a nice "setup-x86_64.bat" that is executed by the
> installation Powershell script. That command is still popping up a progress
> window, but it was removed by our Landesk configuration. You may check if
> yours having the same option not to allow any GUI to be displayed by the
> installation program.
> >
> > I have already requested a feature to totally remove any GUI from silent
> installation:
> >
> > https://www.mail-archive.com/cygwin@cygwin.com/msg162887.html
> >
>
> Yeah, about that...
>
> If you want to see a feature added to setup, by far the best way is to
> provide a patch to add it.
>
>
>
>
> ---------- Forwarded message ----------
> From: <sten.kristian.ivarsson@gmail.com>
> To: <cygwin@cygwin.com>
> Cc:
> Bcc:
> Date: Sat, 18 Apr 2020 17:24:28 +0200
> Subject: open write descriptor on named pipe sometime results in ENOENT
> Hey all
>
>
> We're trying to nail down some issues with using named pipes
>
> The issue we're getting is deterministic (ENXIO) but it is not this one,
> but
> we think this issue is worth reporting anyway
>
>
> We're using the branch topic/fifo
>
>
>
> The program explained in short is:
>
>
> - One main (parent) pipe that lives through the whole execution
>
> - The main process forks 'children' child-processes that creates their own
> (unique) named pipes
>
> - Each child forks 'children' grans-child-processes that just writes some
> bogus messages back to the unique child pipe
>
> - Each child writes a bogus message back to the main process
>
> - Every process creates a write and a read descriptor, but the write
> descriptor is just a dummy descriptor (to somehow keep the pipe alive
> without being bombarded with signals)
>
> - This iterates a few times
>
>
> Some of the constructs may be a bit confusing and maybe not relevant to
> this
> issue, but I left them in the test-program anyway
>
>
>
>
> Issue #1 sometimes occurs in line 35 (printed as 36) we get ENOENT (No such
> file or directory) despite that the pipe was just created and the read
> descriptor successfully was opened
>
> *wfd = open(name, O_WRONLY);
>
>
> Issue #2 sometimes occurs in line 73 (printed as 74) we get EBUSY (Device
> or
> resource busy) when attempting to open a non blocking descriptor
>
> const int wfd = open(name, O_WRONLY | O_NONBLOCK);
>
>
> Issue #3 sometimes occurs somewhere unknown and the main process just get
> stuck (I've failed to reproduced that with strace or so) and to not have
> any
> more input so maybe this should be left out ?
>
>
>
> I hope this is well described and hopefully it's enough to reproduce the
> issue(s) and hopefully is not due to a fault test case ;-)
>
>
>
> Kristian
>
>
>
>
> ---------- Forwarded message ----------
> From: Phoenix Soul <phoenixlight101@gmail.com>
> To: moss@cs.umass.edu
> Cc: cygwin@cygwin.com
> Bcc:
> Date: Sat, 18 Apr 2020 08:40:28 -0700
> Subject: Re: katomic and atomix will not run
> No, I haven't. What is it and how do I run one?
>
> On Fri, Apr 17, 2020 at 3:23 PM Eliot Moss <moss@cs.umass.edu> wrote:
>
> > 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
> >
>
>
> --
> From, Warrick
>
> --
> 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
>
^ permalink raw reply [flat|nested] 2+ messages in thread* Help
[not found] <mailman.10707.1587224442.8982.cygwin@cygwin.com>
2020-04-18 16:17 ` Cygwin Digest, Vol 2, Issue 48 Stephen Quintero
@ 2020-04-18 17:26 ` William de la Vega
1 sibling, 0 replies; 2+ messages in thread
From: William de la Vega @ 2020-04-18 17:26 UTC (permalink / raw)
To: cygwin
Help
On Sat, Apr 18, 2020 at 11:42 <cygwin-request@cygwin.com> wrote:
> Send Cygwin mailing list submissions to
> cygwin@cygwin.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://cygwin.com/mailman/listinfo/cygwin
> or, via email, send a message with subject or body 'help' to
> cygwin-request@cygwin.com
>
> You can reach the person managing the list at
> cygwin-owner@cygwin.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cygwin digest..."
> Today's Topics:
>
> 1. Bug with Windows 10 console (akiki@free.fr)
> 2. [ANNOUNCEMENT] Updated: neomutt-20200417-1
> (Federico Kircheis via Cygwin-announce)
> 3. Re: Bug with Windows 10 console (Thomas Wolff)
> 4. Re: setup-x86_64.exe --quiet-mode issues using Management
> Tools (Jon Turney)
> 5. open write descriptor on named pipe sometime results in
> ENOENT (sten.kristian.ivarsson@gmail.com)
> 6. Re: katomic and atomix will not run (Phoenix Soul)
>
>
>
> ---------- Forwarded message ----------
> From: akiki@free.fr
> To: cygwin <cygwin@cygwin.com>
> Cc:
> Bcc:
> Date: Sat, 18 Apr 2020 14:42:16 +0200 (CEST)
> Subject: Bug with Windows 10 console
> Hi,
> To day, all programs are upgraded permanently. A good and a bad thing.
> Windows 10, cygwin ...
> One recent upgrade, I don't target exactly which one, has broken my
> environment.
>
>
> Current versions as reported by cygcheck :
> Windows 10 Professional Ver 10.0 Build 18363
> cygwin 3.1.4-1 OK
> bash 4.4.12-3 OK
>
> I am using 2 kinds of console to interact with cygwin
> mintty : using pty as TTY
> bash under cmd : using cons as TTY
>
> These two were working correctly until recently, but now only mintty stay
> correct.
> -- in reality it's seems
> The principal difference is about Ctrl-C interaction.
> With the 2nd kind of TTY, a same program using curses, on Ctrl-c
> interrupt the program
> give me a prompt
> but the terminal stay in curses mode, ie without echo and bad new line
> I have to do "reset" (/bin/reset) to restore the terminal
>
> So the interrupt handling has changed.
> Who is responsible.
>
> I had a look about the new Window Console Legacy.
> With this new console, we saw a black screen with color bash prompt.
>
> So with bash, is it possible to work with one or other TTY mode ?
>
> Howto understand this problem and what can I do to correct it.
> mintty present some problems with my environment and because of that I use
> the second form of TTY.
>
> Sorry for my bad English.
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Federico Kircheis via Cygwin-announce <cygwin-announce@cygwin.com>
> To: cygwin@cygwin.com
> Cc:
> Bcc:
> Date: Sat, 18 Apr 2020 15:50:16 +0200
> Subject: [ANNOUNCEMENT] Updated: neomutt-20200417-1
> Version 20200417-1 of neomutt has been uploaded.
>
> The command line mail reader neomutt reached version 20200417.
>
> On GitHub it is possible to find the changelog for the new release:
> https://github.com/neomutt/neomutt/releases
>
> Federico
>
>
>
>
> ---------- Forwarded message ----------
> From: Thomas Wolff <towo@towo.net>
> To: cygwin@cygwin.com
> Cc:
> Bcc:
> Date: Sat, 18 Apr 2020 16:05:54 +0200
> Subject: Re: Bug with Windows 10 console
> Am 18.04.2020 um 14:42 schrieb akiki@free.fr:
> > Hi,
> Bonjour
> > To day, all programs are upgraded permanently. A good and a bad thing.
> > Windows 10, cygwin ...
> > One recent upgrade, I don't target exactly which one, has broken my
> environment.
> >
> >
> > Current versions as reported by cygcheck :
> > Windows 10 Professional Ver 10.0 Build 18363
> > cygwin 3.1.4-1 OK
> > bash 4.4.12-3 OK
> >
> > I am using 2 kinds of console to interact with cygwin
> > mintty : using pty as TTY
> > bash under cmd : using cons as TTY
> >
> > These two were working correctly until recently, but now only mintty
> stay correct.
> > -- in reality it's seems
> > The principal difference is about Ctrl-C interaction.
> > With the 2nd kind of TTY, a same program using curses, on Ctrl-c
> > interrupt the program
> > give me a prompt
> > but the terminal stay in curses mode, ie without echo and bad new line
> > I have to do "reset" (/bin/reset) to restore the terminal
> >
> > So the interrupt handling has changed.
> > Who is responsible.
> It might help if you tell us *which* program behaves like that.
> >
> > I had a look about the new Window Console Legacy.
> > With this new console, we saw a black screen with color bash prompt.
> >
> > So with bash, is it possible to work with one or other TTY mode ?
> >
> > Howto understand this problem and what can I do to correct it.
> > mintty present some problems with my environment and because of that I
> use the second form of TTY.
> Which problems?
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Jon Turney <jon.turney@dronecode.org.uk>
> To: The Cygwin Mailing List <cygwin@cygwin.com>
> Cc:
> Bcc:
> Date: Sat, 18 Apr 2020 15:58:11 +0100
> Subject: Re: setup-x86_64.exe --quiet-mode issues using Management Tools
> On 15/04/2020 16:02, KAVALAGIOS Panagiotis (EEAS-EXT) wrote:
> >> From: Cygwin <cygwin-bounces@cygwin.com> On Behalf Of Paul Isaacson
> >> Hello Cygwin Support,
> >>
> >> I am trying to install Cygwin silently through a management tool like
> SCCM
> >> (called Bigfix). I went through the FAQ on your website to see what
> >> commands/switches existed. I would like to install silently without any
> user
> >> interaction and so I attempted to use setup-x86_64.exe --quiet-mode and
> I
> >> get into an infinite loop for the installation. Bigfix tells me that
> the installation
> >> is waiting for user response and will not continue. It gets stuck and
> can't
> >> start/finish the installation. Is there any suggestions on what I can
> try? I also
> >> want to install a bunch of packages during the installation but thought
> I would
> >> try to start at a completely silent installation firsts.
>
> It's possible that there are bugs in setup which cause quiet-mode to get
> stuck on some error conditions.
>
> Unfortunately, there's not enough information provided to know if that's
> the case here, or fix it if it is.
>
> >> I have also checked forums as well online to see if anyone else had
> issues. I
> >> found a one forum where someone is having the same issue with no
> >> resolution found here: https://www.itninja.com/question/cygwin-realy-
> >> silent-installation-no-progress-window-with-option-to-counsel
> >
> > Welcome to the club. Unfortunately, Cygwin setup is not friendly for
> Software Managers. After a lot of research, I have ended up to the
> following command:
> >
> > ----------------
> > @echo off
> > @echo Starting Cygwin installation
> >
> > "%cd%\setup-x86_64.exe" -q -A -L -l "%cd%\cygwin-repo" -R "C:\Program
> Files\Cygwin" -P
> autoconf,automake,bash-completion,binutils,curl,emacs,git,git-svn,gnupg2,inetutils,konsole,mc,openssh,patchutils,perl,python2,python3,rsync,ruby,subversion,tcsh,tmux,unzip,vim,vim-common,wget,xinit,xlaunch,xorg-server,xorg-server-common,xorg-server-xorg,xorg-x11-fonts-dpi100,xorg-x11-fonts-dpi75,xorg-x11-fonts-Type1,xorg-x11-fonts-misc,xterm,zip
> > ----------------
> >
> > wrapped in a nice "setup-x86_64.bat" that is executed by the
> installation Powershell script. That command is still popping up a progress
> window, but it was removed by our Landesk configuration. You may check if
> yours having the same option not to allow any GUI to be displayed by the
> installation program.
> >
> > I have already requested a feature to totally remove any GUI from silent
> installation:
> >
> > https://www.mail-archive.com/cygwin@cygwin.com/msg162887.html
> >
>
> Yeah, about that...
>
> If you want to see a feature added to setup, by far the best way is to
> provide a patch to add it.
>
>
>
>
> ---------- Forwarded message ----------
> From: <sten.kristian.ivarsson@gmail.com>
> To: <cygwin@cygwin.com>
> Cc:
> Bcc:
> Date: Sat, 18 Apr 2020 17:24:28 +0200
> Subject: open write descriptor on named pipe sometime results in ENOENT
> Hey all
>
>
> We're trying to nail down some issues with using named pipes
>
> The issue we're getting is deterministic (ENXIO) but it is not this one,
> but
> we think this issue is worth reporting anyway
>
>
> We're using the branch topic/fifo
>
>
>
> The program explained in short is:
>
>
> - One main (parent) pipe that lives through the whole execution
>
> - The main process forks 'children' child-processes that creates their own
> (unique) named pipes
>
> - Each child forks 'children' grans-child-processes that just writes some
> bogus messages back to the unique child pipe
>
> - Each child writes a bogus message back to the main process
>
> - Every process creates a write and a read descriptor, but the write
> descriptor is just a dummy descriptor (to somehow keep the pipe alive
> without being bombarded with signals)
>
> - This iterates a few times
>
>
> Some of the constructs may be a bit confusing and maybe not relevant to
> this
> issue, but I left them in the test-program anyway
>
>
>
>
> Issue #1 sometimes occurs in line 35 (printed as 36) we get ENOENT (No such
> file or directory) despite that the pipe was just created and the read
> descriptor successfully was opened
>
> *wfd = open(name, O_WRONLY);
>
>
> Issue #2 sometimes occurs in line 73 (printed as 74) we get EBUSY (Device
> or
> resource busy) when attempting to open a non blocking descriptor
>
> const int wfd = open(name, O_WRONLY | O_NONBLOCK);
>
>
> Issue #3 sometimes occurs somewhere unknown and the main process just get
> stuck (I've failed to reproduced that with strace or so) and to not have
> any
> more input so maybe this should be left out ?
>
>
>
> I hope this is well described and hopefully it's enough to reproduce the
> issue(s) and hopefully is not due to a fault test case ;-)
>
>
>
> Kristian
>
>
>
>
> ---------- Forwarded message ----------
> From: Phoenix Soul <phoenixlight101@gmail.com>
> To: moss@cs.umass.edu
> Cc: cygwin@cygwin.com
> Bcc:
> Date: Sat, 18 Apr 2020 08:40:28 -0700
> Subject: Re: katomic and atomix will not run
> No, I haven't. What is it and how do I run one?
>
> On Fri, Apr 17, 2020 at 3:23 PM Eliot Moss <moss@cs.umass.edu> wrote:
>
> > 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
> >
>
>
> --
> From, Warrick
>
> --
> 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
>
^ permalink raw reply [flat|nested] 2+ messages in thread