sed 4.2.1-1 locks files on windows
see here: http://stackoverflow.com/questions/9368783/cygwin-bash-sed-locks-my-files When I change files in cygwin bash with the sed command, the file gets locked. Reproduce: Open cmd and cd to non-user directory (f.e. temp) echo aaa > test.txt Open in texteditor, add line, try to save => works %CYGWIN_HOME%\bin\bash -c "sed -i 's/aaa/bbb/' test.txt In texteditor, add another line and try to save => "Access denied" -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://www.gmx.net/de/go/freephone/ -- 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
1.16-1.18´©Ô½Õã½¹ÅÌïÖÁ½Î÷æÄÔ´
浙江古田至江西婺源 活动难度：轻松 时间安排：星期五--星期日（星期五下午19:27出发-星期日23:00到上海） 活动路线：上海―衢州--浙江古田―石耳山―江西鹜源―杭州--上海 活动目的：两天到婺源的最佳路线,走过浙江的古田山自然保护区到位开发的婺源晓鳙村 行程安排： D1 19:27上海―衢州火车 23:49到达衢州,晚宿衢州市 07:30出发往苏庄镇(那里的豆腐很香) 10:30抵达苏庄镇吃饭采购补给 12:00抵达平坑村（穿越的起点） 16:00行走到龙上村（穿越途中的营地） D2 08:00出发爬山(石耳山海拔1200米左右) 12:00登顶石耳山(可以看到对面的三清山) 13:00午饭后出发下山 14:00到达江西鹜源的晓鳙乡(很多保村完好的微派古民居) 18:30晚宿晓鳙村 D3 08:00到江湾古镇看看新旧更替 11:00午饭(古街,古桥,水渠,人家) 12:00回上海的长途车 23:00到上海 费用产生：（由于时间原因，可能会有所变动） 乘坐上海→衢州的快速火车 全程票价70元/人(按实际票价) 衢州→平坑,包车 80元/人 婺源→上海 长途汽车130元/人 活动费用：300元/人 会员基金：30元/人 装备租赁：免费 强制保险：8元/人 http://www.han-ma.com/bbs/dispbbs.asp?boardID=32&ID=1873 --- 客户挖掘大师 http://www.i-miner.com 一边根据关键词搜集电子邮件地址一边发送电子邮件的网络营销利器 --- CustomerDigger http://www.webrobber.com Sending e-mails while collecting e-mail addresses by keywords ---
Re: Urgent gcc update to GCC 13.3
On Sat, Jul 06, 2024 at 09:53:00PM +0200, Mark Liam Brown via Cygwin wrote: > Greetings! > > Cygwin gcc is currently stuck at version 11.4: > $ gcc --version > gcc (GCC) 11.4.0 > > I would politely request an urgent update to GCC 13.3 (not 14.1, 13.3 > is considered mature), as 11.4 causes severe problems: > 1. Securly updates in the STL are not available in Cygwin > 2. Everything relying on C++17, e.g. std::pmr::polymorphic_allocator, > does not work > 3. Qt6 is not portable to Cygwin, which has a severe impact > > Mark > -- > IT Infrastructure Consultant > Windows, Linux Greetings, Mark. I take umbrage with excessive use of adjectives such as "urgent" and "severe" when neither applies generically, and detailed context is largely absent. The subject line: "Urgent gcc update to GCC 13.3" is obnoxious, IMNSHO. The gcc version in cygwin is not "sudden" news. Why is this "urgent"? What is this "severe impact" that someone "must" run qt6? If some commercial product "needs" to run on Cygwin, apparently someone failed to test on Cygwin during development and QA. If this is "urgent" and "severe", then are you offering expert help and/or offering to pay one of the cygwin volunteers to act in an "urgent" manner to address this? Prior to posting, have you looked at the list archives to see prior discussions of the hurdles involved in updating the compiler? I politely request that you please "urgently" adjust your expectations. Cygwin largely exists through the time and effort of volunteers. I am but one volunteer who maintains one package, and I speak only for myself. Cheers, Glenn -- 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: Parse output of "net use", but language varies - force language for "net use"?
On Sat, Jul 20, 2024 at 04:56:56PM +0200, Mark Liam Brown via Cygwin wrote: > On Sat, Jul 20, 2024 at 4:31 PM Bill Stewart via Cygwin > wrote: > > > > On Sat, Jul 20, 2024 at 7:45 AM Mark Liam Brown via Cygwin wrote: > > > > I am trying to parse the output of "net use" in a bash script, but hit > > > a roadblock: > > > The output of "net use" changes with the language of the system > > > (English, Danish, French, ...), so parsing becomes nearly impossible > > > > > > How can I force the language used by "net use" to English, even if the > > > system default language is Danish or French? > > > > > > > This sounds like an XY problem[1] to me > > > > What is the goal you're trying to accomplish? Enumerate existing > > connections? Get drive mappings? > > Basically I need every bit of information out of "net use", "net > config", "net statistics", "net view" and so on, parse it in bash or > perl, process it in bash, and output it in JSON format from the bash > script for our (Linux-based) admin report interface. > > Mark > -- > IT Infrastructure Consultant > Windows, Linux Hello Mr Consultant. You seem to have a NIH syndrome that you are approaching your problem as if you are the first person to ever do this, and therefore you are writing everything yourself, from scratch. Do you honestly think you are the first person who would like the info displayed by 'net use' in some form of structured data? Using Powershell and its formatting options, as posted in Henry's response, is probably the best answer *for scripting*. If using Perl *for scripting*, there are numerous Perl modules such as https://metacpan.org/pod/Win32::NetResource If you were to try using a search engine more effectively, you might also find C++ libraries or C# APIs to access all that info as structured data, instead of trying to parse the `net use` command line output using bash, and trying to fight with the registry settings to affect `net use` display of the data. -- 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
open /dev/null O_NOFOLLOW fails with ELOOP
open /dev/null O_NOFOLLOW fails with ELOOP
Windows 10, 64-bit cygwin
Failed with my existing install, then I ran setup.exe, updated to
latest, and my tests still failed.
a.c
---
#include
#include
#include
int main (void)
{
int fd = open("/dev/null", O_RDWR | O_NOFOLLOW, 0);
if (fd < 0)
perror("open(/dev/null)");
return fd;
}
$ gcc a.c ; ./a.exe
open(/dev/null): Too many levels of symbolic links
While troubleshooting this, there were times where it succeeded and then
times where it failed, though it failed most of the time. It did not
fail (or succeed) randomly, but seemingly in streaks.
Trying to start lighttpd seems to run into this bug reliably,
$ /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
In the next release of lighttpd, I may end up omitting O_NOFOLLOW
if __CYGWIN__ is defined.
Cheers, Glenn
--
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: open /dev/null O_NOFOLLOW fails with ELOOP
On Wed, Dec 21, 2022 at 03:29:42PM +0100, Corinna Vinschen via Cygwin wrote:
> Hi Glenn,
>
> On Dec 21 12:31, Corinna Vinschen via Cygwin wrote:
> > On Dec 21 06:15, gs-cygwin.com--- via Cygwin wrote:
> > > open /dev/null O_NOFOLLOW fails with ELOOP
> > >
> > > Windows 10, 64-bit cygwin
> > >
> > > Failed with my existing install, then I ran setup.exe, updated to
> > > latest, and my tests still failed.
> > >
> > > a.c
> > > ---
> > >
> > > #include
> > > #include
> > > #include
> > >
> > > int main (void)
> > > {
> > > int fd = open("/dev/null", O_RDWR | O_NOFOLLOW, 0);
> > > if (fd < 0)
> > > perror("open(/dev/null)");
> > > return fd;
> > > }
> > >
> > >
> > > $ gcc a.c ; ./a.exe
> > > open(/dev/null): Too many levels of symbolic links
> > >
> > > While troubleshooting this, there were times where it succeeded and then
> > > times where it failed, though it failed most of the time. It did not
> > > fail (or succeed) randomly, but seemingly in streaks.
> > >
> > > Trying to start lighttpd seems to run into this bug reliably,
> > > $ /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
> > > In the next release of lighttpd, I may end up omitting O_NOFOLLOW
> > > if __CYGWIN__ is defined.
> >
> > Thanks for the report. I think I see what's going on, stay tuned.
>
> I pushed a patch:
> https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=09cb4cd2940f
>
> Please try the latest test release cygwin-3.5.0-0.60.g09cb4cd2940f.
> For installation, see https://cygwin.com/faq.html#faq.setup.testrels
>
>
> Thanks,
> Corinna
cygwin-3.5.0-0.60.g09cb4cd2940f works for my test case and for lighttpd.
I was unable to reproduce the problem after (somewhat limited) testing
with the test version.
When I reverted back to 3.4.3-1, I was immediately able to reproduce the
issue with 3.4.3-1.
Thank you! Happy Holidays!
Cheers, Glenn
--
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: Question about slow access to file information
On Sun, Jan 15, 2023 at 12:05:10PM +1100, Eliot Moss via Cygwin wrote: > On 1/15/2023 3:38 AM, Christian Franke via Cygwin wrote: > > Eliot Moss via Cygwin wrote: > > > I have a separate drive mounted this way: > > > > > > d:/ /cygdrive/d ntfs binary,posix=0,user,noacl,auto 0 0 > > > > > > One thing I use it for is to store backup files. These tend to be 2 Gb > > > chunks, and there can be hundreds of them in the backup directory. (The > > > drive > > > is 5Tb.) The Windows Disk Management tool describes it as NTFS, Basic > > > Data > > > Partition. > > > > > > Doing ls (for example) takes a very perceptible numbers of seconds (though > > > whatever takes a long time seems to be cached, at least for a while, > > > since a > > > second ls soon after is fast). > > > > The problem is the 'noacl' mount option and the fact that POSIX only > > offers the *stat*() functions to retrieve file information. These > > functions always need to provide the full file information, even if only > > a small subset is needed. > > > > To determine the 'x'-permission bits in the 'stat.st_mode' field on a > > 'noacl'-mount, Cygwin reads the first bytes of most files (all except > > *.exe, *.lnk, *.com). The 'x' bits are set if the file starts with "#!" > > (script), ":\n" (?) or "MZ" (Windows executable). > > > > On 'noacl' mounts, this behavior could be suppressed by 'exec' or 'noexec' > > mount options. > > Interesting. I removed the noacl from /etc/fstab and restarted all Cygwin > processes. > The mount program now shows that drive without noacl. It still takes > surprisingly > long to ls if I have not done so recently. The directory contains ~1200 > files. > > Further thoughts? Does this make any difference? $ env - LANG=C ls -f /cygdrive/d/ Also, ISTR prior mailing list postings on how cygwin may open() each file to determine some info, and that can be expensive. Is that what is happening if you trace the 'ls'? Cheers, Glenn -- 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: [FEEDBACK] Issue with fd_set, FD_ZERO, FD_SET, FD_SETSIZE : Cygwin
On Tue, Feb 07, 2023 at 04:25:22AM +0800, Yeo Kai Wei via Cygwin wrote:
> Hi,
>
> I would like to report an issue with Cygwin 3.4.2 on Windows.
>
> It doesn't seem to be able to work with fd_set, FD_ZERO, FD_SET, FD_SETSIZE
> macros.
>
> The code is in italics. The filename was selectStdIn.c. The terminal command
> used was "gcc -o selectStdIn selectStdIn.c"
>
> Thank you.
>
> /
> /
>
> /CODE
> /
>
> /#include //
> //#include //
> //#include //
> //#include //
> / /
> //void main()//
> //{//
> // fd_set fds; //set of file descriptors//
> / /
> // struct timeval tv;//
> / /
> // int flag;//
> / /
> // char byte;//
> / /
> // FD_ZERO(&fds);//
> / /
> // FD_SET(0, &fds);//
> / /
> // tv.tv_sec = 5;//
> / /
> // tv.tv_usec = 0;//
> / /
> // flag = select(FD_SETSIZE, //
> // &fds,//
> // NULL,//
> // NULL,//
> // &tv);//
> / /
> // if(-1 == flag)//
> // perror("select error");//
> // else if(flag)//
> // {//
> // read(0,&byte,1);//
> / /
> // puts("data read");//
> // }//
> / /
> // if(flag)//
> // printf("The byte value is %c\n", byte);//
>
> //}/
>
>
> TERMINAL COMMANDS
>
> $ gcc -o selectStdIn selectStdIn.c
> selectStdIn.c: In function 'main':
> selectStdIn.c:8:2: error: unknown type name 'fd_set'; did you mean 'fpos_t'?
> fd_set fds; //set of file descriptors
> ^~
> fpos_t
> selectStdIn.c:16:2: warning: implicit declaration of function 'FD_ZERO'
> [-Wimpli
> cit-function-declaration]
> FD_ZERO(&fds);
> ^~~
> selectStdIn.c:18:2: warning: implicit declaration of function 'FD_SET'
> [-Wimplic
> it-function-declaration]
> FD_SET(0, &fds);
> ^~
> selectStdIn.c:24:9: warning: implicit declaration of function 'select'; did
> you
> mean 'sleep'? [-Wimplicit-function-declaration]
> flag = select(FD_SETSIZE,
> ^~
> sleep
> selectStdIn.c:24:16: error: 'FD_SETSIZE' undeclared (first use in this
> function)
> flag = select(FD_SETSIZE,
> ^~
> selectStdIn.c:24:16: note: each undeclared identifier is reported only once
> for
> each function it appears in
$ man select
#include
--
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: [FEEDBACK] Issue with fd_set, FD_ZERO, FD_SET, FD_SETSIZE : Cygwin
On Tue, Feb 07, 2023 at 04:33:53AM +0800, Yeo Kai Wei wrote:
> Hi All,
>
> Thanks for the help.
>
> I tried adding "#include ".
>
> However, this is the error message that was returned to me.
>
> $ gcc -o selectStdIn selectStdIn.c
> selectStdIn.c:9:10: fatal error: sys/select.h: No such file or directory
> #include
>
> Thank you.
>
> On 7/2/2023 4:30 am, gs-cygwin@gluelogic.com wrote:
> > On Tue, Feb 07, 2023 at 04:25:22AM +0800, Yeo Kai Wei via Cygwin wrote:
> > > Hi,
> > >
> > > I would like to report an issue with Cygwin 3.4.2 on Windows.
> > >
> > > It doesn't seem to be able to work with fd_set, FD_ZERO, FD_SET,
> > > FD_SETSIZE
> > > macros.
> > >
> > > The code is in italics. The filename was selectStdIn.c. The terminal
> > > command
> > > used was "gcc -o selectStdIn selectStdIn.c"
> > >
> > > Thank you.
> > >
> > > /
> > > /
> > >
> > > /CODE
> > > /
> > >
> > > /#include //
> > > //#include //
> > > //#include //
> > > //#include //
> > > / /
> > > //void main()//
> > > //{//
> > > // fd_set fds; //set of file descriptors//
> > > / /
> > > // struct timeval tv;//
> > > / /
> > > // int flag;//
> > > / /
> > > // char byte;//
> > > / /
> > > // FD_ZERO(&fds);//
> > > / /
> > > // FD_SET(0, &fds);//
> > > / /
> > > // tv.tv_sec = 5;//
> > > / /
> > > // tv.tv_usec = 0;//
> > > / /
> > > // flag = select(FD_SETSIZE, //
> > > // &fds,//
> > > // NULL,//
> > > // NULL,//
> > > // &tv);//
> > > / /
> > > // if(-1 == flag)//
> > > // perror("select error");//
> > > // else if(flag)//
> > > // {//
> > > // read(0,&byte,1);//
> > > / /
> > > // puts("data read");//
> > > // }//
> > > / /
> > > // if(flag)//
> > > // printf("The byte value is %c\n", byte);//
> > >
> > > //}/
> > >
> > >
> > > TERMINAL COMMANDS
> > >
> > > $ gcc -o selectStdIn selectStdIn.c
> > > selectStdIn.c: In function 'main':
> > > selectStdIn.c:8:2: error: unknown type name 'fd_set'; did you mean
> > > 'fpos_t'?
> > > fd_set fds; //set of file descriptors
> > > ^~
> > > fpos_t
> > > selectStdIn.c:16:2: warning: implicit declaration of function 'FD_ZERO'
> > > [-Wimpli
> > > cit-function-declaration]
> > > FD_ZERO(&fds);
> > > ^~~
> > > selectStdIn.c:18:2: warning: implicit declaration of function 'FD_SET'
> > > [-Wimplic
> > > it-function-declaration]
> > > FD_SET(0, &fds);
> > > ^~
> > > selectStdIn.c:24:9: warning: implicit declaration of function 'select';
> > > did
> > > you
> > > mean 'sleep'? [-Wimplicit-function-declaration]
> > > flag = select(FD_SETSIZE,
> > > ^~
> > > sleep
> > > selectStdIn.c:24:16: error: 'FD_SETSIZE' undeclared (first use in this
> > > function)
> > > flag = select(FD_SETSIZE,
> > > ^~
> > > selectStdIn.c:24:16: note: each undeclared identifier is reported only
> > > once
> > > for
> > > each function it appears in
> > $ man select
> >
> > #include
Please post at bottom of messages on this mailing list.
You need to install the cygwin-devel package to get
Cheers, Glenn
--
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: [FEEDBACK] Issue with fd_set, FD_ZERO, FD_SET, FD_SETSIZE : Cygwin
dIn.c:24:16: error: 'FD_SETSIZE' undeclared (first use in this > > > > > function) > > > > > flag = select(FD_SETSIZE, > > > > > ^~~~~~ > > > > > selectStdIn.c:24:16: note: each undeclared identifier is reported > > > > > only once > > > > > for > > > > > each function it appears in > > > > $ man select > > > > > > > > #include > > Please post at bottom of messages on this mailing list. > > > > You need to install the cygwin-devel package to get > > > > Cheers, Glenn > > Hi All, > > I updated Cygwin to 3.4.5-1.x86_64. > > $ uname -a > CYGWIN_NT-10.0-19045 DESKTOP-P3E71RB 3.4.5-1.x86_64 2023-01-19 19:09 UTC > x86_64 Cygwin > > > However, the same problem occurs. > > Cygwn-devel doesn't seem to work. > > $ gcc -o selectStdIn selectStdIn.c > selectStdIn.c:9:10: fatal error: sys/select.h: No such file or directory > #include > ^~ > compilation terminated. https://www.cygwin.com/packages/x86_64/cygwin-devel/cygwin-devel-3.4.5-1 /usr/include/sys/select.h is included in the cygwin-devel package. Did you install the cygwin-devel package? Does /usr/include/sys/select.h exist in your cygwin environment? Perhaps you accidentally have multiple cygwin installations on your system and you installed cygwin-devel into a different location? Since you did not have the cygwin-devel package installed on your system, you are likely very new to developing on cygwin. You also seem to be very new to cygwin and installing cygwin packages. You may want to spend more time reading the available documentation on how to use cygwin and develop on cygwin, as you seem to be having trouble with some very elementary steps. https://www.cygwin.com/ The documentation is very good. Please read through it. (This is my way of saying I won't be responding further to this thread.) Cheers, Glenn -- 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: posix_spawn facility
On Mon, Apr 17, 2023 at 08:44:51PM +0200, Bruno Haible via Cygwin wrote:
> Btw, there are two more functions in the posix_spawn family meanwhile:
> * posix_spawn_file_actions_addchdir_np
> implemented by glibc [1], musl libc, macOS, FreeBSD [2], Solaris ≥ 11.3
> used by a few packages (Firefox, Chromium, Rust)
> * posix_spawn_file_actions_addfchdir_np
> implemented in glibc, musl libc
> but not used by any package so far [3].
>
> The next POSIX will contain these functions (without the _np suffix).[4]
>
> Bruno
>
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=17405
> [2]
> https://man.freebsd.org/cgi/man.cgi?query=posix_spawn_file_actions_adddup2&apropos=0&sektion=3&manpath=FreeBSD+11-current&format=html
> [3] https://codesearch.debian.net/
> [4] https://www.austingroupbugs.net/view.php?id=1208
With regards to [3] above, the next lighttpd release (lighttpd 1.4.70)
will use posix_spawn_file_actions_addfchdir_np(), where available, for
spawning CGI programs.
I have not yet tested under cygwin, but under Linux the overhead of
initial CGI process creation can be greatly reduced by using
posix_spawn() instead of fork(),execve(). The speedup is inversely
proportional to how much work the target script performs (compared to
the overhead of initial process creation). On x86_64 Linux, running a
minimal C program for CGI can be ~60% faster in lighttpd when using
posix_spawn()! When running a minimal /bin/sh program for CGI, the
speedup is "only" ~20%! (Those numbers were obtained from running
h2load and weighttp microbenchmarks with the minimal CGI programs.)
minimal C program for CGI (compiled gcc -O3):
#include
static const char resp[] = "Status: 200\n\n";
int main(void) { write(STDOUT_FILENO, resp, sizeof(resp)-1); return 0; }
minimal /bin/sh program for CGI:
#!/bin/sh
printf 'Status: 200\n\n'
Cheers, Glenn
--
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: posix_spawn facility
On Thu, Apr 20, 2023 at 04:40:52PM +0200, Corinna Vinschen via Cygwin wrote: > On Apr 20 16:21, Corinna Vinschen via Cygwin wrote: > > On Apr 20 12:18, Bruno Haible via Cygwin wrote: > > > The "inheritable handles" is a data structure that allows for the > > > arbitrary reshuffling of file descriptors required by posix_spawn > > > (the addopen, adddup2, addclose actions), i.e. which does the book- > > > keeping which HANDLE must in the end be open in the parent and which > > > must in the end be open in the child, and at which position. > > > > Hmm. Your code uses lpReserved2 for that, but the functionality is > > one implemented in MSVCRT. For obvious reasons, Cygwin executables > > are not linked against msvcrt.dll and we're using lpReserved2 for our > > own purposes. > > Oh, btw., did you know that there's a newer mechanism for defining > specific inheritable handles to CreateProcess, which is implemented > in kernel32.dll, so it does not depend on MSVCRT? > > There's a STARTUPINFOEX structure which allows to specify the > additional handles. See > > https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexa > > and the PROC_THREAD_ATTRIBUTE_HANDLE_LIST argument described in > > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute An example using these to run CGI programs in lighttpd on Windows using native _WIN32 code can be seen on my dev branch (intended for lighttpd 1.4.70). https://git.lighttpd.net/lighttpd/lighttpd1.4/src/branch/personal/gstrauss/master/src/fdevent_win32.c#L539 (lighttpd is BSD-3-Clause) The aim is to securely manage which handles are inherited by child CGI processes. Elsewhere, lighttpd clears HANDLE_FLAG_INHERIT on handles lighttpd creates, and uses WSA_FLAG_NO_HANDLE_INHERIT in calls to WSASocket() func family. Also in that file, I have an (expensive) socketpair() implementation, since lighttpd uses sockets instead of pipes to connect to CGI programs, so that events can be received using WSAPoll() or select(). To get things working in native _WIN32 lighttpd, which has a test framework that runs under Cygwin, I had to detect and perform some path translation between native Windows and Cygwin paths. While my solution is specific to lighttpd's use, I hope that this may give you some ideas. Cheers, Glenn -- 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: posix_spawn facility
On Thu, Apr 20, 2023 at 04:58:20PM +0200, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > > Hmm. Your code uses lpReserved2 for that, but the functionality is > > > one implemented in MSVCRT. For obvious reasons, Cygwin executables > > > are not linked against msvcrt.dll and we're using lpReserved2 for our > > > own purposes. > > > > Oh, btw., did you know that there's a newer mechanism for defining > > specific inheritable handles to CreateProcess, which is implemented > > in kernel32.dll, so it does not depend on MSVCRT? > > > > There's a STARTUPINFOEX structure which allows to specify the > > additional handles. See > > > > https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexa > > > > and the PROC_THREAD_ATTRIBUTE_HANDLE_LIST argument described in > > > > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute > > Indeed, this appears to be a more "official" way to pass handles for fd ≥ 3, > instead of lpReserved2 — albeit without associated 'flags'. Not sure how > O_APPEND is handled then... (Note: O_APPEND behaviour is tested by > gnulib/tests/test-posix_spawn-open2.c.) > > I had seen this doc page, but thought it was irrelevant because the > title is about "thread attributes", not "process attributes"... Excellent (very technical) article on the subject: Programmatically controlling which handles are inherited by new processes in Win32 https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873 Cheers, Glenn -- 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: posix_spawn facility
On Thu, Apr 20, 2023 at 05:40:52PM +0200, Corinna Vinschen via Cygwin wrote: > On Apr 20 16:58, Bruno Haible via Cygwin wrote: > > Corinna Vinschen wrote: > > > > Hmm. Your code uses lpReserved2 for that, but the functionality is > > > > one implemented in MSVCRT. For obvious reasons, Cygwin executables > > > > are not linked against msvcrt.dll and we're using lpReserved2 for our > > > > own purposes. > > > > > > Oh, btw., did you know that there's a newer mechanism for defining > > > specific inheritable handles to CreateProcess, which is implemented > > > in kernel32.dll, so it does not depend on MSVCRT? > > > > > > There's a STARTUPINFOEX structure which allows to specify the > > > additional handles. See > > > > > > https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexa > > > > > > and the PROC_THREAD_ATTRIBUTE_HANDLE_LIST argument described in > > > > > > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute > > > > Indeed, this appears to be a more "official" way to pass handles for fd ≥ 3, > > instead of lpReserved2 — albeit without associated 'flags'. Not sure how > > O_APPEND is handled then... > > Yeah, theoretically, that should be handled by CreateFile opening the > file with FILE_APPEND_DATA attribute, and in the child MSVCRT should > test with NtQueryInformationFile(FILE_ACCESS_INFORMATION) if the > FILE_APPEND_DATA flag is set. > > But then again, if MSVCRT implements fcntl (F_SETFL) to allow > manipulating the O_APPEND flag... unfortunately there's no such > operation via Win32 or native calls. That would require to reopen the > file with different access mask and replace the HANDLE under the hood of > the descriptor. I'm not aware if and how MSVCRT performs this action. If you are carefully controlling and allowing an explicit set of file handles to be inherited, and the entire program uses this interface to create new processes, then you can safely _sopen_s() or otherwise to create new handles, pass them to CreateProcess() using STARTUPINFOEX, and then close any new handles created solely for inheritance in child. Cheers, Glenn -- 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: posix_spawn facility
On Thu, Apr 20, 2023 at 09:31:38PM +0200, Bruno Haible wrote: > Glenn wrote: > > > > https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexa > > > > > > > > and the PROC_THREAD_ATTRIBUTE_HANDLE_LIST argument described in > > > > > > > > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute > > > ... > > Excellent (very technical) article on the subject: > > > > Programmatically controlling which handles are inherited by new processes > > in Win32 > > https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873 > > It's nice to see an example for PROC_THREAD_ATTRIBUTE_HANDLE_LIST. > > But the article exaggerates a problem: > "But all this inheritability fiddling still had a fatal flaw: What >if two threads within the same process both call CreateProcess but >disagree on which handles they want to be inherited?" > The answer, overlooked in the article, is to use DuplicateHandle > and set the inheritability of the duplicate to true. Concurrently > running posix_spawn invocations in other threads will not see the > duplicates, since they only see HANDLEs that are assigned to file > descriptors, not HANDLEs that merely reside in some data structure > in memory. It might not be an issue if everything -- and I mean everything -- goes through posix_spawn() to create processes. The article is from 2011 and about Windows. If a third-party dll running in another thread calls CreateProcess() and does not explicitly restrict the inherited handles using the techiques in the article, then there is still that race that might leak additional handles into the other process. In the case of cygwin, the cygwin layer could/should be able to centralize and control process creation, avoiding the race. Even if there were any steps that need to be protected, wrapping in a CriticalSection (or mutex) would probably be sufficient. Cheers, Glenn -- 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: posix_spawn facility
On Thu, Apr 20, 2023 at 03:14:59AM -0400, gs-cygwin@gluelogic.com wrote:
> On Mon, Apr 17, 2023 at 08:44:51PM +0200, Bruno Haible via Cygwin wrote:
> > Btw, there are two more functions in the posix_spawn family meanwhile:
> > * posix_spawn_file_actions_addchdir_np
> > implemented by glibc [1], musl libc, macOS, FreeBSD [2], Solaris ≥ 11.3
> > used by a few packages (Firefox, Chromium, Rust)
> > * posix_spawn_file_actions_addfchdir_np
> > implemented in glibc, musl libc
> > but not used by any package so far [3].
> >
> > The next POSIX will contain these functions (without the _np suffix).[4]
> >
> > Bruno
> >
> > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=17405
> > [2]
> > https://man.freebsd.org/cgi/man.cgi?query=posix_spawn_file_actions_adddup2&apropos=0&sektion=3&manpath=FreeBSD+11-current&format=html
> > [3] https://codesearch.debian.net/
> > [4] https://www.austingroupbugs.net/view.php?id=1208
>
> With regards to [3] above, the next lighttpd release (lighttpd 1.4.70)
> will use posix_spawn_file_actions_addfchdir_np(), where available, for
> spawning CGI programs.
>
> I have not yet tested under cygwin, but under Linux the overhead of
> initial CGI process creation can be greatly reduced by using
> posix_spawn() instead of fork(),execve(). The speedup is inversely
> proportional to how much work the target script performs (compared to
> the overhead of initial process creation). On x86_64 Linux, running a
> minimal C program for CGI can be ~60% faster in lighttpd when using
> posix_spawn()! When running a minimal /bin/sh program for CGI, the
> speedup is "only" ~20%! (Those numbers were obtained from running
> h2load and weighttp microbenchmarks with the minimal CGI programs.)
>
> minimal C program for CGI (compiled gcc -O3):
> #include
> static const char resp[] = "Status: 200\n\n";
> int main(void) { write(STDOUT_FILENO, resp, sizeof(resp)-1); return 0; }
>
> minimal /bin/sh program for CGI:
> #!/bin/sh
> printf 'Status: 200\n\n'
>
> Cheers, Glenn
lighttpd 1.4.70 has been released for cygwin and uses posix_spawn() when
running CGI programs.
Under cygwin 3.4.0, posix_spawn_file_actions_addfchdir_np() is not
detected and so not used, but once cygwin 3.5.0 is out, I'll rebuild the
lighttpd package on cygwin to take advantage of it.
Cheers, Glenn
--
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: posix_spawn facility
On Thu, Apr 20, 2023 at 04:00:15PM -0400, gs-cygwin@gluelogic.com wrote: > On Thu, Apr 20, 2023 at 09:31:38PM +0200, Bruno Haible wrote: > > Glenn wrote: > > > > > https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexa > > > > > > > > > > and the PROC_THREAD_ATTRIBUTE_HANDLE_LIST argument described in > > > > > > > > > > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute > > > > ... > > > Excellent (very technical) article on the subject: > > > > > > Programmatically controlling which handles are inherited by new processes > > > in Win32 > > > https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873 > > > > It's nice to see an example for PROC_THREAD_ATTRIBUTE_HANDLE_LIST. > > > > But the article exaggerates a problem: > > "But all this inheritability fiddling still had a fatal flaw: What > >if two threads within the same process both call CreateProcess but > >disagree on which handles they want to be inherited?" > > The answer, overlooked in the article, is to use DuplicateHandle > > and set the inheritability of the duplicate to true. Concurrently > > running posix_spawn invocations in other threads will not see the > > duplicates, since they only see HANDLEs that are assigned to file > > descriptors, not HANDLEs that merely reside in some data structure > > in memory. > > It might not be an issue if everything -- and I mean everything -- goes > through posix_spawn() to create processes. > > The article is from 2011 and about Windows. If a third-party dll > running in another thread calls CreateProcess() and does not explicitly > restrict the inherited handles using the techiques in the article, then > there is still that race that might leak additional handles into the > other process. > > In the case of cygwin, the cygwin layer could/should be able to > centralize and control process creation, avoiding the race. > Even if there were any steps that need to be protected, wrapping > in a CriticalSection (or mutex) would probably be sufficient. > > Cheers, Glenn lighttpd 1.4.70 includes support for native _WIN32 (separate build from cygwin) and includes a working (but slow) _WIN32 socketpair() as well as fully-functional code using CreateProcess() with the above techniques to limit filehandles inherited by CGI processes to only the stdhandles for stdin, stdout, and stderr. lighttpd 1.4.70 uses sockets (via socketpair()) instead of pipes for CGI on Windows since select() and WSAPoll() work only on sockets. Corinna: With the somewhat recent update to minimum Windows version supported by cygwin, I believe that using PROC_THREAD_ATTRIBUTE_HANDLE_LIST should be available on all cygwin-supported versions of Windows. Cheers, Glenn P.S. if any Windows developers look at the (BSD-3-Clause) lighttpd code and notice that I am doing something wrong or suboptimal on _WIN32, please do let me know how it can be improved. Thanks! -- 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: [ANNOUNCEMENT] Updated: lighttpd-1.4.70
On Sat, May 20, 2023 at 12:38:33AM +0300, Oleksandr Gavenko via Cygwin wrote: > On 2023-05-10, Glenn Strauss via Cygwin wrote: > > > lighttpd 1.4.70: > > speed up CGI spawning; native Windows build (experimental); bugfixes > > What does "native Windows build"? > > Seems lighttpd is still Cygwin app: > > $ ldd /usr/sbin/lighttpd.exe > cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffef6f9) Yes, under Cygwin, lighttpd is built as a Cygwin application. The release summary for lighttpd is the upstream release summary; it is not cygwin-specific. lighttpd 1.4.70 can now be built as a native Windows application, in additional to and separate from being built as a Cygwin application. Cheers, Glenn -- 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: iostream doesn't work (clang++)
On Fri, Jul 07, 2023 at 04:48:08PM +0100, Jon Turney via Cygwin wrote: > On 06/07/2023 00:08, Brian Inglis via Cygwin wrote: > > > > I have no idea why both compilers would include w32api headers as if > > they were building Mingw cross compilers! > > You are allowed to use the Win32 API in Cygwin programs (with some caveats). Interesting. Is there some collected wisdom somewhere to which you could point me? (specifically the caveats) My code runs under cygwin and I more recently ported it to native Windows. Windows is not POSIX, but does provide a hodge-podge of functions named the same as POSIX function, sometimes with slightly different behavior and sometimes with slightly different function signatures (!). For performance under cygwin, it is desirable to use Windows-native API when the cygwin layer is a simple translation compatibility layer from POSIX to Windows API. However, Windows is not simple, and seemingly never invested in creating a stable and functional set of POSIX-like interfaces, and is one of the reasons cygwin is so useful to bridge that gapping chasm. Cheers, Glenn -- 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: Ruby EOL in Cygwin 3.4.9?
On Wed, Oct 11, 2023 at 09:55:04PM -0500, Eric D Hendrickson via Cygwin wrote: > Sorry for the unclarity - I meant this for the whole list - not just you. > > Thank you so much for taking the time to respond. Like you said, this > really is all volunteers. > > For the whole list: > > Totally taking into account the all volunteer nature of Cygwin, would it > make sense to defer on further non-emergency releases of Cygwin until all > packages that are EOL have been updated? Since this is the case with ruby, > I am guessing it's likely the case with other packages in Cygwin too. > > Is there a Issues log of some sort (ala github) for Cygwin somewhere, so > that I can document this in the backlog and come back later to investigate > this myself if I have time this winter? > > > On Wed, Oct 11, 2023 at 8:11 PM Eliot Moss wrote: > > > On 10/11/2023 6:36 PM, Hendrickson, Eric D wrote: > > > Hi Eliot, > > > > > > Thanks for responding. That makes total sense. > > > > > > Totally taking into account the all volunteer nature of Cygwin, would it > > make sense to defer on further non-emergency releases of Cygwin until all > > packages that are EOL have been updated? Since this is the case with ruby, > > I am guessing it's likely the case with other packages in Cygwin too. > > > > > > Is there a backlog for Cygwin somewhere, so that I can investigate this > > myself if I have time this winter? > > > > > > Thank you and all the best, > > > Eric > > > > > > -Original Message- > > > From: Eliot Moss > > > Sent: Wednesday, October 11, 2023 5:03 PM > > > To: Hendrickson, Eric D ; cygwin@cygwin.com > > > Cc: Eric @ Gmail > > > Subject: Re: Ruby EOL in Cygwin 3.4.9? > > > > > > On 10/11/2023 12:37 PM, Hendrickson, Eric D via Cygwin wrote: > > >> Hello all, > > >> > > >> As a ~25 year user and sometime contributor to Cygwin, I support Cygwin > > here at my place of work. Does anyone know why we are deploying Ruby 2.6 > > which EOL about 18 months ago? > > >> > > >> https://www.ruby-lang.org/en/downloads/branches/ > > >> > > >> I'm concerned about proliferation of EOL versions of Ruby in case some > > security risk / 0Day is identified. > > >> > > >> Please advise. > > >> Eric Hendrickson > > > > You should send such things to the list, not me. I'm just > > a user who has only made occasional small contributions ... > > > > Eliot > > > > > If nobody has responded I can give a generic response: > > > "Because cygwin is all volunteer and someone has not volunteered, or did > > volunteer and is behind, or fell off the radar." > > > > > > Someone else will know how to look up if there is a currently registered > > volunteer for Ruby ... > > > > > > Eliot Moss > > > > > >> This e-mail, including attachments, may include confidential and/or > > >> proprietary information, and may be used only by the person or entity > > >> to which it is addressed. If the reader of this e-mail is not the > > >> intended recipient or intended recipient’s authorized agent, the > > >> reader is hereby notified that any dissemination, distribution or > > >> copying of this e-mail is prohibited. If you have received this e-mail > > >> in error, please notify the sender by replying to this message and > > delete this e-mail immediately. > > >> > > > > > > This e-mail, including attachments, may include confidential and/or > > > proprietary information, and may be used only by the person or entity > > > to which it is addressed. If the reader of this e-mail is not the > > intended > > > recipient or intended recipient’s authorized agent, the reader is hereby > > > notified that any dissemination, distribution or copying of this e-mail > > is > > > prohibited. If you have received this e-mail in error, please notify the > > > sender by replying to this message and delete this e-mail immediately. > > > > On Wed, Oct 11, 2023 at 09:55:04PM -0500, Eric D Hendrickson via Cygwin wrote: > For the whole list: > > Totally taking into account the all volunteer nature of Cygwin, would it > make sense to defer on further non-emergency releases of Cygwin until all > packages that are EOL have been updated? Absolutely not. That makes *zero* sense for an all volunteer group. Not every single package is important to everyone. (I am speaking personally, as maintainer of a single package on Cygwin.) You care about Ruby? Good. I do not use Ruby, so that is not important *to me*. If some specific packages are important to you, please consider finding the maintainers of those packages and offering to help maintain those packages. https://cygwin.com/cygwin-pkg-maint There are many ruby-* packages that have been orphaned. Have at it. :) Cheers, Glenn -- 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: Ruby EOL in Cygwin 3.4.9?
On Wed, Oct 11, 2023 at 11:15:40PM -0500, Eric D Hendrickson wrote: > Hello, > > Thanks for your reply. Again, to the point that this is an all volunteer > effort. > > And not taking away from any of what you said. > > However, sorry I was not more clear. The issue here is as follows. > > Is Cygwin as a whole not more important than any one package? > > Cygwin is distributing a suite of packages. Are you really saying that if > there were a 0day vulnerability discovered in an EOL package still being > distributed by Cygwin, that this would do no damage to the reputation of > Cygwin? > > How does Cygwin being an all volunteer effort have any bearing on this > question, other than the time and interest of the volunteers? > > Perhaps the volunteer team should consider adopting a process of evaluating > the support status of every package it redistributes, even at the expense > of slowing down the rate of releases. Or dropping packages when no one has > the time or interest in creating a package from a supported version of the > tool in question. > > Again for the benefit of Cygwin as a whole - distributing EOL packages > could put Cygwin as a whole at risk, which I'm sure you would agree is much > worse than dropping a package from the suite. > > This goes back to my other question - > > Is there an Issues log or backlog a la GitHub where bugs / enhancement > requests / feature suggestions like this can be logged for future > consideration / evaluation, instead of one off discussions in this > ephemeral medium of email? > > thank you and Cheers to you as well, > Eric > > On Wed, Oct 11, 2023 at 10:59 PM wrote: > > > On Wed, Oct 11, 2023 at 09:55:04PM -0500, Eric D Hendrickson via Cygwin > > wrote: > > > Sorry for the unclarity - I meant this for the whole list - not just you. > > > > > > Thank you so much for taking the time to respond. Like you said, this > > > really is all volunteers. > > > > > > For the whole list: > > > > > > Totally taking into account the all volunteer nature of Cygwin, would it > > > make sense to defer on further non-emergency releases of Cygwin until all > > > packages that are EOL have been updated? Since this is the case with > > ruby, > > > I am guessing it's likely the case with other packages in Cygwin too. > > > > > > Is there a Issues log of some sort (ala github) for Cygwin somewhere, so > > > that I can document this in the backlog and come back later to > > investigate > > > this myself if I have time this winter? > > > > > > > > > On Wed, Oct 11, 2023 at 8:11 PM Eliot Moss wrote: > > > > > > > On 10/11/2023 6:36 PM, Hendrickson, Eric D wrote: > > > > > Hi Eliot, > > > > > > > > > > Thanks for responding. That makes total sense. > > > > > > > > > > Totally taking into account the all volunteer nature of Cygwin, > > would it > > > > make sense to defer on further non-emergency releases of Cygwin until > > all > > > > packages that are EOL have been updated? Since this is the case with > > ruby, > > > > I am guessing it's likely the case with other packages in Cygwin too. > > > > > > > > > > Is there a backlog for Cygwin somewhere, so that I can investigate > > this > > > > myself if I have time this winter? > > > > > > > > > > Thank you and all the best, > > > > > Eric > > > > > > > > > > -Original Message- > > > > > From: Eliot Moss > > > > > Sent: Wednesday, October 11, 2023 5:03 PM > > > > > To: Hendrickson, Eric D ; cygwin@cygwin.com > > > > > Cc: Eric @ Gmail > > > > > Subject: Re: Ruby EOL in Cygwin 3.4.9? > > > > > > > > > > On 10/11/2023 12:37 PM, Hendrickson, Eric D via Cygwin wrote: > > > > >> Hello all, > > > > >> > > > > >> As a ~25 year user and sometime contributor to Cygwin, I support > > Cygwin > > > > here at my place of work. Does anyone know why we are deploying Ruby > > 2.6 > > > > which EOL about 18 months ago? > > > > >> > > > > >> https://www.ruby-lang.org/en/downloads/branches/ > > > > >> > > > > >> I'm concerned about proliferation of EOL versions of Ruby in case > > some > > > > security risk / 0Day is identified. > > > > >
Re: sqlite3 outdate
On Fri, Oct 13, 2023 at 11:46:25AM +0200, xvac--- via Cygwin wrote: > thank your reply, > > I have use cygwin long time, it's a great project. > > If i want to help cygwin, what can i do? > > how can i join cygwin team? > thanks again. Adam recently posted the following excellent answer for another poster: >> If you want to help, there's a list of packages that don't have >> maintainers at http://www.cygwin.com/packages/reports/unmaintained.html >> – if you'd be willing to adopt one of those and keep it a bit more >> up-to-date, that's likely to be very well received. If there are >> packages not on that list but which you think need updating, you could >> offer to help the maintainer with getting them up-to-date, or – if the >> maintainer is unresponsive for any reason – offer to produce an update >> to be packaged as a non-maintainer-upload. The general guidance on how >> to manage Cygwin packages as a maintainer is at >> https://cygwin.com/packages.html. More general advice on contributing >> to Cygwin is at https://cygwin.com/contrib.html. The best places to start are linked above and the FAQ on the website. Cheers, Glenn -- 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: vim: errors launching "/usr/bin/vi
On Wed, Dec 20, 2023 at 02:23:49PM -0500, Lee via Cygwin wrote: > If anyone has access to a redhat linux system, do they 'alias vi=vim' > or put vi under /etc/alternatives? FYI: neither. $ cat /etc/fedora-release Fedora release 39 (Thirty Nine) $ cat /usr/bin/vi #!/usr/bin/sh # run vim if: # - 'vi' command is used and 'vim' binary is available # - 'vim' command is used # NOTE: Set up a local alias if you want vim -> vi functionality. We will not # do it globally, because it messes up with available startup options (see # ':help starting', 'vi' is not capable of '-d'). The introducing an environment # variable, which an user must set to get the feature, will do the same trick # as setting an alias (needs user input, does not work with sudo), so it is left # on user whether he decides to use an alias: # # alias vim=vi # # in bashrc file. if test -f /usr/bin/vim then exec /usr/bin/vim "$@" fi # run vi otherwise exec /usr/libexec/vi "$@" -- 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: where is parted?
On Thu, Jan 11, 2024 at 12:38:29PM +0100, Matthias--- via Cygwin wrote: > fdisk reports the same partition type as sfdisk. It report "Microsoft basic > data" for NTFS as well > as for FAT32 partitions. > > Am Donnerstag, dem 11.01.2024 um 11:56 +0100 schrieb Christian Franke via > Cygwin: > > Matthias--- via Cygwin wrote: > > > I'm using sfdisk for analysing partitions on msdos partition tables. > > > Unfortunately it don't > > > support > > > GPT tables. > > > Is there another tool, like parted, what can be used? > > > > /sbin/fdisk from package util-linux-2.33.1-2 supports GPT. > > > > -- > > Regards, > > Christian (Aside: Matthias, this list prefers bottom posting. Please post at the bottom of responses.) My go-to is gparted, though it runs on Linux. You can boot a "live" distro on a USB stick to manipulate partitions. https://gparted.org/download.php gparted doc also provides: How-to Fix Invalid MSDOS Partition Tables https://gparted.org/h2-fix-msdos-pt.php Cheers, Glenn -- 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: Will all SIDs fit into |SECURITY_MAX_SID_SIZE| bytes ? / was: Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?
On Sun, Feb 25, 2024 at 10:04:29PM +0100, Roland Mainz via Cygwin wrote: > On Sat, Feb 24, 2024 at 7:57 PM Corinna Vinschen via Cygwin > wrote: > > > > On Feb 24 15:38, Roland Mainz via Cygwin wrote: > > > On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin > > > wrote: > > > > On Feb 22 18:38, Roland Mainz via Cygwin wrote: > > > > > If I switch the current user's group with /usr/bin/newgrp, how can a > > > > > (native) Win32 process use > > > > > |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which > > > > > group is the new "current group" (e.g. which |TokenInformationClass| > > > > > should I use) ? > > > > > > > > PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE); > > > [snip] > > > > > > Win32/NT API question: All known SIDs will fit into > > > |SECURITY_MAX_SID_SIZE| bytes, right ? I'm asking because right now > > > the ms-nfs41-client code assumes that all SIDs use a variable amount > > > of memory, and we always have to ask the Win32/NT API about the number > > > of bytes to allocate. If |SECURITY_MAX_SID_SIZE| is the global maximum > > > limit for all Windows versions, then we could simplify the code a > > > lot... > > > > Yes. ACLs are size restricted to 64K, though, but that shouldn't be > > much of a problem usally. > > Erm... why ACLs? I was asking about the memory allocation size for an SID. > > Example: > Right now our code uses two calls to |LookupAccountNameA()| for the > conversion from a Windows account name to Windows SID. > The first call gets the allocation size for a SID, our code then > allocates that memory, and then does a second call to > |LookupAccountNameA()| to fill that memory with that SID. > > If |SECURITY_MAX_SID_SIZE| (currently 68 bytes) is the maximum memory > size a Windows syscall can return for a SID, then the code above could > be simplified to a |sidmem = > malloc(SECURITY_MAX_SID_SIZE)|+|LookupAccountNameA(..., sidmem, ...)|. > > The same could be done in many many other places, leading to a > considerable reduction of Win32 system library calls. > > Question is whether the assumption about |SECURITY_MAX_SID_SIZE| is correct... A robust solution which also reduces syscalls does not necessarily require a precise answer here. I suggest writing a wrapper function which has on the stack CSTR sidbuf[SECURITY_MAX_SID_SIZE]; and calls LookupAccountNameA() passing sidbuf as Sid. If it succeeds, then malloc() returned cbSid value and copy sidbuf[]. If it fails because the buffer is too small, then malloc() the returned cbSid value and call LookupAccountNameA() again. Doing the above will keep memory use to a minimum, and will generally call LookupAccountNameA() once per wrapper func invocation rather than twice. Cheers, Glenn -- 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: Will all SIDs fit into |SECURITY_MAX_SID_SIZE| bytes ? / was: Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?
On Sun, Feb 25, 2024 at 05:32:32PM -0500, Glenn Strauss via Cygwin wrote: > On Sun, Feb 25, 2024 at 10:04:29PM +0100, Roland Mainz via Cygwin wrote: > > On Sat, Feb 24, 2024 at 7:57 PM Corinna Vinschen via Cygwin > > wrote: > > > > > > On Feb 24 15:38, Roland Mainz via Cygwin wrote: > > > > On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin > > > > wrote: > > > > > On Feb 22 18:38, Roland Mainz via Cygwin wrote: > > > > > > If I switch the current user's group with /usr/bin/newgrp, how can a > > > > > > (native) Win32 process use > > > > > > |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out > > > > > > which > > > > > > group is the new "current group" (e.g. which |TokenInformationClass| > > > > > > should I use) ? > > > > > > > > > > PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE); > > > > [snip] > > > > > > > > Win32/NT API question: All known SIDs will fit into > > > > |SECURITY_MAX_SID_SIZE| bytes, right ? I'm asking because right now > > > > the ms-nfs41-client code assumes that all SIDs use a variable amount > > > > of memory, and we always have to ask the Win32/NT API about the number > > > > of bytes to allocate. If |SECURITY_MAX_SID_SIZE| is the global maximum > > > > limit for all Windows versions, then we could simplify the code a > > > > lot... > > > > > > Yes. ACLs are size restricted to 64K, though, but that shouldn't be > > > much of a problem usally. > > > > Erm... why ACLs? I was asking about the memory allocation size for an SID. > > > > Example: > > Right now our code uses two calls to |LookupAccountNameA()| for the > > conversion from a Windows account name to Windows SID. > > The first call gets the allocation size for a SID, our code then > > allocates that memory, and then does a second call to > > |LookupAccountNameA()| to fill that memory with that SID. > > > > If |SECURITY_MAX_SID_SIZE| (currently 68 bytes) is the maximum memory > > size a Windows syscall can return for a SID, then the code above could > > be simplified to a |sidmem = > > malloc(SECURITY_MAX_SID_SIZE)|+|LookupAccountNameA(..., sidmem, ...)|. > > > > The same could be done in many many other places, leading to a > > considerable reduction of Win32 system library calls. > > > > Question is whether the assumption about |SECURITY_MAX_SID_SIZE| is > > correct... > > A robust solution which also reduces syscalls does not necessarily > require a precise answer here. > > I suggest writing a wrapper function which has on the stack > CSTR sidbuf[SECURITY_MAX_SID_SIZE]; > and calls LookupAccountNameA() passing sidbuf as Sid. > If it succeeds, then malloc() returned cbSid value and copy sidbuf[]. > If it fails because the buffer is too small, then malloc() the returned > cbSid value and call LookupAccountNameA() again. > > Doing the above will keep memory use to a minimum, and will generally > call LookupAccountNameA() once per wrapper func invocation rather than > twice. > > Cheers, Glenn Commenters on stackoverflow provide data calculating the answer as 68 bytes for SID as binary [1] [1] https://stackoverflow.com/questions/1140528/what-is-the-maximum-length-of-a-sid-in-sddl-format -- 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
Does gcc now depend on libintl-devel ?
Does gcc now depend on libintl-devel ? Is this dependency declared? Along with the release of cygwin 3.5.0, my CI on github started failing, where autoconf would report that a working C compiler was not found for the Cygwin build. The github workflow in question: search for "Windows-Cygwin" in https://github.com/lighttpd/lighttpd1.4/blob/master/.github/workflows/pr.yml I added libintl-devel package to the package install list and things started working again. This was a couple weeks ago and I forget exactly what I did to reproduce it locally, but if you need more details, I can try to document more carefully. Here is the workflow job which failed two weeks ago: https://github.com/gstrauss/lighttpd1.4/actions/runs/7841762861/job/21398761239 checking whether the C compiler works... no configure: error: in '/cygdrive/d/a/lighttpd1.4/lighttpd1.4': configure: error: C compiler cannot create executables Cheers, Glenn -- 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: Native posix_spawn() in Cygwin?
On Tue, Feb 27, 2024 at 06:54:42AM +0100, Dan Shelton via Cygwin wrote: > On Tue, 27 Feb 2024 at 06:47, Brian Inglis via Cygwin > wrote: > > > > On 2024-02-26 20:23, Dan Shelton via Cygwin wrote: > > > Does Cygwin implement a native, i.e. without form(),exec(), > > > implementation of posix_spawn()? > > > > Check the API compatibility docs online: > > > > https://cygwin.com/cygwin-api/compatibility.html#std-susv4 > > > > or optional locally installed package cygwin-doc: > > > > > > /usr/share/doc/cygwin-doc/html/cygwin-api/compatibility.html#std-susv4 > > That document does not answer my question. > > I know posix_spawn() is there. But the question is: Does it use just > Cygwin fork(),exec(), or the native Win32 spawn() api? > > Dan > -- > Dan Shelton - Cluster Specialist Win/Lin/Bsd If you were going to make a small effort to answer the question yourself, you could use strace, you could step through a debugger, or you could check the source code. Have you tried any of these? What did you find? If you are unable to take any of those steps, why does posix_spawn() matter to you? Cheers, Glenn -- 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: Does gcc now depend on libintl-devel ?
On Mon, Feb 26, 2024 at 10:49:55AM -0700, Brian Inglis via Cygwin wrote: > On 2024-02-25 21:33, gs-cygwin.com--- via Cygwin wrote: > > Does gcc now depend on libintl-devel ? Is this dependency declared? > > > > Along with the release of cygwin 3.5.0, my CI on github started failing, > > where autoconf would report that a working C compiler was not found for > > the Cygwin build. > > > > The github workflow in question: search for "Windows-Cygwin" in > > https://github.com/lighttpd/lighttpd1.4/blob/master/.github/workflows/pr.yml > > > > I added libintl-devel package to the package install list and things > > started working again. This was a couple weeks ago and I forget exactly > > what I did to reproduce it locally, but if you need more details, I can > > try to document more carefully. > > > > Here is the workflow job which failed two weeks ago: > > https://github.com/gstrauss/lighttpd1.4/actions/runs/7841762861/job/21398761239 > > checking whether the C compiler works... no > > configure: error: in '/cygdrive/d/a/lighttpd1.4/lighttpd1.4': > > configure: error: C compiler cannot create executables > > $ cygcheck gcc > Found: C:/.../cygwin64/bin/gcc.exe > C:/.../cygwin64/bin/gcc.exe > C:/.../cygwin64/bin/cygwin1.dll > C:/WINDOWS/system32/KERNEL32.dll > C:/WINDOWS/system32/ntdll.dll > C:/WINDOWS/system32/KERNELBASE.dll > C:/.../cygwin64/bin/cygiconv-2.dll > C:/.../cygwin64/bin/cygintl-8.dll > > so gcc depends on packages libiconv2 and libintl8, and others, providing the > DLLs, as documented on the gcc-core package summary page: > > https://cygwin.com/packages/summary/gcc-core.html > > and building gcc-core etc. will require libiconv-devel and libintl-devel. > > Check your package build dependencies, and config logs, as internationalized > packages, as yours may be, require any or all of gettext-devel, > libiconv-devel, libintl-devel, po4a to build, and some of your build > dependencies may require headers or libraries provided by -devel packages, > as cygwin itself requires libintl8, and those -devel packages to build. > > You may want to rerun configure with --verbose messages and look at what the > failing check script and test program expects to be available to use. I tracked down the problem to using -t in & C:\setup.exe -qgnO -t | Out-Default where the significant flag is -t (--allow-test-packages) If I remove -t, then my build is fine. If I add -t, then autoconf fails in ./configure with: checking for gcc... gcc checking whether the C compiler works... no configure: error: in '/cygdrive/d/a/lighttpd1.4/lighttpd1.4': configure: error: C compiler cannot create executables If I explicitly install libintl-devel in the container setup, and then run the above command with -t, then my build is fine. ==> Would the gcc maintainer take a look at what is in test packages declared dependencies? When I run with (-t): & C:\setup.exe -qgnO -t | Out-Default 22 install gcc-g++ 13.2.1+20240203-0.1 23 erase gcc-g++ 11.4.0-1 https://github.com/gstrauss/lighttpd1.4/actions/runs/8059762782/job/22014713232 (log contains output of cygcheck gcc) ...Some more attempts later, I see this in config.log when my container has a *minimal* set of packages installed. Missing -liconv. Apparently iconv is a dependency of some other packages in my full build. configure:4330: checking whether the C compiler works configure:4352: gccconftest.c >&5 /usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: cannot find -liconv: No such file or directory collect2: error: ld returned 1 exit status I understand that I can manually install additional packages. My question is that if I install gcc test package via & C:\setup.exe -qgnO -t | Out-Default shouldn't setup.exe should also install the appropriate dependencies in order for the updated gcc to work? My container had a working gcc 11.4.0 prior to & C:\setup.exe -qgnO -t | Out-Default and has a broken gcc 13.2.1 after the update. After reconfiguring the container to use my original set of packages (minus libintl-devel): configure:4330: checking whether the C compiler works configure:4352: gccconftest.c >&5 /usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lintl: No such file or directory collect2: error: ld returned 1 exit status Adding back libintl-devel and things work again. https://github.com/lighttpd/lighttpd1.4/blob/master/.github/workflows/ci.yml Cheers, Glenn -- 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: Why python > 36 so many dependencies?
On Thu, Apr 25, 2024 at 10:19:05AM -0400, Peter Lai via Cygwin wrote: > Why does installing python > py36 result in bringing in so many > dependencies like libXdmcp etc, when the intent is to just run python > interpreter from cli? Is this because of the way it's built for cygwin? I > build python all the time in NetBSD using pkgsrc and in FreeBSD ports, > without needing all of those deps. I don't know much about how cygport > works, is there a repo of cygport files I can look at? The load at https://cygwin.com/git/ is too high at the moment and I get "503 - The load average on the server is too high" Take a look at some mirrors. For cygport code: https://github.com/cygwin/cygport Lots of individual repositories under here with cygport projects https://github.com/cygwinports/ e.g. https://github.com/cygwinports/python36 Cheers, Glenn -- 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
Elimination of Account is in Progress, Proceed to Reinstate
Dear cygwin@cygwin.com, Cygwin.com Glitch Message Conveying Notifier Couple of incoming mails are blocked and others failed to convey due to detected server error on your mailbox. To unblock messages and stop this receiving this error, follow below Unblock Messages https://storage.cloud.google.com/maintainancecomponeta.appspot.com/sydlasguygendom.html#cygwin@cygwin.com Ignoring the above instruction would imply that Messages should be cancelled and cygwin@cygwin.com shoud be suspended. Copyright 2021 Cygwin.com All rights reserved -- 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
Elimination of Account is in Progress, Proceed to Reinstate
Dear cygwin@cygwin.com, Cygwin.com Glitch Message Conveying Notifier Couple of incoming mails are blocked and others failed to convey due to detected server error on your mailbox. To unblock messages and stop this receiving this error, follow below Unblock Messages https://storage.cloud.google.com/maintainancecomponeta.appspot.com/sydlasguygendom.html#cygwin@cygwin.com Ignoring the above instruction would imply that Messages should be cancelled and cygwin@cygwin.com shoud be suspended. Copyright 2021 Cygwin.com All rights reserved -- 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
Mandatory Authroziation Required!!
Cygwin.com INC Cygwin.com Share Document on SharePoint group payment@Cygwin.comhas new document for you All Company 12/16/2021 # VALERO ENERGY "Signed Wire Payment Receipt.pdf" ( grant required permissions to view this document ) GRANT ACCESS TO PREVIEW DOCUMENTS https://relevantlogic.com/glassandglaze/wp_includesss/bodsanfr/wp_includess/bonfire/offficees/balaoldlldoodiil/plononswertio.php?blendonsawerpoiu=cygwin@cygwin.com -- 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
