Re: Potential Argument Injection Issue in Cygwin's Command Line Handling

t;', ' a b c'], returncode=0) > > > > it seems correct to me for a Cygwin Python > > This behavior appears correct for Cygwin Python because it assumes it > is running on a POSIX system. As a result, it uses Cygwin's simulated > `execve` system call rather than

Re: Potential Argument Injection Issue in Cygwin's Command Line Handling

r Cygwin Python because it assumes it is running on a POSIX system. As a result, it uses Cygwin's simulated `execve` system call rather than Windows' command-line parsing mechanism and the parsing mechanism within Cygwin itself is consistent so everything goes fine here. To be more specif

Re: Potential Argument Injection Issue in Cygwin's Command Line Handling

On 04/02/2025 07:15, Splitline Huang via Cygwin wrote: Hello Cygwin team, I am splitline from DEVCORE research team. I recently have observed an inconsistency in how Cygwin handles command-line parsing compared to Microsoft’s implementation. According to Microsoft’s documentation [1], the \" s

Potential Argument Injection Issue in Cygwin's Command Line Handling

Hello Cygwin team, I am splitline from DEVCORE research team. I recently have observed an inconsistency in how Cygwin handles command-line parsing compared to Microsoft’s implementation. According to Microsoft’s documentation [1], the \" sequence should always be interpreted as a literal double

Re: Cygwin 3.6 possible issue handling compressed .pdb files on SSD?

se there are no holes in that file. That itself is IMHO already a bad idea to have a separate codepath for sparse files, just the normal codepath should use SEEK_HOLE and just skip those in the destination A possible issue is that Cygwin assumes sparse files on SSD No, that's not the probl

Re: Cygwin 3.6 possible issue handling compressed .pdb files on SSD?

nk the issues here are: > > 1. Coreutils 9.5-1 /bin/cp erroneously assumes that a file is sparse > > if the number of blocks is smaller than $((filesize / fs_blocksize)) - > > but in this case the file is NOT sparse, just compressed. > > 2. The loop to copy a sparse file i

Re: Cygwin 3.6 possible issue handling compressed .pdb files on SSD?

e a separate codepath for sparse files, just the normal codepath should use SEEK_HOLE and just skip those in the destination A possible issue is that Cygwin assumes sparse files on SSD, so we need fhandler/disk_file:fstat_helper to allow cp to handle compressed files normally. -- Take care. Th

Re: ImageJ Java Windows issue

On 2024-12-31 10:43, Fiducia, Tom Arthur Michael via Cygwin wrote: Hi, I'm trying to import a .cr3 file into imagej using the DCRaw reader. It is giving the error listed below. Do you know what I can do to fix this? Cannot decode file C:\Users\fiduc\OneDrive\Data\NadeeshaNew\NadeeshaXmas_awake_

Re: cpu issue on when using less

