[ANNOUNCEMENT] lftp 4.7.3
lftp 4.7.3 is now available in Cygwin. This is a minor upstream release. See http://lftp.yar.ru/news.html for the list of changes. lftp is a sophisticated file transfer program and ftp/http/bittorrent client. It supports multiple network protocols. It uses the readline library for input, so it offers tab completion and command history. It has job control and bookmarks. It can mirror sites and transfer multiple files in parallel. It keeps trying interrupted operations until it can complete them. Andrew E. Schulman *** To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com_at_cygwin.com If you need more information on unsubscribing, start reading here: http://cygwin.com/lists.html#subscribe-unsubscribe Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: [PATCH] Strange behavior of cmd.exe when hammered with clear screen operations from Cygwin program.
On Aug 2 23:19, Kaz Kylheku wrote: > On 01.08.2016 01:51, Corinna Vinschen wrote: > > On Jul 29 08:59, Kaz Kylheku wrote: > > > On 29.07.2016 03:39, Corinna Vinschen wrote: > > > > I applied a patch to perform this action. It's in the latest > > > > 2.6.0-0.5 test release I just announced. > > > [...] > > > I've done some interactive testing with this using > > > the interpreter for a Lisp dialect. I would evaluate > > > this expression to generate a 5 second delay and then > > > a clear screen VT100 sequence: > > > > > > (progn (usleep 500) (put-string "\e[2J")) > > > > > > during this time, I would scroll the buffer somewhere. > > > > > > I also tested with a cursor position somewhere in the > > > middle of the window, having issued: > > > > > > (put-string "\e[12H") > > > > > > The programming language details don't matter; we > > > could do this with bash echo $'\e...' and sleep 5. > > > [...] > > > With the third patch, I've run into behavior in which the > > > display isn't cleared at all if the clear is issued > > > in a scrolled-back state. > > > > I can't reproduce this. If I don't click wildly on the scroll bat at > > the time the clear screen action takes place (so I move the window right > > after clear screen), the cursor is positioned at the top of the screen, > > at the end of the buffer. So, how would I reproduce your observation so > > that all window positioning is guaranteed to take place *before* the > > clear screen action and still see the broken output? > > Hi Corinna, > > I have figured out how to reproduce it. There are two > necessary conditions. No, three: > > 1. You must scroll the display all the way to the top >as far as you can before the clear screen is issued. > > 2. The scrollback history must be full. I.e., this >won't happen in a fresh cmd.exe window. First, print >thousands of lines of stuff to make the buffer "tall". >This is why it only started happening to me after some >amount of testing; I had filled the buffer. > > 3. It's probably a necessary condition that there is additional >output immediately after the clear screen (such as the >programming language prompt being printed), because >the console scrolls to bottom on any output. > > I'm not sure if these are sufficient, but they seem to be > on my end. I could reproduce this now and I think I have fixed it. There's still a problem with the position of the scrollbars in certain scenarios where they are off by about one window size. I added a FIXME comment. I have to admit I'm very puzzled that neither SetConsoleWindowInfo nor the subsequent SetConsoleCursorPosition automatically set the scrollbars correctly. That's what I would expect, naively. If anybody knows how to fix the scrollbar position in a Windows console without moving the window contents around, please help. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: /dev/ptmx fails with Azure accounts
On Aug 2 12:54, rm...@aboutgolf.com wrote:
> [I'm so sorry I'm messing up the mailing list by not replying to the proper
> email I only just got it through my thick skull now to subscribe to the
> mailing list. I think my brain is on vacation already]
>
>
> Unfortunately your prediction was correct - RunAs Administrator CMD gives
> this:
Thanks!
In the meantime I prepared my test application. Can you please fetch
the attached source and store it as, e.g., azure-check.c. Then build
and run it like this:
$ gcc -g -o azure-check azure-check.c -lnetapi32
$ ./azure-check
Then run it and paste the complete output into your reply.
I have an idea for an extension of this testcase, but I think I have
to see the output of this one first.
Thanks in advance,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
#include
#define _WIN32_WINNT 0x0a00
#define WINVER 0x0a00
#include
#include
#include
#include
#include
int
main ()
{
HANDLE lsa;
NTSTATUS status;
ULONG ret;
PPOLICY_DNS_DOMAIN_INFO pdom;
PPOLICY_ACCOUNT_DOMAIN_INFO adom;
PDS_DOMAIN_TRUSTSW td;
ULONG tdom_cnt;
static LSA_OBJECT_ATTRIBUTES oa = { 0, 0, 0, 0, 0, 0 };
LPSTR str;
BOOL has_dom;
HANDLE tok;
WCHAR name[256];
WCHAR dom[256];
DWORD nlen, dlen;
SID_NAME_USE type;
status = LsaOpenPolicy (NULL, &oa, POLICY_VIEW_LOCAL_INFORMATION, &lsa);
if (!NT_SUCCESS (status))
{
printf ("LsaOpenPolicy: 0x%08x\n", status);
return 1;
}
status = LsaQueryInformationPolicy (lsa, PolicyDnsDomainInformation,
(PVOID *) &pdom);
if (NT_SUCCESS (status))
{
if (pdom->Name.Length)
printf ("PDom.Name: %ls\n", pdom->Name.Buffer);
if (pdom->DnsDomainName.Length)
printf ("PDom.DnsDomainName: %ls\n", pdom->DnsDomainName.Buffer);
if (pdom->DnsForestName.Length)
printf ("PDom.DnsForestName: %ls\n", pdom->DnsForestName.Buffer);
has_dom = !!pdom->Sid;
if (has_dom)
{
ConvertSidToStringSidA (pdom->Sid, &str);
printf ("PDom.Sid: %s\n", str);
LocalFree (str);
}
LsaFreeMemory (pdom);
}
else
printf ("LsaQueryInformationPolicy (PDOM): 0x%08x\n", status);
status = LsaQueryInformationPolicy (lsa, PolicyAccountDomainInformation,
(PVOID *) &adom);
if (NT_SUCCESS (status))
{
if (adom->DomainName.Length)
printf ("ADom.DomainName: %ls\n", adom->DomainName.Buffer);
ConvertSidToStringSidA (adom->DomainSid, &str);
printf ("ADom.DomainSid: %s\n", str);
LocalFree (str);
LsaFreeMemory (adom);
}
else
printf ("LsaQueryInformationPolicy (ADOM): 0x%08x\n", status);
if (dom)
{
ret = DsEnumerateDomainTrustsW (NULL, DS_DOMAIN_DIRECT_INBOUND
| DS_DOMAIN_DIRECT_OUTBOUND
| DS_DOMAIN_IN_FOREST,
&td, &tdom_cnt);
if (ret == ERROR_SUCCESS)
for (ULONG idx = 0; idx < tdom_cnt; ++idx)
{
printf ("Trusted Domain %u:\n", idx);
printf (" NetbiosDomainName: %ls\n", td[idx].NetbiosDomainName);
if (td[idx].DnsDomainName)
printf (" DnsDomainName: %ls\n", td[idx].DnsDomainName);
printf (" Flags: 0x%08x\n", td[idx].Flags);
printf (" TrustType: 0x%08x\n", td[idx].TrustType);
printf (" TrustAttributes: 0x%08x\n", td[idx].TrustAttributes);
if (td[idx].DomainSid)
{
ConvertSidToStringSidA (td[idx].DomainSid, &str);
printf ("DomainSid: %s\n", str);
LocalFree (str);
}
}
else
printf ("DsEnumerateDomainTrustsW: %u\n", ret);
}
LsaClose (lsa);
if (OpenProcessToken (GetCurrentProcess (), TOKEN_QUERY, &tok))
{
PTOKEN_USER tp = (PTOKEN_USER) malloc (65536);
if (GetTokenInformation (tok, TokenUser, tp, 65536, &ret))
{
printf ("User:\n");
ConvertSidToStringSidA (tp->User.Sid, &str);
printf (" Sid: %s\n", str);
LocalFree (str);
nlen = dlen = 256;
if (LookupAccountSidW (NULL, tp->User.Sid, name, &nlen,
dom, &dlen, &type))
printf (" Dom\\Name: %ls\\%ls\n", dom, name);
else
printf (" LookupAccountSidW: %u\n", GetLastError ());
printf (" Attributes: 0x%08x\n", tp->User.Attributes);
}
else
printf ("GetTokenInformation(user): %u\n", GetLastError ());
free (tp);
PTOKEN_GROUPS tg = (PTOKEN_GROUPS) malloc (65536);
if (GetTokenInformation (tok, TokenGroups, tg, 65536, &ret))
for (ULONG idx = 0; idx < tg->GroupCount; ++idx)
{
Re: /dev/ptmx fails with Azure accounts
On Wednesday, August 3, 2016 10:32, "Corinna Vinschen" said: > > In the meantime I prepared my test application. Can you please fetch > the attached source and store it as, e.g., azure-check.c. Then build > and run it like this: > > $ gcc -g -o azure-check azure-check.c -lnetapi32 > $ ./azure-check > > Then run it and paste the complete output into your reply. > > I have an idea for an extension of this testcase, but I think I have > to see the output of this one first. The output is as below. This was without Run As Administrator - with it the Group 0 Sid changed to S-1-16-12288/High Mandatory Level, which *seems* appropriate Unknown+User@Lenovo-PC /cygdrive/c/cygwin64 $ ./azure-check PDom.Name: WORKGROUP ADom.DomainName: Lenovo-PC ADom.DomainSid: S-1-5-21-1836915194-3548948870-2562531131 DsEnumerateDomainTrustsW: 1722 User: Sid: S-1-12-1-2043906341-1249388050-2635137163-399631282 Dom\Name: AzureAD\RussellMora Attributes: 0x Group 0 Sid: S-1-16-8192 Dom\Name: Mandatory Label\Medium Mandatory Level Attributes: 0x0060 Group 1 Sid: S-1-1-0 Dom\Name: \Everyone Attributes: 0x0007 Group 2 Sid: S-1-5-32-544 Dom\Name: BUILTIN\Administrators Attributes: 0x0010 Group 3 Sid: S-1-5-32-545 Dom\Name: BUILTIN\Users Attributes: 0x0007 Group 4 Sid: S-1-5-4 Dom\Name: NT AUTHORITY\INTERACTIVE Attributes: 0x0007 Group 5 Sid: S-1-2-1 Dom\Name: \CONSOLE LOGON Attributes: 0x0007 Group 6 Sid: S-1-5-11 Dom\Name: NT AUTHORITY\Authenticated Users Attributes: 0x0007 Group 7 Sid: S-1-5-15 Dom\Name: NT AUTHORITY\This Organization Attributes: 0x0007 Group 8 Sid: S-1-5-5-0-852920 Dom\Name: NT AUTHORITY\LogonSessionId_0_852920 Attributes: 0xc007 Group 9 Sid: S-1-2-0 Dom\Name: \LOCAL Attributes: 0x0007 Group 10 Sid: S-1-12-1-2741946010-1181797680-2322883994-3292483823 LookupAccountSidW: 1332 Attributes: 0x0007 Group 11 Sid: S-1-5-64-36 Dom\Name: NT AUTHORITY\Cloud Account Authentication Attributes: 0x0007 Unknown+User@Lenovo-PC /cygdrive/c/cygwin64 $ HTH! Cheers, Russell -- 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: /dev/ptmx fails with Azure accounts
On Aug 3 12:53, rm...@aboutgolf.com wrote:
>
>
> On Wednesday, August 3, 2016 10:32, "Corinna Vinschen"
> said:
> >
> > In the meantime I prepared my test application. Can you please fetch
> > the attached source and store it as, e.g., azure-check.c. Then build
> > and run it like this:
> >
> > $ gcc -g -o azure-check azure-check.c -lnetapi32
> > $ ./azure-check
> >
> > Then run it and paste the complete output into your reply.
> >
> > I have an idea for an extension of this testcase, but I think I have
> > to see the output of this one first.
>
> The output is as below. This was without Run As Administrator - with
> it the Group 0 Sid changed to S-1-16-12288/High Mandatory Level, which
> *seems* appropriate
It is. Thanks for this test, the result is as horrifying as I imagined.
Can you please try the testcase attached to this mail, too? It should
be built and run the same way:
$ gcc -g -o azure-check2 azure-check2.c -lnetapi32
$ ./azure-check2
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
#include
#define _WIN32_WINNT 0x0a00
#define WINVER 0x0a00
#include
#include
#include
int
main ()
{
HANDLE tok;
PTOKEN_USER tp = (PTOKEN_USER) malloc (65536);
DWORD ret;
LPSTR str;
WCHAR name[256];
WCHAR dom[256];
DWORD nlen, dlen;
SID_NAME_USE type;
NET_API_STATUS status;
PUSER_INFO_24 ui24;
if (!OpenProcessToken (GetCurrentProcess (), TOKEN_QUERY, &tok))
{
printf ("OpenProcessToken: %u\n", GetLastError ());
return 1;
}
if (!GetTokenInformation (tok, TokenUser, tp, 65536, &ret))
{
printf ("GetTokenInformation(user): %u\n", GetLastError ());
return 1;
}
ConvertSidToStringSidA (tp->User.Sid, &str);
printf (" Sid: %s\n", str);
LocalFree (str);
nlen = dlen = 256;
if (LookupAccountSidW (NULL, tp->User.Sid, name, &nlen,
dom, &dlen, &type))
printf ("Dom\\Name: %ls\\%ls\n", dom, name);
else
printf ("LookupAccountSidW: %u\n", GetLastError ());
printf ("Attributes: 0x%08x\n", tp->User.Attributes);
status = NetUserGetInfo (NULL, name, 24, (PBYTE *) &ui24);
if (status != NERR_Success)
{
status = NetUserGetInfo (dom, name, 24, (PBYTE *) &ui24);
if (status != NERR_Success)
{
printf ("NetUserGetInfo: %u\n", status);
return 1;
}
}
printf ("UserInfo:\n");
printf (" InternetIdentity: %d\n", ui24->usri24_internet_identity);
printf (" Flags: 0x%08x\n", ui24->usri24_flags);
printf (" ProviderName: %ls\n", ui24->usri24_internet_provider_name);
printf (" PrincipalName: %ls\n", ui24->usri24_internet_principal_name);
ConvertSidToStringSidA (ui24->usri24_user_sid, &str);
printf (" Sid: %s\n", str);
LocalFree (str);
return 0;
}
signature.asc
Description: PGP signature
Re: /dev/ptmx fails with Azure accounts
On Aug 3 20:00, Corinna Vinschen wrote:
> On Aug 3 12:53, rm...@aboutgolf.com wrote:
> >
> >
> > On Wednesday, August 3, 2016 10:32, "Corinna Vinschen"
> > said:
> > >
> > > In the meantime I prepared my test application. Can you please fetch
> > > the attached source and store it as, e.g., azure-check.c. Then build
> > > and run it like this:
> > >
> > > $ gcc -g -o azure-check azure-check.c -lnetapi32
> > > $ ./azure-check
> > >
> > > Then run it and paste the complete output into your reply.
> > >
> > > I have an idea for an extension of this testcase, but I think I have
> > > to see the output of this one first.
> >
> > The output is as below. This was without Run As Administrator - with
> > it the Group 0 Sid changed to S-1-16-12288/High Mandatory Level, which
> > *seems* appropriate
>
> It is. Thanks for this test, the result is as horrifying as I imagined.
> Can you please try the testcase attached to this mail, too? It should
> be built and run the same way:
>
> $ gcc -g -o azure-check2 azure-check2.c -lnetapi32
> $ ./azure-check2
Pleae use the one attached in this mail. I noticed I forgot to print
primary group info. It's not unimportant to see it as well.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
#include
#define _WIN32_WINNT 0x0a00
#define WINVER 0x0a00
#include
#include
#include
int
main ()
{
HANDLE tok;
PTOKEN_USER tp = (PTOKEN_USER) malloc (65536);
DWORD ret;
LPSTR str;
WCHAR name[256];
WCHAR dom[256];
DWORD nlen, dlen;
SID_NAME_USE type;
NET_API_STATUS status;
PUSER_INFO_24 ui24;
if (!OpenProcessToken (GetCurrentProcess (), TOKEN_QUERY, &tok))
{
printf ("OpenProcessToken: %u\n", GetLastError ());
return 1;
}
if (!GetTokenInformation (tok, TokenUser, tp, 65536, &ret))
{
printf ("GetTokenInformation(user): %u\n", GetLastError ());
return 1;
}
ConvertSidToStringSidA (tp->User.Sid, &str);
printf (" Sid: %s\n", str);
LocalFree (str);
nlen = dlen = 256;
if (LookupAccountSidW (NULL, tp->User.Sid, name, &nlen,
dom, &dlen, &type))
printf ("Dom\\Name: %ls\\%ls\n", dom, name);
else
printf ("LookupAccountSidW: %u\n", GetLastError ());
PTOKEN_PRIMARY_GROUP tpg = (PTOKEN_PRIMARY_GROUP) malloc (65536);
if (GetTokenInformation (tok, TokenPrimaryGroup, tpg, 65536, &ret))
{
printf ("Primary Group:\n");
ConvertSidToStringSidA (tpg->PrimaryGroup, &str);
printf (" Sid: %s\n", str);
LocalFree (str);
nlen = dlen = 256;
if (LookupAccountSidW (NULL, tpg->PrimaryGroup, name, &nlen,
dom, &dlen, &type))
printf (" Dom\\Name: %ls\\%ls\n", dom, name);
else
printf (" LookupAccountSidW: %u\n", GetLastError ());
}
else
printf ("GetTokenInformation(primary): %u\n", GetLastError ());
free (tpg);
status = NetUserGetInfo (NULL, name, 24, (PBYTE *) &ui24);
if (status != NERR_Success)
{
status = NetUserGetInfo (dom, name, 24, (PBYTE *) &ui24);
if (status != NERR_Success)
{
printf ("NetUserGetInfo: %u\n", status);
return 1;
}
}
printf ("UserInfo:\n");
printf (" InternetIdentity: %d\n", ui24->usri24_internet_identity);
printf (" Flags: 0x%08x\n", ui24->usri24_flags);
printf (" ProviderName: %ls\n", ui24->usri24_internet_provider_name);
printf (" PrincipalName: %ls\n", ui24->usri24_internet_principal_name);
ConvertSidToStringSidA (ui24->usri24_user_sid, &str);
printf (" Sid: %s\n", str);
LocalFree (str);
return 0;
}
signature.asc
Description: PGP signature
Re: /dev/ptmx fails with Azure accounts
On Wednesday, August 3, 2016 14:16, "Corinna Vinschen" said: > On Aug 3 20:00, Corinna Vinschen wrote: >> On Aug 3 12:53, rm...@aboutgolf.com wrote: >> > >> > >> > The output is as below. This was without Run As Administrator - with >> > it the Group 0 Sid changed to S-1-16-12288/High Mandatory Level, which >> > *seems* appropriate >> >> It is. Thanks for this test, the result is as horrifying as I imagined. >> Can you please try the testcase attached to this mail, too? It should >> be built and run the same way: >> >> $ gcc -g -o azure-check2 azure-check2.c -lnetapi32 >> $ ./azure-check2 > > Pleae use the one attached in this mail. I noticed I forgot to print > primary group info. It's not unimportant to see it as well. > Here it is: Unknown+User@Lenovo-PC /cygdrive/c/cygwin64 $ ./azure-check2 Sid: S-1-12-1-2043906341-1249388050-2635137163-399631282 Dom\Name: AzureAD\RussellMora Primary Group: Sid: S-1-12-1-2043906341-1249388050-2635137163-399631282 Dom\Name: AzureAD\RussellMora NetUserGetInfo: 53 Unknown+User@Lenovo-PC /cygdrive/c/cygwin64 $ (As an aside, I assume that the fact that the permissions on the compiled executable are totally messed up, and thus the executable won't run until I fix them via Windows, is incidental to the fact that I am running under "Unknown+User" and thus you don't want any information on that as well.) Cheers, Russell. -- 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
[ANNOUNCEMENT] adwaita-qt 0.4-1
The following packages have been uploaded to the Cygwin distribution: * adwaita-qt4-0.4-1 * adwaita-qt5-0.4-1 * adwaita-qt-common-0.4-1 A native style to bend Qt4 and Qt5 applications to look like they belong into the GNOME desktop. -- 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
[ANNOUNCEMENT] qt5-qgnomeplatform 0.2-0.1.git20160718
The following packages have been uploaded to the Cygwin distribution: * qt5-qgnomeplatform-0.2-0.1.git20160718 QGnomePlatform is a Qt Platform Theme aimed to accommodate as much of GNOME settings as possible and utilize them in Qt applications without modifying them - making them fit into the environment as well as possible. -- 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
[ANNOUNCEMENT] qt5ct 0.24-1
The following packages have been uploaded to the Cygwin distribution: * qt5ct-0.24-1 This program allows users to configure Qt5 settings (theme, font, icons, etc.) under DE/WM without Qt integration. Note that in order to use it, QT_QPA_PLATFORMTHEME=qt5ct must be set in the environment. -- 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
[ANNOUNCEMENT] gstreamer0.10-plugins-bad-free 0.10.23-9
The following packages have been uploaded to the Cygwin distribution: * gstreamer0.10-plugins-bad-free-0.10.23-9 * gstreamer0.10-plugins-bad-free-extras-0.10.23-9 * gstreamer0.10-plugins-bad-doc-0.10.23-9 * libgstbad0.10_23-0.10.23-9 * libgstbad0.10-devel-0.10.23-9 * mingw64-i686-gstreamer0.10-plugins-bad-free-0.10.23-2 * mingw64-x86_64-gstreamer0.10-plugins-bad-free-0.10.23-2 GStreamer Bad Plug-ins is a set of plug-ins that aren't up to par compared to the rest. They might be close to being good quality, but they're missing something - be it a good code review, some documentation, a set of tests, a real live maintainer, or some actual wide use. This release has been rebuilt for libvpx-1.5.0. -- 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
[ANNOUNCEMENT] libdbusmenu-qt 0.9.3-0.2.20150604bzr
The following packages have been uploaded to the Cygwin distribution: * libdbusmenu-qt2-0.9.3-0.2.20150604bzr * libdbusmenu-qt-devel-0.9.3-0.2.20150604bzr * libdbusmenu-qt-doc-0.9.3-0.2.20150604bzr * libdbusmenu-qt5_2-0.9.3-0.2.20150604bzr * libdbusmenu-qt5-devel-0.9.3-0.2.20150604bzr * mingw64-i686-libdbusmenu-qt-0.9.3-0.2.20150604bzr * mingw64-i686-libdbusmenu-qt5-0.9.3-0.2.20150604bzr * mingw64-x86_64-libdbusmenu-qt-0.9.3-0.2.20150604bzr * mingw64-x86_64-libdbusmenu-qt5-0.9.3-0.2.20150604bzr This library provides a Qt implementation of the DBusMenu protocol. The DBusMenu protocol makes it possible for applications to export and import their menus over DBus. This is an update to a more recent snapshot for both Qt4 and Qt5. -- 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
[ANNOUNCEMENT] gstreamer1.0-plugins-good 1.6.4-2
The following packages have been uploaded to the Cygwin distribution: * gstreamer1.0-plugins-good-1.6.4-2 * gstreamer1.0-plugins-good-extras-1.6.4-2 * gstreamer1.0-plugins-good-doc-1.6.4-2 * mingw64-i686-gstreamer1.0-plugins-good-1.6.4-2 * mingw64-i686-gstreamer1.0-plugins-good-extras-1.6.4-2 * mingw64-x86_64-gstreamer1.0-plugins-good-1.6.4-2 * mingw64-x86_64-gstreamer1.0-plugins-good-extras-1.6.4-2 GStreamer Good Plug-ins is a set of plug-ins that are consider to have good quality code, correct functionality, and a preferred license (LGPL for the plug-in code, LGPL or LGPL-compatible for the supporting library). This release has been rebuilt for libvpx-1.5.0. -- 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
[ANNOUNCEMENT] desktop-file-utils 0.23-1
The following packages have been uploaded to the Cygwin distribution: * desktop-file-utils-0.23-1 This package includes utilities for manipulating desktop files. This is an update to the latest upstream release: https://lists.freedesktop.org/archives/ftp-release/2016-June/000708.html -- 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
[ANNOUNCEMENT] curl 7.50.1-1
The following packages have been uploaded to the Cygwin distribution: * curl-7.50.1-1 * libcurl4-7.50.1-1 * libcurl-devel-7.50.1-1 * libcurl-doc-7.50.1-1 * mingw64-i686-curl-7.50.1-1 * mingw64-x86_64-curl-7.50.1-1 curl is a command line tool and library for transferring files with URL syntax, supporting FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, and FILE. curl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload, proxies, cookies, user+password authentication (Basic, Digest, NTLM, Negotiate...), file transfer resume, proxy tunneling and a busload of other useful tricks. This is an update to the latest upstream release, which includes fixes for three security issues among other fixes: https://curl.haxx.se/changes.html#7_50_1 https://curl.haxx.se/docs/adv_20160803A.html https://curl.haxx.se/docs/adv_20160803B.html https://curl.haxx.se/docs/adv_20160803C.html -- 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
[ANNOUNCEMENT] lighttpd 1.4.41-1
The following packages have been uploaded to the Cygwin distribution: * lighttpd-1.4.41-1 Security, speed, compliance, and flexibility -- all of these describe lighttpd which is rapidly redefining efficiency of a webserver; as it is designed and optimized for high performance environments. With a small memory footprint compared to other web-servers, effective management of the cpu-load, and advanced feature set, lighttpd is the perfect solution for every server that is suffering load problems. This is an update to the latest upstream release, with numerous bug fixes: https://www.lighttpd.net/2016/7/16/1.4.40/ https://www.lighttpd.net/2016/7/31/1.4.41/ -- 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
PATHEXT is fundamental to Windows and Should be recognised by CYGWIN
The CYGWIN site makes it quite difficult to discern how somebody can report an issue or comment. In any event, I subscribed to the cygwin mailing list and am replying to one of the many links sent to me in case this happens to be a way to comment. Problem 1: Cygwin does not support PATHEXT and really should. Fundamental reason: from the Cygwin FAQ - What is it? "Cygwin is a distribution of popular GNU and other Open Source tools running on Microsoft Windows." PATHEXT is as fundamental component of Windows program execution as PATH. Without using extensions, bash can use execution privileges to determine if a file is executable. However, that does not work when invoking a command from CMD. This means that when invoked from BASH, you name a command "ZOT" but "ZOT.sh" (or similar) if invoked from CMD. The published solutions in the various FAQs are not satisfactory. Creating links between ZOT.sh and ZOT creates substantial overhead. If CYGWIN really intends to support Windows it should support its fundamental execution framework. It should be equally easy to invoke a bash script from a bash script or a CMD script. (This is not insurmountable as the MKS toolkit has supported this for decades.) Problem 2: Cygwin does not support CR-LF delimiters. For the same reason, it is unfortunate that CYGWIN/bash does not cope with both types of line delimiters transparently. I have been using and developing system software within Unix since 1974 and Windows since the mid-80's. in more recent years (since the mid-90's) I have developed extensive sets of tools (sh/awk/etc..) for corporate and public sector clients - on the order of 100,000 lines of code for representative projects. Most had to run under both Solaris and Windows environments for which I used the MKS toolkit. Michel LaBarre -- 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: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN
On 03.08.2016 18:43, Michel LaBarre wrote: Problem 1: Cygwin does not support PATHEXT and really should. A casual websearch shows that this topic has come up before. For instance, someone posted, some decade ago, to the Cygwin mailing list, a patch against GNU Bash to make its command search algorithm take PATHEXT into account. Fundamental reason: from the Cygwin FAQ - What is it? "Cygwin is a distribution of popular GNU and other Open Source tools running on Microsoft Windows." PATHEXT is as fundamental component of Windows program execution as PATH. I can't find any reference anywhere to PATHEXT being used outside of the CMD.EXE interpreter, which rather tends to make it substantially less than fundamental to Windows, though noteworthy. Certainly, CreateProcess does not use PATHEXT. I can't find any documentation which says that ShellExecuteEx uses PATHEXT, either. (Can anyone confirm?) Everything points to it being a CMD.EXE "gizmo". If you want to execute a command such that PATHEXT is taken into account, you have to spawn CMD.EXE /C . Cygwin provides a POSIX environment on Windows. Users of a POSIX environment don't expect a command "foo" to resolve to a file "foo.bat". If they want to run "foo.bat" they use "foo.bat". Without using extensions, bash can use execution privileges to determine if a file is executable. However, that does not work when invoking a command from CMD. What does not work from CMD is Microsoft's problem, not Cygwin's. Yes, even though you have a "myscript.sh" and you do "chmod a+x myscript.sh" inside Cygwin, the outside Windows world doesn't agree that myscript.sh is now executable, and that it uses /bin/sh by default as its interpreter, if a #! line is absent, otherwise the interpreter nominated by the #! line. Adding ".sh" to PATHEXT might work in causing CMD.EXE to resolve "myscript" to "myscript.sh"; however, it will not then successfully execute "myscript.sh", because the underlying CreateProcess API will not find it executable. CMD.EXE will probably *try* to execute it, and fail. This means that when invoked from BASH, you name a command "ZOT" but "ZOT.sh" (or similar) if invoked from CMD. From CMD, you have do something explicit like this: C:\Cygwin\bin\bash C:\Path\to\zot.sh That is, you have to run Bash, and pass it the script as an argument. Windows and CMD.EXE will not associate .sh with Bash and certainly won't look at any #! line you may have in the script. Not supporting arbitrary interpreters for scripts is a Windows problem/limitation. Cygwin overcomes that limitation within its "garden". If you solve the entry point problem of how to invoke Cygwin code from the outside, once you are in Cygwin land, you have no further problems. Scripts marked executable and containing #! use their respective interpreters and so on. The published solutions in the various FAQs are not satisfactory. Creating links between ZOT.sh and ZOT creates substantial overhead. I don't think that will work, unless by "creating a link" you mean that you create a ZOT.BAT file shim which invokes the neighboring ZOT.sh by passing its full path to bash.exe. If CYGWIN really intends to support Windows it should support its fundamental execution framework. It should be equally easy to invoke a bash script from a bash script or a CMD script. What you need on Windows is a script-to-EXE application deployment tool, which takes your "script.sh" and combines it with a copy of a special binary executable, and writes out the combination to "script.exe". Then even a raw CreateProcess Win32 API call can invoke "script.exe". Problem 2: Cygwin does not support CR-LF delimiters. For the same reason, it is unfortunate that CYGWIN/bash does not cope with both types of line delimiters transparently. The way Cygwin deals with CR/LF has evolved over time, and there are various ways to deal with this, depending on the specific situation. Firstly, the binary mode default treatment for files comes from the mount table: $ mount C:/Cygwin/bin on /usr/bin type ntfs (binary,auto) C:/Cygwin/lib on /usr/lib type ntfs (binary,auto) C:/Cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) See how that /cygdrive/c is mounted "binary" (as is everything else?) That's what causes text files to be treated as LF rather than CR/LF. That can be altered; you can mount some Windows path into Cygwin's POSIX file system view as text, and then CR/LF conversion is done. Then, secondly, there are approaches for individual C programs. If you're porting something written in C, the C library in Cygwin supports the "t" flag in fopen and related functions. This is similar to the Microsoft extension, found in the Visual C run-time library. In ISO C, if you omit the "b" mode, then a file is open in text mode, but on POSIX that is the same as binary mode. In Cygwin, if you specify "t", you get the Windows text mode, CR/LF.
RE: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN
Thanks for the reply Kaz. I did not embed any comments in your reply for the sake of brevity. I had seen the reference to a patch to support PATHEXT; it was dismissed pretty lightly. PATHEXT has been part of Windows for as long as I can remember - back to the mid-80's - used by shells that run under windows (e.g. CMD, PowerShell, VBS, etc.). Windows inherently uses file suffixes to associate programs to data files, hence CMD files to CMD.exe, VBS to VB, etc.. All its shells refer to PATHEXT and/or file associations in the registry. I have worked with Unix for a long time (1974) and Windows for almost as long (1986?). Because some notion does not exist in Unix is no reason for discrediting it within Windows esp in the context of a tool framework specifically catering to Windows according to its defining mission. If you have been web-searching for references to my query, surely you have found many items referring to the problem in practice. I used to move a whack of scripts between Solaris and Windows - same scripts supporting an enterprise backup product with HQ hosted on Solaris and 150 sites worldwide running Windows only. My automated port process stripped or added suffixes as necessary going between Solaris and Windows. However, once in Windows, a tool could be called from a shell script or a CMD script without regard of the suffix - the (MKS) shell worked with the suffix or not while CMD (and vbs) relied upon PATHEXT. One has to look at practical applications when deciding what is warranted. I cannot help feeling that CYGWIN's proponents give lip service to interoperability with Windows - that they would rather be running Linux in a VM in which case why bother with a Windows foundation in the first place? Other than Microsoft fearing competition, the second biggest drawback to Windows developers adopting Unix tools has been due to Unix developers wishing that Windows would go away. MKS has done a great job of working with Windows. You may recall Interix which tried to launch a product that ran isolated within the POSIX subsystem - it went nowhere - Microsoft bought the dregs of the company for no rational reason I can discern. They released a Unix environment for NT and it tanked. They are trying again with Ubuntu under Windows 10 but that will fail as well because it will be completely isolated from the Win32 environment. Windows developers need to get to Windows tools and resources - CYGWIN could be a very smart supplement to that requirement. Windows 7 with the MKS Toolkit is in fact one of the most productive environments I have used. MKS's value lays in its integration with Windows. CYGWIN's developers recognising that Windows is not a passing fad might push CYGWIN into the mainstream of Windows development. As it stands, if getting into it is a challenge for people with plenty of Unix and Windows background, it will not make much headway with pure Windows programmers. Your comment regarding " What does not work from CMD is Microsoft's problem, not Cygwin's." ignores that Cygwin is supposed to work within Windows. You penalise CYGWIN users - not Microsoft. Frankly, that comment strikes me as somewhat cavalier. You commented: "Cygwin provides a POSIX environment on Windows. Users of a POSIX environment don't expect a command "foo" to resolve to a file "foo.bat". If they want to run "foo.bat" they use "foo.bat"." I disagree completely. If you are in an interactive bash, running on a Windows computer, you sure as hell expect to be able to run "foo.bat" by typing "foo". And if you are in a script you expect to release to a large community, If "foo" comes from some 3rd party package released independently, then you don't want to be wiring into your script that "foo" is a bat, exe, vbs, cmd, or whatever in case the 3rd party package ever changes its implementation (e.g. converting a CMD to an EXE for performance reasons). I agree fully that PATHEXT is not a great mechanism - it just happens to be wired into Windows. It is a myth that Unix-y programmers work in a vacuum within Windows. Any serious software will have to exploit, hence interact with, Windows native and add-on tools. As for CR/LF, I admit that I have not mastered all the opportunities fstab might present under CYGWIN but I don't think they will apply if the bash script is invoked from a Windows environment rather than from a bash script would they. Thanks for your thoughts Kaz. I realise you are a volunteer and appreciate your efforts. Having cut my teeth on Unix, I appreciate its value however having been forced to work with Windows for so many decades, I have come to appreciate a few aspects. I just miss all the tools for day-to-day use I took for granted under Unix. If CYGWIN could mitigate some of the recurring impediments new users trip over, (as evidenced by the many web-references to both my problems) it would facilitate it
Re: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN
> On Aug 3, 2016, at 8:43 PM, Michel LaBarre wrote: > > The CYGWIN site makes it quite difficult to discern how somebody can report > an issue or comment. If you think a plainly labeled “Reporting Problems” and “Mailing Lists” in the prominent sidebar is difficult, then I’m afraid it’s only going to get worse from here. > Problem 1: Cygwin does not support PATHEXT and really should. > > Fundamental reason: from the Cygwin FAQ - What is it? "Cygwin is a > distribution of popular GNU and other Open Source tools running on Microsoft > Windows.” > PATHEXT is as fundamental component of Windows program execution as PATH. “To you.” Almost every sentence in that paragraph should have “to you” at the end. I’ve used Cygwin for over a dozen years, and I have never once missed having PATHEXT in mintty/bash. You can continue to use PATHEXT to your heart’s content in CMD. Bash isn’t CMD. > The published solutions in the various FAQs are not satisfactory. “To you." > Problem 2: Cygwin does not support CR-LF delimiters. Yes it does, although it is heartily suggested they be left behind (pretty much any Windows program can handle Unix line endings but Notepad, and anyone using Notepad has bigger issues than line endings). Text mounts can be created in Cygwin (although, again, not suggested). There are also a few (non-standard) things in Cygwin’s bash to try to handle CRLF scripts. You can search the archives for more information. > CYGWIN could be a very smart supplement to that requirement. > … > If CYGWIN could mitigate some of the recurring impediments new users trip > over, (as evidenced by the many web-references to both my problems) it would > facilitate its adoption by both Unix and non-Unix types. No, Cygwin _is_ a very smart supplement to that requirement. You talk as if Cygwin just showed up last week. It’s been around for almost twenty years, is widely used and widely respected. > I disagree completely. If you are in an interactive bash, running on a > Windows computer, you sure as hell expect to be able to run "foo.bat" by > typing "foo”. No, _you_ expect to. I don’t. I know that Bash isn’t CMD. Cygwin is providing a Posix environment on Windows. If you want a Windows environment on Windows, then use CMD. Almost all of Cygwin’s supplied programs work perfectly well in CMD, as long as you remember they’re providing a Posix environment and therefore need Unix paths, etc. -- 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: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN
On 3 August 2016 at 22:30, Michel LaBarre wrote: > ... > > PATHEXT has been part of Windows for as long as I can remember - back to > the mid-80's - used by shells that run under windows > First, this discussion is more appropriate for cygwin-talk than this list. Second, PATHEXT is an attempt to carry the concept of default behavior (based on its extension) for a file in the graphics window world, into the command line world. That default behavior is hidden away in the registry where normal users fear to tread and experts tread with care. That default behavior is subject to the whims of the most recently installed program than thinks it knows what the user wants to do with a file with a particular extension. The default behavior of a newly installed version of windows is to hide the extension, and only show an icon in the explorer, where (again) the icon depends on the most recently installed program than thought it knew what icon should go with that file extension. And that icon to extension mapping does not guarantee or require a unique icon for each extension, so, unless you dig through the registry you have no way of knowing, in advance, what will happen when you double click that file. And any knowledge you gained from experience may get changed by the next program you install, without your knowledge or permission. A couple of examples: I work with Oracle databases, so 90% of my .sql files are Oracle scripts and PL/SQL. I had to install MSSQL for some reason, and suddenly an accidental double click on an .sql file was opening some huge slow Microsoft tool instead of SQL Developer. It was an annoying fiddle to restore useful behavior. I use Python a lot. I have 7 versions (of Python, 5 for Win, 2 for cygwin, plus Jython and IronPython) installed right now, so I need to pick my environment for each .py file, or for my current project. I had to install Visual Studio and a Python plugin for it. VS hijacked my .py files, ignores #! lines, and takes forever to load and open an editor window. Now though, double clicked a .py file or entering its name (with or without the extension) at the command prompt opens it in a fast and useful text editor. To summarize, I don't think PATHEXT is such a great feature of the command prompt that it needs to be emulated in cygwin. If I have gone to the trouble of typing "./name_of_file", (you don't have "." in your PATH do you?) it's no big effort to hit TAB (for command completion) and fill in the explicit extension. And if I'm writing a script, I'm a fool if I don't include the extension. And BTW, I set CYGWIN_NOWINPATH=1 from the control panel so I can't accidentally run a windows program when I meant to run a cygwin one. Doug -- Doug Henderson, Calgary, Alberta, Canada -- 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
