On Nov 30 21:27, Brian Inglis wrote:
> On 2018-11-30 05:56, Corinna Vinschen wrote:
> > On Nov 30 07:43, James E. King III wrote:
> >> On Fri, Nov 30, 2018 at 7:23 AM Corinna Vinschen wrote:
> >>> On Nov 29 17:38, James E. King III wrote:
> >>>> On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen wrote:
> >>>>> I created a patch and uploaded new developer snapshots to
> >>>>> https://cygwin.com/snapshots/  Please give them a try.
> >>>> This fixed the issue for me.  What's the best way to detect cygwin
> >>>> with this support?
> >>> This will show up in version 2.12.0(*) so checking the release field
> >>> from uname(2) should do the trick.
> >> Is there a programmatic way to check this without having to parse a
> >> bunch of char[20] from utsname.h?
> > How would you do this on Linux?
> 
> Same:
> https://stackoverflow.com/questions/46280456/check-kernel-version-at-runtime-in-c
> 
> - read /proc/version which is generated from utsname fields (or vice versa)
> using e.g fscanf
> 
> $ head /proc/version
> CYGWIN_NT-10.0 version 2.11.2(0.329/5/3) (corinna@calimero.vinschen.de) (gcc
> version 7.3.0 20180125 (Fedora Cygwin 7.3.0-2) (GCC) ) 2018-11-08 14:34
> 
> - read (or source) /{etc,usr/lib}/os-release VERSION_ID line (or variable):
> 
> $ head /{etc,usr/lib}/os-release
> ==> /etc/os-release <==
> PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
> NAME="Debian GNU/Linux"
> VERSION_ID="9"
> VERSION="9 (stretch)"
> ID=debian
> HOME_URL="https://www.debian.org/"
> SUPPORT_URL="https://www.debian.org/support"
> BUG_REPORT_URL="https://bugs.debian.org/"
> 
> ==> /usr/lib/os-release <==
> ... [same]
> 
> Could also be supported under Cygwin:

We don't have OS releases.  Every component in Cygwin has its own
release cycle and the version number of the Cygwin DLL is *not* a
os release number.  What sense would this file have for us?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer