Re: howto rollback cygwin 3.1.4-1 to older 3.0.7 version?

On Wed, 19 Feb 2020 22:02:14, Eugene Klimov wrote: > i'm idiot = ( why I install this new buggy version? > > > The following packages have been uploaded to the Cygwin distribution: > > * cygwin-3.1.4-1 > > * cygwin-devel-3.1.4-1 > > * cygwin-doc-3.1.4-1 > > This is a bugfix release, including a

Re: [ANNOUNCEMENT] cygwin 3.1.0-1

On Wed, 18 Dec 2019 10:23:16, Henning wrote: > On 16/12/2019 20:11, Corinna Vinschen wrote: > > The following packages have been uploaded to the Cygwin distribution: > > > > * cygwin-3.1.0-1 > > * cygwin-devel-3.1.0-1 > > * cygwin-doc-3.1.0-1 > > After cygwin-3.0.7 all attempts to update (to

Re: Solved. Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

Nothing new here; only correction of mistakes that I made (I decided to review my e-mail because Ken Brwon took an interrest in the subject matter). On Fri, 06 Sep 2019 23:53:05, Houder wrote: > To those still interested! :-P [snip] > While I took a closer look at the source code, I found

Re: Solved. Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Sat, 21 Sep 2019 21:02:37, Ken Brown wrote: [snip] > I think you can simplify this by eliminating the second part and changing > the first part to the following: > > char sep = dir[strlen (dir) - 1]; > if (isdirsep (sep) >{ > /* This converts // to

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Sat, 21 Sep 2019 15:42:36, Ken Brown wrote: [snip] > I'll fix this and then look at your patches to mkdir and rmdir. It would > be very helpful if you would write these as a patch series with cover letter, > using git format-patch, and send them to the cygwin-patches list. Hi Ken, I think

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Fri, 20 Sep 2019 09:55:59, Houder wrote: [snip] > So, in general this piece of code should NOT be executed. And I doubt if > it is ever reached in case of a device path, like \\.\e: (did not check). Did check. Using my modified code (and debugger). Yes, the code snippet is reached i

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Thu, 19 Sep 2019 18:04:47, Ken Brown wrote: > On 9/1/2019 1:38 PM, Houder wrote: > > On Fri, 30 Aug 2019 11:54:27, Houder wrote: > > [...] > > > As the directory "/foo" had been correctly created, I turned to > > path_conv::check(), whi

Solved. Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

To those still interested! :-P I expressed surprise that mkdir e:/ does NOT refer to the drive, but rmdir e:/ does. Likewise do ls, stat ... https://cygwin.com/ml/cygwin/2019-08/msg00334.html ( Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ... ) Why could mkdir not be made

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Mon, 2 Sep 2019 10:15:08, Corinna Vinschen wrote: > > On Sep 1 19:38, Houder wrote: > > Hi Corinna, > > > > My last post in this issue. > > > > As reported, Eric's code snippet in rmdir() (dir.cc) has become > > redundant, lines 317 - 325 can be r

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Fri, 30 Aug 2019 11:54:27, Houder wrote: > A trailing forward slash in "pathname" is stripped in path_conv::check, > > (look for: *--tail = '\0' ) > > after "pathname" has been normalized in > > normalized_posix_path or normalized_wi

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Thu, 29 Aug 2019 17:05:41, Houder wrote: > On Wed, 28 Aug 2019 16:22:20, Corinna Vinschen wrote: [snip] > > One problem here is, what to do about border cases like > > > > $ mkdir a\/\/\/ > > > > In theory slashes and backslashes should both be treated

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Wed, 28 Aug 2019 16:22:20, Corinna Vinschen wrote: > > As simple as that? > > > > diff --git a/winsup/cygwin/dir.cc b/winsup/cygwin/dir.cc > > index b757851d5c7f..747b1582af50 100644 > > --- a/winsup/cygwin/dir.cc > > +++ b/winsup/cygwin/dir.cc > > @@ -314,13 +314,13 @@ mkdir (const char

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Wed, 28 Aug 2019 08:33:05, Eric Blake wrote: > On 8/27/19 7:51 AM, Houder wrote: > > > > 64-@@ mkdir 'e:\' # creates subdirectory e: ! > > Had you typed: > > mkdir 'e:/' > > I would expect subdirectory ./e: to be created. But with 'e:\', that >

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Wed, 28 Aug 2019 10:32:27, john doe wrote: > As hinted out in here, backporting the code snippet from mkdir to rmdir > would solve your issue. No, the reverse. Removing the snippet from mkdir() would solve my issue. rmdir() does the right thing; currently, mkdir() does the wrong thing.

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Tue, 27 Aug 2019 11:44:17, Vince Rice wrote: > > On Aug 27, 2019, at 11:28 AM, Houder wrote: > > > > On Tue, 27 Aug 2019 17:25:49, Corinna Vinschen wrote: > >> > >> mkdir(2) has some special code from 2009 which drops trailing > >> {back}s

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Tue, 27 Aug 2019 17:25:49, Corinna Vinschen wrote: > > On Aug 27 14:51, Houder wrote: [snip] > > Now, let's play: > > > > 64-@@ cygpath -w /drv/e > > E:\ > > > 64-@@ mkdir 'e:\' # creates subdirectory e: ! > > 64-@@ rmdir 'e:\' # fails,

Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

L.S., # note: cygdrive has been remapped to /drv at my place 64-%% uname -a CYGWIN_NT-6.1 Seven 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin 64-%% mkdir /drv/e mkdir: cannot create directory ‘/drv/e’: Permission denied 64-@@ uname -a CYGWIN_NT-6.1 Seven 3.1.0(0.340/5/3) 2019-08-19 10:13

Re: Empty file without "x" permission is successfully executable on Cygwin

On Wed, 07 Aug 2019 08:12:28, Houder wrote: > On Tue, 6 Aug 2019 19:09:04, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin" > wrote: > > > zero-sized? Irrelevant. > > > > It is actually very relevant. Because executing an empty script results in= > > &

Re: Win7 system update hosed something in Cygwin

On Fri, 16 Aug 2019 11:43:22, David Karr wrote: > On Fri, Aug 16, 2019 at 7:58 AM Houder wrote: > > > On Fri, 16 Aug 2019 06:40:28, David Karr wrote: [snip] > > > Any other ideas? > > > > 1. cygcheck -srv? (include the compressed output to your reply) >

Re: Win7 system update hosed something in Cygwin

On Fri, 16 Aug 2019 16:58:09, Houder wrote: > On Fri, 16 Aug 2019 06:40:28, David Karr wrote: > > On Fri, Aug 16, 2019 at 2:01 AM Houder wrote: > .. > > > > Please study /etc/profile where it says "here is how HOME is set" ... > > > > > >

Re: Win7 system update hosed something in Cygwin

On Fri, 16 Aug 2019 06:40:28, David Karr wrote: > On Fri, Aug 16, 2019 at 2:01 AM Houder wrote: .. > > Please study /etc/profile where it says "here is how HOME is set" ... > > > > Ok. This says: > > # 1) From existing HOME in the Windows environment,

Re: Win7 system update hosed something in Cygwin

On Thu, 15 Aug 2019 18:28:09, David Karr wrote: > I logged into my Win7 laptop and I saw it was having some connection > problems, so I decided to reboot. > > After the reboot I found that Cygwin had some basic problems. I brought up > a mintty window (C:\cygwin64\bin\mintty.exe -e /bin/bash

Re: getpriority() and top display for priority inconsistent

On Thu, 15 Aug 2019 12:20:38, Corinna Vinschen wrote: > > On Aug 15 09:41, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote: > > > git format-patch output with commit message, please? > >=20 > > Please educate me how to do that; I am just using "git diff --no-color". > > $ git add > $

Re: Did I miss something? cscope v15.9.1 has been released ...

On Sat, 10 Aug 2019 10:36:36, =?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker?= wrote: > Am 10.08.2019 um 10:01 schrieb Houder: > > > Remarkably https://sourceforge.net/projects/cscope/ (news) > > reports v15.8b as the last release ... > > > > ... though v15.9 is men

Did I miss something? cscope v15.9.1 has been released ...

L.S., The mirror show v15.9.1 of cscope ... This version has been released by Jari Aalto ... as far as I can tell. Did I miss the announcement? What changed? Remarkably https://sourceforge.net/projects/cscope/ (news) reports v15.8b as the last release ... ... though v15.9 is mentioned at a

Re: Empty file without "x" permission is successfully executable on Cygwin

On Tue, 6 Aug 2019 19:09:04, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin" wrote: > > zero-sized? Irrelevant. > > It is actually very relevant. Because executing an empty script results in= > "success" (exit code 0) -- that creates a false-positive. Good morning Anton, Sorry for being

Re: Empty file without "x" permission is successfully executable on Cygwin

On Mon, 5 Aug 2019 18:18:52, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin" wrote: > Hi, > > Please consider the following shell session: > > $ cat dummy.c > #include > > int main() > { > return 0; > } > $ gcc -o dummy dummy.c > $ mv dummy.exe dummy > $ ./dummy > $ echo $? > 0 > $

Re: Regression (last snapshot)

On Fri, 2 Aug 2019 14:34:02, Ken Brown wrote: > I think I've finally got it. > > First of all, here's what POSIX says about signal handlers after an exec: > > "Signals set to the default action (SIG_DFL) in the calling process > image shall be set to the default action in the new process

Re: Regression (last snapshot)

On Thu, 1 Aug 2019 12:19:55, Ken Brown wrote: > As I said, the problem only occurs in terminals started from the > xwin-xdg-menu. > That isn't what you did. Here are the reproduction instructions again: Entendu! > 1. Start the X server using the XWin Server shortcut in the Start Menu (look

Re: Regression (last snapshot)

On Thu, 01 Aug 2019 12:03:34, Houder wrote: > On Wed, 31 Jul 2019 15:53:27, Ken Brown wrote: > > > I've made some progress. It turns out that the problem only occurs in > > terminals > > launched from the xwin-xdg-menu tray icon. I can even launch a mintty > &

Re: Regression (last snapshot)

On Wed, 31 Jul 2019 15:53:27, Ken Brown wrote: > I've made some progress. It turns out that the problem only occurs in > terminals > launched from the xwin-xdg-menu tray icon. I can even launch a mintty window > from that icon (System Tools -> Cygwin Terminal) and I'll see the problem. >

Re: Regression (last snapshot)

On Sat, 27 Jul 2019 15:24:49, Ken Brown wrote: > It would be better to be able to debug ls and/or grep, but I don't know how > to > get to subprocesses in gdb. And I think I have to start with 'gdb bash' in > order for the process substitution to happen. Sorry Ken, I cannot help you here

Re: Regression (last snapshot)

On Fri, 26 Jul 2019 22:12:43, Ken Brown wrote: > On 7/22/2019 2:47 PM, Houder wrote: >> The specific regression as reported, has gone. >> >> 64-@@ uname -a >> CYGWIN_NT-6.1 Seven 3.1.0s(0.339/5/3) 2019-07-22 16:43 x86_64 Cygwin >> 64-@@ ls -lL <(grep bash .

Re: Regression (last snapshot)

On Mon, 22 Jul 2019 18:45:09, Corinna Vinschen wrote: [snip] > I pushed a patch and I'm building new developer snapshots right now. > Please give them a try. Thanks Corinna. Thanks Ken. The specific regression as reported, has gone. Regards, Henri 64-@@ uname -a CYGWIN_NT-6.1 Seven

Re: Regression (last snapshot)

On Sun, 21 Jul 2019 11:38:49, Houder wrote: > On Sun, 21 Jul 2019 00:55:51, Houder wrote: > > L.S., > > > > Using the latest snapshot, I now get a complaint from 'ls'; this does > > not happen w/ 3.0.7 > > > > Henri > > > > = 3.0.7: &g

Re: Regression (last snapshot)

On Sun, 21 Jul 2019 00:55:51, Houder wrote: > L.S., > > Using the latest snapshot, I now get a complaint from 'ls'; this does > not happen w/ 3.0.7 > > Henri > > = 3.0.7: > > 64-@@ uname -a > CYGWIN_NT-6.1 Seven 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cyg

Regression (last snapshot)

L.S., Using the latest snapshot, I now get a complaint from 'ls'; this does not happen w/ 3.0.7 Henri = 3.0.7: 64-@@ uname -a CYGWIN_NT-6.1 Seven 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin 64-@@ ls -lL <(grep bash .bashrc) pr 1 Henri None 0 Jul 21 00:49 /dev/fd/63 = snapshot

Re: sigpending() incorrectly returns signals pending on other threads

On Mon, 15 Jul 2019 09:53:27, Corinna Vinschen wrote: > On Jul 14 15:19, Houder wrote: > > .. uhm, just a note in the interest of accuracy ... > > > > - standard signals (which include USRSIG1 and USRSIG2) are not queued > >(traditional signal semantics) &g

Re: sigpending() incorrectly returns signals pending on other threads

On Fri, 12 Jul 2019 17:33:51, Corinna Vinschen wrote: > On Jul 6 19:15, Kenton Varda wrote: > > I found a second problem which may or may not be related: > > If two threads use pthread_kill() to send each other the same signal, > > such that the signal should be separately pending on both

Re: Possible issue with gawk 5.0.1-1: Getting new warnings

Hi, Apparently Corinna V. (the maintainer of gawk) is not available at the moment. On Thu, 11 Jul 2019 11:51:09, Vipul P wrote: > Hello, > > Here is a sample script to invoke awk: > > $ cat ./gawk_error.sh > #!/bin/sh > echo "This:is:a:colon:separated:line:%%%:" | awk '{ > gsub("\\%",

Re: cygwin can not be compiled with gcc 8.3.0

On Fri, 5 Jul 2019 22:33:20, Biswapriyo Nath wrote: [snip] > > cygwin is built using cygport ... > > Is there any docs about it? I don't find the cygwin.cygport file in source > tree. Also I don't use source tarballs, git is my first choice. Also the > configure script or Makefile didn't warn

Re: cygwin can not be compiled with gcc 8.3.0

On Fri, 05 Jul 2019 10:21:49, Houder wrote: [snip] > cygwin is built using cygport ... > > - install the cygport package (subsequently invoke "man cygport" from bash) > - using cygport to build cygwin requires the cygwin.cygport file in the > Cygwin >sour

Re: cygwin can not be compiled with gcc 8.3.0

On Fri, 5 Jul 2019 13:15:46, Biswapriyo Nath wrote: [snip] > Am I doing anything wrong? I have installed all the required .. uhm, sort of ... [1] is deprecated cygwin is built using cygport ... - install the cygport package (subsequently invoke "man cygport" from bash) - using cygport to

Re: Question about packaging and cygport

On Fri, 28 Jun 2019 14:01:45, Adam Dinwoodie wrote: [snip] > have uploaded to provide via the packaging distribution mirrors. Some > maintainers will keep their cygport files on GitHub or similar (I do), > but that's entirely down to the preferences of the individual > maintainer, and I don't

Re: Dragging from explorer to cygwin terminal is not putting the path into the terminal

On Fri, 7 Jun 2019 09:41:45, Thomas Wolff wrote: > Am 07.06.2019 um 01:04 schrieb Houder: [snip] > > I cannot say anything sensible about the 2 scripts you have executed. Sorry. > > > > But I am afraid, that you may have to start from scratch again (reinstalling > >

Re: Dragging from explorer to cygwin terminal is not putting the path into the terminal

On Thu, 6 Jun 2019 15:26:25, Academy OfFetishes wrote: > inline > > On Thu, Jun 6, 2019 at 12:56 PM Houder wrote: > > > On Thu, 6 Jun 2019 10:56:28, Academy OfFetishes wrote: > > > > > Well first of all, is this feature supposed to work by default

Re: Dragging from explorer to cygwin terminal is not putting the path into the terminal

On Thu, 6 Jun 2019 10:56:28, Academy OfFetishes wrote: > Well first of all, is this feature supposed to work by default or is it > something you turn on? Yes. > > > > What did you try? Something that can give us (and you) a clue ... > > > I tried dragging a file to the terminal. That is not

Re: Dragging from explorer to cygwin terminal is not putting the path into the terminal

On Wed, 5 Jun 2019 21:26:06, Academy OfFetishes wrote: > Hello, Hello to you. > I tried to google for this but couldn't find anyone with the same problem. > I'm using mintty 3.0.1 and cygwin 3.0.7(0.338/5/3). > > On my previous computer, if I dragged a file from my explorer to the cygwin >

Re: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

On Tue, 4 Jun 2019 22:04:16, Vince Rice wrote: > It's cygport, he doesn't have to know about compiling C. ... Vince, this utter nonsense, and you know it! Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation:

Re: Why is __unix__ defined, and not __WINDOWS__ ?

On Sun, 12 May 2019 22:40:48, Brian Inglis wrote: > On 2019-05-12 14:54, Houder wrote: > > On Sun, 12 May 2019 13:33:30, Mike Gran via cygwin" wrote: > > >> I think these days the canonical defines are (somebody correct me if > >> I'm wrong) > >>

Re: Why is __unix__ defined, and not __WINDOWS__ ?

On Sun, 12 May 2019 23:59:55, Houder wrote: [snip] > But if you were thinking of a "mixed" executable (be careful), then > the _WIN* mnemonics will be defined by gcc/g++. using gcc/g++ -- -- Problem reports: http://cygwin.com/p

Re: Why is __unix__ defined, and not __WINDOWS__ ?

On Sun, 12 May 2019 20:22:36, Agner Fog wrote: > I have noticed that the gcc and clang compilers have defined the > preprocessing macro __unix__, but not __WINDOWS__, _WIN32, or _WIN64 > when compiling a windows executable. > > Why is this? > > A C/C++ program will check for these macros if

Re: Why is __unix__ defined, and not __WINDOWS__ ?

On Sun, 12 May 2019 13:33:30, Mike Gran via cygwin" wrote: [snip] > I think these days the canonical defines are (somebody correct me if > I'm wrong) > > __CYGWIN__ for Cygwin > > _WIN32 as 1 on MinGW when the compilation target is Windows 32-bit > ARM, 64-bit ARM, x86, or x64.

Re: Why is __unix__ defined, and not __WINDOWS__ ?

On Sun, 12 May 2019 20:22:36, Agner Fog wrote: > I have noticed that the gcc and clang compilers have defined the > preprocessing macro __unix__, but not __WINDOWS__, _WIN32, or _WIN64 > when compiling a windows executable. > > Why is this? > > A C/C++ program will check for these macros if

Setup.exe: solution to misbehaviour

L.S., Setup.exe writes "user defaults" to /etc/setup/setup.rc in the root directory. Among these user defaults (which should override program defaults) are "last-action" and "last-cache". last-cache is an alias for the Local Package Directory (abbreviated to local directory), the directory

Setup.exe: BUG.

L.S., While implementing a solution for the problem described here: https://cygwin.com/ml/cygwin/2019-04/msg00032.html ( Setup: why consult registry (rootdir) if -R has been specified? ) I discovered a bug in main.cc (setup.exe). At startup, setup.exe writes the following report to

Re: RE: Unattended installation with locally downloaded packages

On Thu, 4 Apr 2019 09:13:35, X wrote: > Hi > > we are trying to install Cygwin 2.11.2 with the following command line: > > setup-x86_64 -q -L -R "C:\Program Files\Cygwin" -l c:\Temp\Packages > > Where -q should be the Silent Installation ... Which packages? add -P ,, ... Henri

setup: why consult registry (rootdir) if -R has been specified?

Hi Jon, My question is about setup.exe. Why does setup _initially_ consult rootdir in registry if -R has been specified ? (and yes, there is an installation at the rootdir that I specify w/ the -R option) This is my workflow: - I use a shortcut to invoke setup.exe - my shortcut specifies

Regression: errno returned by seteuid and companions incorrect

Corinna, As result of the removal of create_token() (sec_auth.cc) in the call flow of seteuid32(), something like: @@ cat seteuid.c int main() { errno = 0; if (seteuid( (uid_t)1004) != 0) { // 1004 = uid of different user printf("seteuid: errno = %d, errstr = %s\n", errno,

Re: Problems with "Hello, World!"

On Sat, 23 Mar 2019 09:33:10, Houder wrote: > On Sat, 23 Mar 2019 09:16:53, Houder wrote: > > > Q: where is your compiler (gcc)? Evidently you are not using the compiler > > from the 64-bits setup ... > > > > Btw, you are using an old version of Cygwi

Re: Problems with "Hello, World!"

On Sat, 23 Mar 2019 09:16:53, Houder wrote: > Q: where is your compiler (gcc)? Evidently you are not using the compiler > from the 64-bits setup ... > > Btw, you are using an old version of Cygwin (cygwin1.dll) ... Why do you > not update (while also installing the

Re: Problems with "Hello, World!"

On Fri, 22 Mar 2019 16:25:08, Vesa P dot " wrote: > > Rather than describing what you did, copy and paste a shell transcript > > showing > > the commands and output from you listing the source code, compiling and > > running > > it, a long listing of the directory contents, then run > > > >

Re: rsync failed after windows 10 update

On Sat, 16 Mar 2019 06:26:05, jwang wrote: > rsync -vvv /tmp/test2.log /tmp/tmp/ > rsync: pipe: Connection timed out (116) > rsync error: error in IPC code (code 14) at pipe.c(122) [sender=3.1.2] > [sender] _exit_cleanup(code=14, file=pipe.c, line=122): about to call > exit(14) > > rsync used

Re: rsync failed after windows 10 update

On 2019-03-16 13:45, Houder wrote: On Sat, 16 Mar 2019 03:49:27, jwang wrote: rsync /tmp/test.log /cygdrive/c/temp/ rsync: pipe: Connection timed out (116) rsync error: error in IPC code (code 14) at pipe.c(122) [sender=3.1.2] cygcheck.txt <http://cygwin.1069669.n5.nabble.com/file/t11

Re: rsync failed after windows 10 update

On Sat, 16 Mar 2019 03:49:27, jwang wrote: > rsync /tmp/test.log /cygdrive/c/temp/ > rsync: pipe: Connection timed out (116) > rsync error: error in IPC code (code 14) at pipe.c(122) [sender=3.1.2] > > cygcheck.txt Based on the

Re: rsync failed after windows 10 update

On Sat, 16 Mar 2019 01:36:38, jwang wrote: > strace showed that it hangs after calling wsock_init > > --- Process 33244 loaded C:\Windows\System32\ws2_32.dll at 7ff98c3b > 3892 199371 [main] rsync 1839 wsock_init: res 0 > 217 199588 [main] rsync 1839 wsock_init: wVersion 514 >88

Re: sshd: fatal: seteuid XXX : No such device or address

On Fri, 15 Mar 2019 21:41:22, Corinna Vinschen wrote: > On Mar 15 20:39, Houder wrote: > > On Fri, 15 Mar 2019 14:42:47, Corinna Vinschen wrote: [snip] > > > Well, there *is* a solution by using strace. And hey, we now know what > > > ENXIO returned from set

Re: sshd: fatal: seteuid XXX : No such device or address

On Fri, 15 Mar 2019 14:42:47, Corinna Vinschen wrote: > On Mar 15 14:06, Houder wrote: > > One is forced to create the exact same environment (system) as the > > person who is complaining, fire up the debugger (like sticking > > a thermometer in a patient's rear end) in or

Re: sshd: fatal: seteuid XXX : No such device or address

On Thu, 14 Mar 2019 18:29:18, Corinna Vinschen wrote: > On Mar 14 16:53, Houder wrote: > > On Thu, 14 Mar 2019 12:39:30, X wrote: > > > Hello the list [snip] > > > sshd: PID 3777: fatal: seteuid 1049076: No such device or address > > Corinna, > > >

Re: rsync problem -- just times out -- rsync or cygwin ?

On Thu, 14 Mar 2019 09:42:24, jwang wrote: > Hi, > > Has your issue been resolved please? If "Yes", how please? Mine is not yet Hi james, Your post is non-sensical ... You forget, that YOU have to be our eyes and to a considerable amount our brains, before we can help you. Your system and

Re: sshd: fatal: seteuid XXX : No such device or address

On Thu, 14 Mar 2019 12:39:30, X wrote: > Hello the list, > > Thanks for all the work and effort put into this. > Since two days i cannot login anymore (password less) with ssh into my > server > > Server is : > Microsoft Windows Server 2012 R2 Essentials / 6.3.9600 N/A version 9600 > >

Re: seteuid problem with sshd

On Wed, 13 Mar 2019 19:26:11, Bruce Halco wrote: > I'm having to update a number of cygwin installations that are about a > year old (cygwin 2.9.0-3). Usually I just run the installer and > everything goes fine.  Occasionally I've run into a problem and had to > remove the existing

Re: Privilege(s) needed to run top command

On Tue, 12 Mar 2019 18:13:39, Corinna Vinschen wrote: > On Mar 12 10:00, jwang wrote: > > Sir, > > Nope. > > > I download, this morning: > > 3132 -rw-r--r-- 1 james None 3207004 Mar 12 10:50 cygwin-20190312.tar.xz (Sigh) James, please, please, read this:

Re: Privilege(s) needed to run top command

On Tue, 12 Mar 2019 04:55:01, jwang wrote: > After last weekend update, I believe I had already the latest version > installed: > > lc cygwin1.dll|xargs ls -lsa > 3412 -rwxr-xr-x 1 admin None 3489952 Mar 5 18:59 /bin/cygwin1.dll > 3412 -rwxr-xr-x 1 admin None 3489952 Mar 5 18:59

Re: [ANNOUNCEMENT] cygwin 3.0.3-1

On Sat, 9 Mar 2019 21:26:32, Ken Brown wrote: > On 3/9/2019 2:32 PM, Corinna Vinschen wrote: > > The following packages have been uploaded to the Cygwin distribution: > > > > * cygwin-3.0.3-1 > > * cygwin-devel-3.0.3-1 > > * cygwin-doc-3.0.3-1 > > It looks like this has been uploaded only for

Re: rsync failed after windows 10 update

On Fri, 8 Mar 2019 06:53:08, jwang wrote: > I saw: > 6296 0 0 6296 ? 0 Mar 4 C:\Program Files > (x86)\Citrix\ICA Client\redirector.exe > > Not sure if this is cause, nor if it was included by Windows update. > > Is it safe to remove it please? Rename, not

Re: Cygwin 3.0.1-1 Breaks ALL cygwin applications on Windows 7 x64

On Tue, 26 Feb 2019 18:01:27, Jerry Baker via cygwin" wrote: > Trying to think of what could make 2.11.x work and 3.0.1 fail on the i7 > system. The only difference I can think of is that the i7 system is a > member of a domain. (first I would suggest a good night's sleep :-) If you really

Re: Cygwin 3.0.1-1 Breaks ALL cygwin applications on Windows 7 x64

> On 2/26/2019 7:38 AM, Jerry Baker via cygwin wrote: > > I have a large installation of cygwin on Windows 7 x64 for the last > > decade that has been working without issue. When I use setup-x86_64.exe > > (2.895) to upgrade the cygwin 2.11.2-1 package to cygwin 3.0.1-1, all of > > my cygwin

Re: can't access remote shares when using ssh with rsa key - passwd -R / set(e)uid / LogonUser is not working as expected

On Tue, 26 Feb 2019 18:01:18, Andrey Repin wrote: > Greetings, Maayan Apelboim! > > > Hi, > > > I hope I'm mailing the proper mailing list.. > > I am using password-less ssh login using RSA key to login windows servers > > from linux. > > I've read this article about network shares problems

Re: problem with mmap and fork()

On Sat, 23 Feb 2019 05:54:18, Doug Henderson wrote: > On Fri, 22 Feb 2019 at 17:01, Glyn Gowing <> wrote: > > I have a program (attached) that works correctly on my mac but does > > not work with Cygwin on Windows 10. I'm running the latest version of [snip] > On further analysis, the call to >

Re: problem with mmap and fork()

On Sat, 23 Feb 2019 05:54:18, Doug Henderson wrote: > On Fri, 22 Feb 2019 at 17:01, Glyn Gowing <> wrote: > > I have a program (attached) that works correctly on my mac but does > > not work with Cygwin on Windows 10. I'm running the latest version of [snip] > On further analysis, the call to >

Re: cygwin 3.0.1-1 breaks my sshd install

On Thu, 21 Feb 2019 11:09:11, Corinna Vinschen wrote: > I managed it today already but I'm somewhat stumped. > > I ran ssh-host-config and let the script install a new local account > "test_server" to use for the sshd service. I started the service and > tried to login with a local account and

Re: cygwin 3.0.1-1 breaks my sshd install

On Wed, 20 Feb 2019 23:38:17, Corinna Vinschen wrote: > On Feb 20 23:25, Houder wrote: > > As a final step I rebooted my system (W7, 64 bits, Uising 64-bits Cygwin). > > > > I can still connect to the localhost w/ ssh ... > > > > But I cannot start and stop t

Re: cygwin 3.0.1-1 breaks my sshd install

On Wed, 20 Feb 2019 23:01:01, Houder wrote: > On Wed, 20 Feb 2019 22:41:08, Corinna Vinschen wrote: > > > On Feb 20 22:35, Houder wrote: > [snip] > > > > > > > Perhaps I missed something in the last couple of month. Did I have > > > to change > &

Re: cygwin 3.0.1-1 breaks my sshd install

On Wed, 20 Feb 2019 22:41:08, Corinna Vinschen wrote: > On Feb 20 22:35, Houder wrote: [snip] > > > > Perhaps I missed something in the last couple of month. Did I have > > to change > > something in the setup of openssh? > > I really don't know, this all

Re: cygwin 3.0.1-1 breaks my sshd install

On Wed, 20 Feb 2019 21:27:22, Andy Moreton wrote: > I've seen a similar failure, on a domain-joined Windows 10 box running > cygsshd using a local cyg_server user account. I've fixed it by: > 1) Open the "Computer Management" app >Select "Services and Applications", then "Services", and >

Re: cygwin 3.0.1-1 breaks my sshd install

On Wed, 20 Feb 2019 21:25:36, Corinna Vinschen wrote: > Sorry guys, but I can't reproduce this problem at all. I tested ssh > login on Vista, W7 and W10 1809, in each case on 64 bit and under > WOW64. On all systems I can login with domain as well as local > accounts. Understood. > For

Re: cygwin 3.0.1-1 breaks my sshd install

On Wed, 20 Feb 2019 10:53:09, scowles at ckhb dot org wrote: > > i can confirm the same behaviours on a 3.0.0 system. i've done several > checks > and have been unable to find the source of the problem. ssh -vvv shows that > the > connection proceeds all the way through the connection

Re: ssh confused about home directory?

On Tue, 19 Feb 2019 19:24:38, Boylan, Ross" wrote: > [Answering my own question after better searching] > Same question asked and answered in the thread starting https://cygwin.com/= > ml/cygwin/2016-06/msg00400.html. > The answer is to set db_home in nsswitch.conf. > > Comment: the current

Re: antrun versus wsl versus cygwin

On Mon, 18 Feb 2019 13:15:02, Franz Fehringer wrote: > Am 18.02.2019 um 11:42 schrieb Houder: [snip] > > Now show us the output of an antrun script, where the executable > > is C:\Tools\Cygwin\bin\which and its argument: bash > > > > > > > > &g

Re: antrun versus wsl versus cygwin

On Mon, 18 Feb 2019 14:39:11, Franz Fehringer wrote: > Am 18.02.2019 um 14:07 schrieb Houder: > > On Mon, 18 Feb 2019 13:15:02, Franz Fehringer wrote: [snip] > >> > >> > >> > >> > >> > >> > >> > >> gives

Re: antrun versus wsl versus cygwin

On Mon, 18 Feb 2019 13:15:02, Franz Fehringer wrote: > Am 18.02.2019 um 11:42 schrieb Houder: [snip] > > Now show us the output of an antrun script, where the executable > > is C:\Tools\Cygwin\bin\which and its argument: bash > > > > Henri > > > &g

Re: [ANNOUNCEMENT] Cygwin 3.0.0-1

On Mon, 18 Feb 2019 14:01:40, Andrey Repin wrote: [snip] > The snapshot only contains a lonely cygwin1.dll. You have to download the tar(.xz) file ... See faq for further details. Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/

Re: antrun versus wsl versus cygwin

On Mon, 18 Feb 2019 10:25:42, Franz Fehringer wrote: in the antrun block gives C:\Projekte\dev\bin\gmake41;\ C:\Tools\VisualStudio\2017\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64;\ C:\Tools\VisualStudio\2017\VC\VCPackages;\ C:\Tools\VisualStudio\2017\MSBuild\15.0\bin\Roslyn;\

Re: antrun versus wsl versus cygwin

On Sun, 17 Feb 2019 12:11:28, Franz Fehringer wrote: > Hi all (half off topic), Not a Cygwin topic at all, I am guessing ... > I have installed (on a Windows 10 1809 system) both Cygwin and WSL (only > the Windows component, no real Linux distribution yet). > This scenario gives me a strange

Re: /dev/fd/N not synonymous with file descriptor N; it is on Linux

On Sun, 27 Jan 2019 22:57:21, Corinna Vinschen wrote: > > On Jan 27 19:39, Houder wrote: > > NO BLODA. > > > > Ok, for the record (as this is W7, i.e. pre-pre-W10 :-) > > > > Using my original STC again: (source code included below) > > > >

Re: /dev/fd/N not synonymous with file descriptor N; it is on Linux

On Tue, 22 Jan 2019 11:39:28, Corinna Vinschen wrote: > > On Jan 22 11:20, Houder wrote: > > On Tue, 22 Jan 2019 10:41:57, Corinna Vinschen wrote: > > > On Jan 22 10:25, Houder wrote: > > [snip] > > > > > > Curious! It fails (for me) on W7 ... &

Re: /dev/fd/N not synonymous with file descriptor N; it is on Linux

On Tue, 22 Jan 2019 10:41:57, Corinna Vinschen wrote: > On Jan 22 10:25, Houder wrote: [snip] > > Curious! It fails (for me) on W7 ... > > It works for me just as well on W7: > > $ uname -a > CYGWIN_NT-6.1 vmbert764 2.12.0(0.333/5/3) 2019-01-21 22:47 x86_64 Cygwin >

Re: /dev/fd/N not synonymous with file descriptor N; it is on Linux

On 2019-01-22 10:06, Corinna Vinschen wrote: On Jan 22 09:57, Houder wrote: On 2019-01-22 09:50, Houder wrote: > On Sun, 6 Jan 2019 21:19:50, Corinna Vinschen wrote: > > This should work in the latest developer snapshot uploaded to > > https://cygwin.com/snapshots/ Please give

Re: /dev/fd/N not synonymous with file descriptor N; it is on Linux

On 2019-01-22 09:50, Houder wrote: On Sun, 6 Jan 2019 21:19:50, Corinna Vinschen wrote: On Dec 16 17:31, Houder wrote: > L.S., > > /dev/fd/N not synonymous with file descriptor N; it is on Linux > > 64-@@ cat /dev/fd/0 <<\EOF > > Hi > > EOF > cat:

  1   2   3   4   5   >