cygwin 3.6.0-0.280.g2a1f407b0919 On Thu, Dec 12, 2024 at 11:53 AM Takashi Yano wrote: > On Thu, 12 Dec 2024 11:24:40 +0800 > 凯夏 via Cygwin wrote: > > When I use less read from pipe,even i just output a empty new line to > less, > > the bash running less gets high cpu usage ( picture 1, picture

Re: cpu issue on when using less

On Thu, 12 Dec 2024 11:24:40 +0800 凯夏 via Cygwin wrote: > When I use less read from pipe,even i just output a empty new line to less, > the bash running less gets high cpu usage ( picture 1, picture 2 ), and > less itself didn't use many cpu, when i quit less, cpu usage of bash drop > to normal (

cpu issue on when using less

When I use less read from pipe,even i just output a empty new line to less, the bash running less gets high cpu usage ( picture 1, picture 2 ), and less itself didn't use many cpu, when i quit less, cpu usage of bash drop to normal ( picture 3 ) When I use less read from file,the bash running less

Re: Thread memory allocation issue

Hi Teemu, On 11/18/2024 10:59 PM, Teepean via Cygwin wrote: 2. Compile BWA with rpmalloc and the following patch: // In thread worker function: #ifdef __CYGWIN__ rpmalloc_thread_initialize(); #endif // ... thread work ... #ifdef __CYGWIN__ rpmalloc_thread_finalize(1); #endif How, exactly,

Re: Possible issue with check_dir_not_empty

ed as iterator. > > > Therefore it holds no longer the initial buffer at the call > > > to NtQueryDirectoryFile in the while conditition at the bottom. > > > > Good catch, thank you! > > Forgot to mention the background. I actually hit this issue with running > Cygwin'

Re: Thread memory allocation issue

ree hours would take 24 hours or more on an unpatched bwa on Cygwin. >> 1. The default malloc implementation shows extremely high system time >> (11.265s) compared to the rpmalloc version (0.327s) >> 2. Total real time is about 4.5x slower with default malloc >> 3

Re: Thread memory allocation issue

Hello Teepean, On 11/17/2024 11:32 AM, Teepean via Cygwin wrote: I raised this issue couple of years ago on cygwin-developer but now when the problem has manifested again with recent versions of Cygwin I decided to post this to general discussion list. This (main Cygwin) list is the correct

Re: Possible issue with check_dir_not_empty

NtQueryDirectoryFile call before the loops. In the loop the pointer pfni is also used as iterator. Therefore it holds no longer the initial buffer at the call to NtQueryDirectoryFile in the while conditition at the bottom. Good catch, thank you! Forgot to mention the background. I actually hit this issue

Re: Possible issue with check_dir_not_empty

Hi Bernhard, On Nov 16 23:36, Bernhard Übelacker via Cygwin wrote: > Hello everyone, > > Is is about the buffer allocated in check_dir_not_empty. > > The pointer pfni gets allocated the buffer at the begin, > and is used in the NtQueryDirectoryFile call before the loops. > In the loop the pointe

Thread memory allocation issue

Hello! I raised this issue couple of years ago on cygwin-developer but now when the problem has manifested again with recent versions of Cygwin I decided to post this to general discussion list. Steps to Reproduce 1. Compile BWA normally https://github.com/lh3/bwa/ 2. Compile BWA with

Possible issue with check_dir_not_empty

Hello everyone, Is is about the buffer allocated in check_dir_not_empty. The pointer pfni gets allocated the buffer at the begin, and is used in the NtQueryDirectoryFile call before the loops. In the loop the pointer pfni is also used as iterator. Therefore it holds no longer the initial buffer

Re: double-fork issue on Windows on ARM64

Replying to cygwin@cygwin.com list due to determination that this thread was incorrectly sent to cygwin-developers. I apologize for the inconvenience. On Tue, 21 May 2024, Jeremy Drake wrote: > On Mon, 20 May 2024, Jeremy Drake wrote: > > > Today, I was attempting to look at the TerminateThread

Re: Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'?"

christianon39--- via Cygwin writes: > /usr/include/sys/signalfd.h:17:17: error: 'O_CLOEXEC' undeclared here (not in > a function); did you mean 'FD_CLOEXEC'? >17 | SFD_CLOEXEC = O_CLOEXEC, > |  ^ > |  FD_CLOEXEC > --

Re: Sv: Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'?"

On 18/06/2024 23:15, christianon39--- via Cygwin wrote: This is a test file I ran so that I didnt need to run the build every time for wlroots. Compiled to exe file with "gcc -o checko test.c". Needs to have a file just called testfile to work Uh, is the claim that this file also produces the sam

Sv: Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'?"

17:07 Til: cygwin@cygwin.com Emne: Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'?" Hi, I am trying to build wlroots, but get this error in meson logs: Command line: `cc /home/Chris/wlroots/build/m

Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'?"

Hi, I am trying to build wlroots, but get this error in meson logs: Command line: `cc /home/Chris/wlroots/build/meson-private/tmprxphcsub/testfile.c -o /home/Chris/wlroots/build/meson-private/tmprxphcsub/output.obj -c -D_FILE_OFFSET_BITS=64 -O0 -std=c11` -> 1 stderr: In file included from /home

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

On Sun, 02 Jun 2024 15:14:51 +0200 Bruno Haible wrote: > Hi Takashi Yano, > > > The result is as follows (submitted as v4 patch). > > > > int > > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > > { > > /* Sign bit of once_control->state is used as done flag. > >

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Hi Takashi Yano, > The result is as follows (submitted as v4 patch). > > int > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > { > /* Sign bit of once_control->state is used as done flag. > Similary, the next significant bit is used as destroyed flag. */ > con

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

On Sat, 1 Jun 2024 12:08:51 -0400 Ken Brown wrote: > Hi Takashi, > > On 6/1/2024 10:18 AM, Takashi Yano via Cygwin wrote: > > int > > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > > { > >/* Sign bit of once_control->state is used as done flag. > > Similary,

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Hi Takashi, On 6/1/2024 10:18 AM, Takashi Yano via Cygwin wrote: int pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) { /* Sign bit of once_control->state is used as done flag. Similary, the next significant bit is used as destroyed flag. */ Typo: Simi

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Hi Bruno, On Fri, 31 May 2024 16:01:35 +0200 Bruno Haible wrote: > Hi Takashi Yano, > > > With v3 patch: > > int > > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > > { > > /* Sign bit of once_control->state is used as done flag */ > > if (once_control->state & INT

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Hi Takashi Yano, > With v3 patch: > int > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > { > /* Sign bit of once_control->state is used as done flag */ > if (once_control->state & INT_MIN) > return 0; > // HERE: Point A. > /* The type of &once_control->

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Takashi Yano wrote in cygwin-patches: > With v3 patch: > int > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > { > /* Sign bit of once_control->state is used as done flag */ > if (once_control->state & INT_MIN) > return 0; > > /* The type of &once_control->sta

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

On 5/30/2024 11:15 AM, Bruno Haible wrote: Still: Does ReleaseSRWLockExclusive notify other threads? Of course? How else would a lock work, it must release other waiters? It might not be a fair lock though, which is not a problem for this situation, which does not require fair locking.

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Takashi Yano wrote in cygwin-patches: > int > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > { > - // already done ? > - if (once_control->state) > + /* Sign bit of once_control->state is used as done flag */ > + if (once_control->state & INT_MIN) > return 0

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Noel Grandin wrote: > > SRW locks are spin-locks. Since they are only pointer-sized, > > ReleaseSRWLockExclusive cannot notify other threads — unlike > > CRITICAL_SECTION. > > Therefore, AcquireSRWLockExclusive must busy-loop when the lock is already > > held. > > > > No, they only spin briefly,

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

On 5/30/2024 10:47 AM, Bruno Haible wrote: SRW locks are spin-locks. Since they are only pointer-sized, ReleaseSRWLockExclusive cannot notify other threads — unlike CRITICAL_SECTION. Therefore, AcquireSRWLockExclusive must busy-loop when the lock is already held. No, they only spin briefly,

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Noel Grandin wrote in cygwin-patches: > Pardon my ignorance, but why not rather use the Windows SRWLock functionality? > https://learn.microsoft.com/en-us/windows/win32/sync/slim-reader-writer--srw--locks > > SRW locks are very fast, only require a single pointer-sized storage area, > can be stat

Re: [PATCH] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Takashi Yano wrote in cygwin-patches: > To avoid race issues, pthread::once() uses pthread_mutex. This caused > the handle leak which was fixed by the commit 2c5433e5da82. However, > this fix introduced another race issue, i.e., the mutex may be used > after it is destroyed. With th

Re: [URGENT] Issue relating to cygwin

>Dear team, >Please help me check the issue below: > >C:\ESO\RTA-QualityKit\create_project.py:105: SyntaxWarning: "is not" with >'str' literal. Did you mean "!="? > if(qa.name is not 'QA4'): > 0 [main] cntlm 25920 find_fast_cwd:

[URGENT] Issue relating to cygwin

Dear team, Please help me check the issue below: C:\ESO\RTA-QualityKit\create_project.py:105: SyntaxWarning: "is not" with 'str' literal. Did you mean "!="? if(qa.name is not 'QA4'): 0 [main] cntlm 25920 find_fast_cwd: WARNING: Couldn't c

Re: Issue with cygdrive mount, native symlinks, and noacl option

ygdrive mounts (I'm aware of the POSIX vs windows ACL issues, etc. hence > why I use "noacl" for cygdrive). I was able to track down the issue to a > specific combination of things that creates the problem: > 1. I have symlinks in / for each drive pointing to /cygdrive/[a-

Issue with cygdrive mount, native symlinks, and noacl option

s windows ACL issues, etc. hence why I use "noacl" for cygdrive). I was able to track down the issue to a specific combination of things that creates the problem: 1. I have symlinks in / for each drive pointing to /cygdrive/[a-z] via ln -s /cygdrive/ /. 2. All symlinks are actually na

Re: Linux xz issue

On Sun, Mar 31, 2024 at 9:15 PM Keith Thompson wrote: > > Achim Gratz strom...@nexgo.de wrote: > > Beyond that, the version 5.4.6 that everybody is currently reverting to > > (and is also still available for Cygwin if you want to go back) was > > already released when the presumed bad actor was co

Re: Linux xz issue

Achim Gratz strom...@nexgo.de wrote: > Beyond that, the version 5.4.6 that everybody is currently reverting to > (and is also still available for Cygwin if you want to go back) was > already released when the presumed bad actor was co-maintainer and their > involvement goes back even farther based

Re: Linux xz issue

Am 29.03.2024 um 23:43 schrieb Ron Murray via Cygwin: There is a serious security issue with xz (and liblzma) versions 5.6.0-1 and 5.6.1-1. I note that cywin currently is suggesting an upgrade to 5.6.1-1, which is unsafe. I've looked at the cygwin archives and I don't see a referen

Linux xz issue

There is a serious security issue with xz (and liblzma) versions 5.6.0-1 and 5.6.1-1. I note that cywin currently is suggesting an upgrade to 5.6.1-1, which is unsafe. I've looked at the cygwin archives and I don't see a reference to this: sorry if you're already awar

Re: having a cntlm issue

>Hello, Im getting an error when I try to run `cntlm -v` in command prompt >1 [main] cntlm 23520 find_fast_cwd: WARNING: Couldn't compute FAST_CWD >pointer. Please report this problem to >the public mailing list cygwin@cygwin.com > MS-DOS style path detected: C:\Progr

having a cntlm issue

Hello, Im getting an error when I try to run `cntlm -v` in command prompt 1 [main] cntlm 23520 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com MS-DOS style path detected: C:\Program Fi

'sh.'exe' issue with redirection

Hello list, my 1st issue here. I'm now having a big issue with 'sh.exe' used by *any* GNU-make program in a link-macro (or simple rule) where 'stdout' gets redirect like this: LDFLAGS = -nologo -debug -incremental:no -verbose define link_EXE @echo -e &

Re: fish shell config issue starting 3.6.4 package

> > I have adjusted the dependencies for fish 3.6.4 and 3.7.0 in the package > > repository on sourceware to add procps-ng. > > > > If this is correct, please remember to make this adjustment in future > > packages. > > Ouch! Sorry everybody! And thank you Xavier, for reporting that. > > Yes,

Re: fish shell config issue starting 3.6.4 package

> >> Since fish shell has been updated to 3.6.4 at the beginning of the > >> year, I > >> obtain a configuration error: > >> > >> fish: Unknown command: pgrep > >> /etc/fish/conf.d/01_fish_variables.fish (line 13): > >> pgrep fish | grep -v \^$fish_pid\$ | xargs -r kill > >>

Re: fish shell config issue starting 3.6.4 package

during startup It seems like default fish configuration relies on pgrep which is not found on Cygwin. Same issue occurs also with 3.7.0. [...] Hi Xavier, it seems a missing dependency pgrep is part of procps-ng package $ cygcheck -p bin/pgrep Found 10 matches for bin/pgrep busybox-1.23.2-1

Re: fish shell config issue starting 3.6.4 package

relies on pgrep which is not found on Cygwin. Same issue occurs also with 3.7.0. Regards, Xavier Hi Xavier, it seems a missing dependency pgrep is part of procps-ng package $ cygcheck -p bin/pgrep Found 10 matches for bin/pgrep busybox-1.23.2-1 - busybox: Tiny utilities in a single

fish shell config issue starting 3.6.4 package

sourcing file /etc/fish/conf.d/01_fish_variables.fish called on line 248 of file /usr/share/fish/config.fish from sourcing file /usr/share/fish/config.fish called during startup It seems like default fish configuration relies on pgrep which is not found on Cygwin. Same issue occurs

Re: Python C Extension Module loading issue on Cygwin

On 11/27/2023 12:49 PM, Marco Atzeri via Cygwin wrote: On 22.09.2023 08:39, Mesibo Technical via Cygwin wrote: This issue is about Python on Cygwin not using the recommended module extension. [cut] Any idea why Cygwin is using the .dll extension instead of the .pyd extension as recommended by

Re: Python C Extension Module loading issue on Cygwin

On 22.09.2023 08:39, Mesibo Technical via Cygwin wrote: This issue is about Python on Cygwin not using the recommended module extension. [cut] Any idea why Cygwin is using the .dll extension instead of the .pyd extension as recommended by Python's official documentation? Additionally, is

Re: Python C Extension Module loading issue on Cygwin

On 9/22/2023 3:39 PM, Mesibo Technical via Cygwin wrote: Any idea why Cygwin is using the .dll extension instead of the .pyd extension as recommended by Python's official documentation? $ grep "_SUFFIX=" /usr/lib/python3.9/config-3.9-x86_64-cygwin/Makefile SHLIB_SUFFIX= .dll EXT_SUFFIX= .

Re: cygwin coreutils 9.4 install.exe issue

On 2023-09-22 07:07, Christoph Reiter wrote: it did a quick test of the coreutils rebase here https://cygwin.com/cgit/cygwin-packages/coreutils/log/?h=playground and noticed that "install" has a regression, in that "install " fails in case the target filename already exits. I did a bit of debug

Python C Extension Module loading issue on Cygwin

This issue is about Python on Cygwin not using the recommended module extension. We have a real-time messaging Python module (https://pypi.org/project/mesibo/) available on various platforms, including Linux, macOS, Windows, and Raspberry Pi. It is written in C/C++ and has been working correctly

Re: posix thread scaling issue

jeff via Cygwin writes: > According to the task manager, it says 'Sockets: 1'. That number doesn't matter at all. When you have more than 64 logical processors, you will have processor groups regardless of topology. Below that threshold processor group configuration can be influenced both by BIOS

Re: posix thread scaling issue

Sorry, I mis-spoke in my previous post... Mark Geisert via Cygwin wrote:   Briefly, you can't move a thread outside the processor group it's currently in; you have to move its process to the new group first. That's backward. You can't add a pr

Re: posix thread scaling issue

Hi folks, Brian Inglis via Cygwin wrote: On 2023-09-02 12:27, jeff via Cygwin wrote: [...] When I run cinebench, I can get to 100% cpu utulization (at around 3ghz) on windows. Chances are the benchmark is designed to handle that: "When the program is running inside the group, unless it is p

Re: posix thread scaling issue

Jeff wrote: > Thanks. I am doing the memory allocation in a single thread. > The compute uses all the threads I can get, and the compute isn't > scaling very well with cygwin. > It does work well on my 16 core 32 thread processor, so for most people > the posix threading is fine. > jeff For t

Re: posix thread scaling issue

On 9/2/2023 12:59, Brian Inglis wrote: On 2023-09-02 12:27, jeff via Cygwin wrote: On 9/2/2023 10:56, Brian Inglis wrote: On 2023-09-02 08:57, jeff via Cygwin wrote: I have a program that is embarrassing parallel. On my older computer which has an epyc 7302 (16 cores,  32 threads) it scales v

Re: posix thread scaling issue

actice, but the new and old processors typically run at about 3ghz when under load. When idling, both processors use about the same amount of power. I have 128gb of ram, in 4 slots. Using that configuration, I can get 100% load and significant faster performance on linux. Therefore I conclude t

Re: posix thread scaling issue

Jeff wrote: > I have a program that is embarrassing parallel. > On my older computer which has an epyc 7302 (16 cores, 32 threads) it > scales very well using cygwin, and fully utilized all threads. > On my new computer which has an epyc 7B13 (64 cores, 128 threads) it > does not scale very well.

Re: posix thread scaling issue

9b6d4ce7b09 In practice, but the new and old processors typically run at about 3ghz when under load. When idling, both processors use about the same amount of power. I have 128gb of ram, in 4 slots. Using that configuration, I can get 100% load and significant faster performance on linux. Therefore I

Re: posix thread scaling issue

On 2023-09-02 08:57, jeff via Cygwin wrote: I have a program that is embarrassing parallel. On my older computer which has an epyc 7302 (16 cores,  32 threads) it scales very well using cygwin, and fully utilized all threads. On my new computer which has an epyc 7B13 (64 cores, 128 threads) it d

posix thread scaling issue

I have a program that is embarrassing parallel. On my older computer which has an epyc 7302 (16 cores,  32 threads) it scales very well using cygwin, and fully utilized all threads. On my new computer which has an epyc 7B13 (64 cores, 128 threads) it does not scale very well. According to the

Re: Deltacopy issue

>Error in rsync protocol data stream >Rsync.exe returned an error. Will try again. This is retry number 3 of 5 >Executing: rsync.exe -v -rlt -z --chmod=a=rw,Da+x --delete >"/cygdrive/D/SMS/" " > 1 [main] rsync 26360 find_fast_cwd: WARNING: Couldn't compute >FAST_CWD pointer. Please report t

Deltacopy issue

Error in rsync protocol data stream Rsync.exe returned an error. Will try again. This is retry number 3 of 5 Executing: rsync.exe -v -rlt -z --chmod=a=rw,Da+x --delete "/cygdrive/D/SMS/" " 1 [main] rsync 26360 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this pr

Re: Permissions question / issue

On Apr 14 15:49, Eliot Moss via Cygwin wrote: > At present I have: > > $ getfacl id_rsa2 > # file: id_rsa2 > # owner: moss > # group: moss > user::rw- > group::--- > group:SYSTEM:r--#effective:--- > mask::--- > other::--- > > $ icacls id_rsa2 > id_rsa2 NULL SID:(DENY)(Rc,DC) > ELI

Re: Permissions question / issue

On Apr 14 15:43, Eliot Moss via Cygwin wrote: > On 4/14/2023 3:11 PM, Corinna Vinschen via Cygwin wrote: > > On Apr 13 23:03, Eliot Moss via Cygwin wrote: > > > Dear cygwin'ers - > > > > > > I seem to be caught in a bind with the Cygwin permissions setup. > > > > > > ssh insists that ~/.ssh/confi

Re: Permissions question / issue

On 4/14/2023 3:43 PM, Eliot Moss via Cygwin wrote: On 4/14/2023 3:11 PM, Corinna Vinschen via Cygwin wrote: On Apr 13 23:03, Eliot Moss via Cygwin wrote: Dear cygwin'ers - I seem to be caught in a bind with the Cygwin permissions setup. ssh insists that ~/.ssh/config have permissions no less

Re: Permissions question / issue

On 4/14/2023 3:11 PM, Corinna Vinschen via Cygwin wrote: On Apr 13 23:03, Eliot Moss via Cygwin wrote: Dear cygwin'ers - I seem to be caught in a bind with the Cygwin permissions setup. ssh insists that ~/.ssh/config have permissions no less permissive than rw--- (600). Huh? No, it doe

Re: Permissions question / issue

On Apr 13 23:03, Eliot Moss via Cygwin wrote: > Dear cygwin'ers - > > I seem to be caught in a bind with the Cygwin permissions setup. > > ssh insists that ~/.ssh/config have permissions no less permissive than > rw--- (600). Huh? No, it doesn't, usually. My file has perms rw-r--r-- (644)

Re: Permissions question / issue

On 4/13/2023 11:03 PM, Eliot Moss via Cygwin wrote: Dear cygwin'ers - I seem to be caught in a bind with the Cygwin permissions setup. ssh insists that ~/.ssh/config have permissions no less permissive than rw--- (600). ---> should have read no *more* permissive (sent too late at night!)

Re: Undeliverable: Cygwin Digest, Vol 38, Issue 22

t;=3D=3D=3D=3D=3D2744155110844989408=3D=3D" >X-GetAbine-Processed: 1 >From: "cygwin.com [Masked]" >Sender: "cygwin.com [Masked]" >Reply-To: fwd.k1zss6pxy...@opayq.com >To: km2z7kca0...@opayq.com >X-GetAbine-Sender: cygwin-bounces+km2z7kca0oge=3dopayq...

Undeliverable: Cygwin Digest, Vol 38, Issue 22

"cygwin.com [Masked]" Reply-To: fwd.k1zss6pxy...@opayq.com To: km2z7kca0...@opayq.com X-GetAbine-Sender: cygwin-bounces+km2z7kca0oge=opayq@cygwin.com X-GetAbine-Disposable: km2z7kca0...@opayq.com X-GetAbine-Host-Address: 23.21.143.60 Subject: Cygwin Digest, Vol 38, Issue 22 Date: Fri, 14

Permissions question / issue

Dear cygwin'ers - I seem to be caught in a bind with the Cygwin permissions setup. ssh insists that ~/.ssh/config have permissions no less permissive than rw--- (600). However, my backup program runs as SYSTEM and needs access. I tried to provide that access by adding an ACL g:SYSTEM:r-x,

Re: Issue with texlive-collection-context

On 4/12/2023 7:54 AM, Vanda Vodkamilkevich via Cygwin wrote: When using setup.exe, I have the following error message : Package: _/Unknown package texlive-collection-context.sh exit code 127 I tried to run the script manually and got: $ sh -x texlive-collection-context.sh + /usr/bin/mtxrun --ge

Issue with ImageMagick

Hi all, The issue is with current installed version of Imagemagick, aka 7.0.10.27-2... Setup.ini shows the following dependencies : sdesc: "Image processing suite (utilities)" ldesc: "ImageMagick is a software suite to create, edit, and compose bitmap images. It can read, co

Issue with texlive-collection-context

When using setup.exe, I have the following error message : Package: _/Unknown package texlive-collection-context.sh exit code 127 I tried to run the script manually and got: $ sh -x texlive-collection-context.sh + /usr/bin/mtxrun --generate texlive-collection-context.sh: ligne 1: /usr/bin/mtxrun:

Re: issue when piping from a windows program

On Tue, 11 Apr 2023 09:15:03 +0200 Leonid Mironov wrote: > I am trying to feed the output of wmic.exe - a windows console program, to > cygwin bash script. > wmic.exe produces UTF16LE output with BOM and CR/LFs, so I am using dos2unix > to convert it. > The problem is that when I write wmic.exe

Re: issue when piping from a windows program

On 2023-04-11 08:43, Andrey Repin via Cygwin wrote: Greetings, Leonid Mironov! I am trying to feed the output of wmic.exe - a windows console program, to cygwin bash script. wmic.exe produces UTF16LE output with BOM and CR/LFs, so I am using dos2unix to convert it. The problem is that when I

Re: issue when piping from a windows program

Greetings, Leonid Mironov! > I am trying to feed the output of wmic.exe - a windows console program, to > cygwin bash script. > wmic.exe produces UTF16LE output with BOM and CR/LFs, so I am using dos2unix > to convert it. > The problem is that when I write wmic.exe output to a file and then use

Re: issue when piping from a windows program

On 11.04.2023 09:15, Leonid Mironov via Cygwin wrote: I am trying to feed the output of wmic.exe - a windows console program, to cygwin bash script. wmic.exe produces UTF16LE output with BOM and CR/LFs, so I am using dos2unix to convert it. The problem is that when I write wmic.exe output to a

issue when piping from a windows program

I am trying to feed the output of wmic.exe - a windows console program, to cygwin bash script. wmic.exe produces UTF16LE output with BOM and CR/LFs, so I am using dos2unix to convert it. The problem is that when I write wmic.exe output to a file and then use dos2unix to convert this file I ge

Re: cygwin gdb: issue with non-posix style absolute paths

ny cases, Cygwin executable may work with Windows paths OOTB, this kind of interoperability is not guaranteed or even promised. Cygwin is "a kind of POSIX" and expectation is that it works with POSIX paths. > AFFECTED USERS > This is especially an issue for developers using Ec

cygwin gdb: issue with non-posix style absolute paths

does not recognize the windows path as beeing absolute and adds the posix-style absolute path to the current working directory as prefix. When using a posix-style absolute path to the executable instead, everything works normally. AFFECTED USERS This is especially an issue for developers

Re: [FEEDBACK] Issue with fd_set, FD_ZERO, FD_SET, FD_SETSIZE : Cygwin

Am 07.02.2023 um 07:59 schrieb Yeo Kai Wei via Cygwin: I think I found the issue, I believe it's due to MinGW's build of gcc (I could be wrong). I downloaded "gcc -core" and it worked. You keep talking of "downloading" and "unpacking" things. That

Re: [FEEDBACK] Issue with fd_set, FD_ZERO, FD_SET, FD_SETSIZE : Cygwin

in:/usr/bin:/bin:/usr/sbin:/sbin:... first in PATH and similar /usr/share/{man,info,awk} /usr/lib/gawk for {MAN,INFO,AWK,AWKLIB}PATH in your preferred shell initialization files e.g. in bash $OSTYPE == "cygwin". Hi Brian, Thank you for the help. I think I found the issue, I believe it

Re: [FEEDBACK] Issue with fd_set, FD_ZERO, FD_SET, FD_SETSIZE : Cygwin

On 2023-02-06 21:28, Yeo Kai Wei via Cygwin wrote: On 7/2/2023 9:54 am, Eliot Moss wrote: On 2/7/2023 11:34 AM, Yeo Kai Wei wrote: On 7/2/2023 7:27 am, Eliot Moss wrote: On 2/7/2023 10:03 AM, Yeo Kai Wei via Cygwin wrote: On 7/2/2023 4:59 am, gs-cygwin@gluelogic.com wrote: On Tue, Feb 07

Re: [FEEDBACK] Issue with fd_set, FD_ZERO, FD_SET, FD_SETSIZE : Cygwin

Ok ... assuming the "Modern C" is more or less POSIX based and does not use things outside the realm of what cygwin supplies, I think the answer is straightforward: Make sure you install every program and every library that the book uses. There's not really such a thing as a "full install" for C

Re: [FEEDBACK] Issue with fd_set, FD_ZERO, FD_SET, FD_SETSIZE : Cygwin

PM To: Yeo Kai Wei ; gs-cygwin@gluelogic.com Cc: cygwin@cygwin.com Subject: Re: [FEEDBACK] Issue with fd_set, FD_ZERO, FD_SET, FD_SETSIZE : Cygwin On 2/7/2023 3:28 PM, Yeo Kai Wei wrote: > > On 7/2/2023 9:54 am, Eliot Moss wrote: >> On 2/7/2023 11:34 AM, Yeo Kai Wei wrote: >>

Re: [FEEDBACK] Issue with fd_set, FD_ZERO, FD_SET, FD_SETSIZE : Cygwin

On 2/7/2023 3:28 PM, Yeo Kai Wei wrote: On 7/2/2023 9:54 am, Eliot Moss wrote: On 2/7/2023 11:34 AM, Yeo Kai Wei wrote: On 7/2/2023 7:27 am, Eliot Moss wrote: On 2/7/2023 10:03 AM, Yeo Kai Wei via Cygwin wrote: On 7/2/2023 4:59 am, gs-cygwin@gluelogic.com wrote: On Tue, Feb 07, 2023 a

Re: [FEEDBACK] Issue with fd_set, FD_ZERO, FD_SET, FD_SETSIZE : Cygwin

On 2/7/2023 2:56 PM, Yeo Kai Wei wrote: On 7/2/2023 9:54 am, Eliot Moss wrote: On 2/7/2023 11:34 AM, Yeo Kai Wei wrote: On 7/2/2023 7:27 am, Eliot Moss wrote: On 2/7/2023 10:03 AM, Yeo Kai Wei via Cygwin wrote: On 7/2/2023 4:59 am, gs-cygwin@gluelogic.com wrote: On Tue, Feb 07, 2023 a

Re: [FEEDBACK] Issue with fd_set, FD_ZERO, FD_SET, FD_SETSIZE : Cygwin

On 7/2/2023 9:54 am, Eliot Moss wrote: On 2/7/2023 11:34 AM, Yeo Kai Wei wrote: On 7/2/2023 7:27 am, Eliot Moss wrote: On 2/7/2023 10:03 AM, Yeo Kai Wei via Cygwin wrote: On 7/2/2023 4:59 am, gs-cygwin@gluelogic.com wrote: On Tue, Feb 07, 2023 at 04:33:53AM +0800, Yeo Kai Wei wrote:

Re: [FEEDBACK] Issue with fd_set, FD_ZERO, FD_SET, FD_SETSIZE : Cygwin

On 7/2/2023 9:54 am, Eliot Moss wrote: On 2/7/2023 11:34 AM, Yeo Kai Wei wrote: On 7/2/2023 7:27 am, Eliot Moss wrote: On 2/7/2023 10:03 AM, Yeo Kai Wei via Cygwin wrote: On 7/2/2023 4:59 am, gs-cygwin@gluelogic.com wrote: On Tue, Feb 07, 2023 at 04:33:53AM +0800, Yeo Kai Wei wrote:

Re: [FEEDBACK] Issue with fd_set, FD_ZERO, FD_SET, FD_SETSIZE : Cygwin

I thought it was the Cygwin GCC. How do I check? From: Eliot Moss Sent: Tuesday, February 7, 2023 9:54:33 AM To: Yeo Kai Wei ; gs-cygwin@gluelogic.com Cc: cygwin@cygwin.com Subject: Re: [FEEDBACK] Issue with fd_set, FD_ZERO, FD_SET, FD_SETSIZE : Cygwin

Re: [FEEDBACK] Issue with fd_set, FD_ZERO, FD_SET, FD_SETSIZE : Cygwin

On 2/7/2023 11:34 AM, Yeo Kai Wei wrote: On 7/2/2023 7:27 am, Eliot Moss wrote: On 2/7/2023 10:03 AM, Yeo Kai Wei via Cygwin wrote: On 7/2/2023 4:59 am, gs-cygwin@gluelogic.com wrote: On Tue, Feb 07, 2023 at 04:33:53AM +0800, Yeo Kai Wei wrote: I updated Cygwin to 3.4.5-1.x86_64. $ u

  1   2   3   4   5   6   7   8   9   10   >