Hi David,
On Oct 22 18:19, David Bean wrote:
> Hello Corrina,
s/rrin/rinn/ ;)
>> From: Corinna Vinschen
>> Hi David,
>>
>> On Oct 22 15:56, David Bean wrote:
>> > Good Day,
>> >
>> > I have been working on porting Samba 4.11 to Cygwin for a few days
>> > and ran into an odd issue. Samba configu
@cygwin.com
Subject: Re: Possible bug retrieving IfIndex in newlib - winsup/cygwin/net.cc
Hi David,
On Oct 22 15:56, David Bean wrote:
> Good Day,
>
> I have been working on porting Samba 4.11 to Cygwin for a few days and ran
> into an odd issue. Samba configures its interfaces in s
Hi David,
On Oct 22 15:56, David Bean wrote:
> Good Day,
>
> I have been working on porting Samba 4.11 to Cygwin for a few days and ran
> into an odd issue. Samba configures its interfaces in several steps, but it
> relies pretty heavily on getting information from the interface structures
> p
Good Day,
I have been working on porting Samba 4.11 to Cygwin for a few days and ran into
an odd issue. Samba configures its interfaces in several steps, but it relies
pretty heavily on getting information from the interface structures populated
by Cygwin. While I was walking through the call m
Hi,
It looks like there is a bug in clang in cygwin when using optimizations
(found by a contributor). You can find details on
https://github.com/aircrack-ng/aircrack-ng/issues/1835
Here is his comment in question:
---
After thoroughly researching this matter, I settled on a
less-than-ideal,
On 2018-02-08 20:51, Ameya Vikram Singh wrote:
> I tried the latest ViM package(vim-8.0.1428-1).
> Even the current version has the same problem.
>
> I do have the **ruby** runtime libraries installed and even the
> development headers package also installed.
Confirmed. The configure script chan
Hello,
I tried the latest ViM package(vim-8.0.1428-1).
Even the current version has the same problem.
I do have the **ruby** runtime libraries installed and even the
development headers package also installed.
The only known latest version supported was vim-8.0.1157-1 which
currently has been re
On 2018-02-06 09:37, Ameya Vikram Singh wrote:
> Maintainers of the ViM/GViM text editor.
> I am noticing that currently with the latest build of ViM
> editor(vim-8.0.1376-1),
> I am unable to use the command-t [1] plugin with this release.
> When invoking the functionality with the key combination
Hello,
Maintainers of the ViM/GViM text editor.
I am noticing that currently with the latest build of ViM
editor(vim-8.0.1376-1),
I am unable to use the command-t [1] plugin with this release.
When invoking the functionality with the key combination: `\` + `t`
I get the following error message o
On Mar 12 15:49, Marco Atzeri wrote:
> On 12/03/2017 12:39, Corinna Vinschen wrote:
> > On Mar 12 00:33, Josef Frank wrote:
> > >
> > > Dear all,
> > >
> > >
> > > dd utility has problems to write to /dev/null with bs>=2^31,
> > > while bs<2^31 is ok.
> > >
> > > Increasing bs further to 2^33 l
On 12/03/2017 12:39, Corinna Vinschen wrote:
On Mar 12 00:33, Josef Frank wrote:
Dear all,
dd utility has problems to write to /dev/null with bs>=2^31,
while bs<2^31 is ok.
Increasing bs further to 2^33 leads to extended error message
For description see below
Thanks for the testcase. It
On Mar 12 00:33, Josef Frank wrote:
>
> Dear all,
>
>
> dd utility has problems to write to /dev/null with bs>=2^31,
> while bs<2^31 is ok.
>
> Increasing bs further to 2^33 leads to extended error message
>
> For description see below
Thanks for the testcase. It's a combination of two bugs:
Dear all,
dd utility has problems to write to /dev/null with bs>=2^31,
while bs<2^31 is ok.
Increasing bs further to 2^33 leads to extended error message
For description see below
jf
Steps to reproduce:
$ dd if=/dev/zero of=/dev/null bs=2147483647 count=1
1+0 records in
1+0 records ou
Greetings, cyg Simple!
> On 3/24/2016 11:43 AM, Dirk Fassbender wrote:
>> Am 24.03.2016 um 15:12 schrieb Unknown Sender:
>>> I noticed this bug for the first time today on a computer that has the
>>> computer name "-" (dash).
>>>
>>> During ssh-host-config:
>>> *** Query: Do you want to use a diff
On Thu, Mar 24, 2016 at 5:45 PM, cyg Simple wrote:
> > the computer name "-" (dash) is illegal in the internet.
>
> Uh, that isn't true.
Yes, it is true.
> > See
> > https://en.wikipedia.org/wiki/Hostname
> > for a start about host name definitions.
> >
>
> From this reference:
> "The Internet st
On 24/03/2016 22:45, cyg Simple wrote:
On 3/24/2016 11:43 AM, Dirk Fassbender wrote:
Am 24.03.2016 um 15:12 schrieb Unknown Sender:
I noticed this bug for the first time today on a computer that has the
computer name "-" (dash).
See
https://en.wikipedia.org/wiki/Hostname
for a start about h
On 3/24/2016 11:43 AM, Dirk Fassbender wrote:
> Am 24.03.2016 um 15:12 schrieb Unknown Sender:
>> I noticed this bug for the first time today on a computer that has the
>> computer name "-" (dash).
>>
>> During ssh-host-config:
>> *** Query: Do you want to use a different name? (yes/no) no
>> /usr/
Am 24.03.2016 um 15:12 schrieb Unknown Sender:
I noticed this bug for the first time today on a computer that has the computer name
"-" (dash).
During ssh-host-config:
*** Query: Do you want to use a different name? (yes/no) no
/usr/bin/getent: invalid option -- '+'
Try `getent --help' or `gete
I noticed this bug for the first time today on a computer that has the computer
name "-" (dash).
During ssh-host-config:
*** Query: Do you want to use a different name? (yes/no) no
/usr/bin/getent: invalid option -- '+'
Try `getent --help' or `getent --usage' for more information.
*** Query: Crea
On Thu, Sep 10, 2015 at 8:36 PM, Qian Hong wrote:
> I'm not the person to answer this, but I can confirm same behavior here.
Oh, sorry, I mean it might not be a gcc bug, instead it might be a bug
of gdb who didn't translate double quotes correctly.
--
Regards,
Qian Hong
-
http://www.winehq.or
Hi,
On Thu, Sep 10, 2015 at 8:21 PM, Sebastian Götzinger
wrote:
> During that, we encountered, that during the compilerinvocation, the
> Doublequotes did not got escaped correctly. [1]
I'm not the person to answer this, but I can confirm same behavior here.
On Linux:
$ gdb --args bash -c "bash
Dear Ladies and Gentlemen,
We had some issues with our program (a wrapper for compiler).
Somehow, not all arguments have been transported correctly to the compiler.
We now bootstrapped gcc-5.2.0 and let it run alone with gdb for cygwin.
During that, we encountered, that during the compilerinvo
On 2015-08-04, Xealot wrote:
> Hello!
> There seems to be a possible bug with cygwin 2.2.0 in xterm terminal
> mode (default) and using vim 7.4.764 with syntax highlighting enabled.
>
> To verify and reproduce:
> echo "syntax on" >> ~/.vimrc
> vim -E
>
&g
Hello!
There seems to be a possible bug with cygwin 2.2.0 in xterm terminal
mode (default) and using vim 7.4.764 with syntax highlighting enabled.
To verify and reproduce:
echo "syntax on" >> ~/.vimrc
vim -E
The prompt at the bottom should now show an escape sequence:
Enterin
Hi Cary,
On Apr 27 22:52, Cary R. wrote:
> The following code:
>
> #include
> #include
>
> int main()
> {
> int32_t ival = 1;
> uint32_t uval = 2;
>
> printf("int = %"PRId32", uint = %"PRIu32".\n", ival, uval);
> return 0;
> }
>
>
> when compiled with either
The following code:
#include
#include
int main()
{
int32_t ival = 1;
uint32_t uval = 2;
printf("int = %"PRId32", uint = %"PRIu32".\n", ival, uval);
return 0;
}
when compiled with either gcc or clang on a 32-bit system and with the -Wall
flag produces the foll
On Apr 14 14:54, Pavel Fedin wrote:
> Hello!
>
> I decided to try to return to my GNU make patch making use of spawn() on
> Cygwin. Since upstream project refused to cooperate, i use my own patched
> version of Make. And i came across a problem. When spawn() is used,
> sub-process fails to proce
Hello!
I decided to try to return to my GNU make patch making use of spawn() on
Cygwin. Since upstream project refused to cooperate, i use my own patched
version of Make. And i came across a problem. When spawn() is used,
sub-process fails to process Ctrl-C. Ctrl-C is simply ignored. If i want t
Looking at the source, I may be able to address my own questions/points.
On 09/29/2014 10:21 PM, Brian Ericson wrote:
Cygwin appears to ignore "winsymlinks:native" when asked to create a
symbolic link to a non-existent target, reverting to its "magic header"
approach.
This is true...
Shouldn't
Cygwin appears to ignore "winsymlinks:native" when asked to create a
symbolic link to a non-existent target, reverting to its "magic header"
approach.
This can be demonstrated via the following examples (using a Cygwin shell):
echo hello > aaa
ln -s aaa bbb
notepad bbb
ln -s xxx yyy
-Original Message-
From: Robert Bu
Sent: 2014/4/21 9:59 +0800
On Apr 16 17:47, Corinna Vinschen wrote:
> > Below is what I get:
> > RS-I9E3U8R4:[~/tmp/test_symlink]>uname -a
> > CYGWIN_NT-6.1 RS-I9E3U8R4 1.7.29(0.272/5/3) 2014-04-07 13:46 x86_64
Cygwin
> > RS-I9E3U8R4:[~/tmp/t
> On Apr 16 17:47, Corinna Vinschen wrote:
> > > Below is what I get:
> > > RS-I9E3U8R4:[~/tmp/test_symlink]>uname -a
> > > CYGWIN_NT-6.1 RS-I9E3U8R4 1.7.29(0.272/5/3) 2014-04-07 13:46 x86_64
> Cygwin
> > > RS-I9E3U8R4:[~/tmp/test_symlink]>echo $CYGWIN
> > > winsymlinks:nativestrict
> >
On Apr 16 17:47, Corinna Vinschen wrote:
> On Apr 16 03:39, 卜勇华 wrote:
> > Hi Corinna,
>
>
> Please don't top-post. Thank you.
>
>
> > Below is what I get:
> > RS-I9E3U8R4:[~/tmp/test_symlink]>uname -a
> > CYGWIN_NT-6.1 RS-I9E3U8R4 1.7.29(0.272/5/3) 2014-04-07 13:46 x86_64 Cygwin
> > RS-I9E3U8
On Apr 16 03:39, 卜勇华 wrote:
> Hi Corinna,
Please don't top-post. Thank you.
> Below is what I get:
> RS-I9E3U8R4:[~/tmp/test_symlink]>uname -a
> CYGWIN_NT-6.1 RS-I9E3U8R4 1.7.29(0.272/5/3) 2014-04-07 13:46 x86_64 Cygwin
> RS-I9E3U8R4:[~/tmp/test_symlink]>echo $CYGWIN
> winsymlinks:nativestrict
On Apr 15 01:07, 卜勇华 wrote:
> Hi,
>
> It seems that cygwin cannot follow the Windows native symlink correctly.
> set CYGWIN=winsymlinks:nativestrict
>
> Steps to re-produce:
> 1. echo test > test.txt
> 2. mkdir dest
> 3. cd dest
> 4. ln -s ../test.txt test.txt
> 5. cd ..
> 6. mkdir src
> 7. cd sr
Hi,
It seems that cygwin cannot follow the Windows native symlink correctly.
set CYGWIN=winsymlinks:nativestrict
Steps to re-produce:
1. echo test > test.txt
2. mkdir dest
3. cd dest
4. ln -s ../test.txt test.txt
5. cd ..
6. mkdir src
7. cd src
8. ln -s ../dest dest
9. cd ..
10. cat src/dest/test
Greetings, Dave Kilroy!
> -1 mode fails because fish would prefer cygpath was run on the argument
> first. I'm not sure why this works in bash.
Because bash know what is going on. In fact, many cygwin tools recognize
native paths.
> I'll try put together a fix for the latter issue, but it may be
On 10/04/2014 11:06, Ronald Fischer wrote:
I've had more time to look around. If you add the following to the file
~/.config/fish/config.fish (create it if you haven't already got one),
then things should work as intended:
if status --is-login
set PATH /usr/local/bin /usr/bin $PATH
end
> I've had more time to look around. If you add the following to the file
> ~/.config/fish/config.fish (create it if you haven't already got one),
> then things should work as intended:
>
> if status --is-login
> set PATH /usr/local/bin /usr/bin $PATH
> end
>
> Alternatively drop it in th
> I've had more time to look around. If you add the following to the file
> ~/.config/fish/config.fish (create it if you haven't already got one),
> then things should work as intended:
>
> if status --is-login
> set PATH /usr/local/bin /usr/bin $PATH
> end
>
> Alternatively drop it in th
On Tue, Apr 8, 2014, at 0:35, Dave Kilroy wrote:
> On 07/04/2014 13:02, Ronald Fischer wrote:
> > I have installed fish 2.1.0. Works fine, when invoking a new fish shell
> > manually.
> >
> > However, when doing a
> >
> > chere -ifcm -t mintty -s fish
> >
> > and invoke the new fish shell from
On 07/04/2014 23:35, Dave Kilroy wrote:
On 07/04/2014 13:02, Ronald Fischer wrote:
I have installed fish 2.1.0. Works fine, when invoking a new fish shell
manually.
However, when doing a
chere -ifcm -t mintty -s fish
and invoke the new fish shell from the Windows Explorer context menu, I
On 07/04/2014 13:02, Ronald Fischer wrote:
I have installed fish 2.1.0. Works fine, when invoking a new fish shell
manually.
However, when doing a
chere -ifcm -t mintty -s fish
and invoke the new fish shell from the Windows Explorer context menu, I
get plenty of error messages, like this:
On Thu, Aug 01, 2013 at 01:38:07PM +0400, Andrey Repin wrote:
>Greetings, starlight.2013z3!
>>Some people like myself cannot abide subscribing to firehose mailing
>>lists and prefer to view discussion threads with a browser. It does
>>not mean contributors, direct or indirect, are any of value. E
Greetings, starlight.201...@binnacle.cx!
> Some people like myself cannot abide subscribing
> to firehose mailing lists and prefer to view
> discussion threads with a browser. It does not
> mean contributors, direct or indirect, are any
> of value. Even if I were a direct contributor
> monitori
Fixes the CTRL-C problem and the point
behind it all, running a critical build
script, work as well.
>
>stephan($0.02);
>
>-Original Message-
>From: cygwin-owner at cygwin dot com
>On Behalf Of starlight.2013z3 at binnacle dot cx
>Sent: Wednesday, July 31, 2013 10:26 AM
>
Well I uncovered a serious regression
and expressed a willingness to track
down the cause.
However your nasty reply and bad attitude
assures that I will defintiely not help
now.
At 01:21 PM 7/31/2013 -0400, Christopher Faylor wrote:
>You are right in assuming that newer DLLs should
>work with old
On Wed, Jul 31, 2013 at 12:24:32PM -0400, starlight.201...@binnacle.cx wrote:
>Have been running 1.7.16 for some time and living with the annoying
>CTRL-C hang bug.
>
>Tried swapping in cygwin1.dll cyglsa.dll and cyglsa64.dll from 1.7.22-1
>without (thankfully) updating the entire CYGWIN release.
>
Hello,
Have been running 1.7.16 for some time
and living with the annoying CTRL-C hang
bug.
Tried swapping in cygwin1.dll cyglsa.dll
and cyglsa64.dll from 1.7.22-1 without
(thankfully) updating the entire CYGWIN
release.
The 22-1 DLLs fix the CTRL-C problem,
but cause a high-intensity parallel
b
On Nov 10 10:58, Corinna Vinschen wrote:
> On Nov 9 22:18, Leon Vanderploeg wrote:
> > Many thanks to Charles and Corinna for the help. I have modified the
> > code to use the POSIX functions. I still have one problem I cannot
> > seem to conquer.
> >
> > I need to be able to read and write t
On Nov 9 22:18, Leon Vanderploeg wrote:
> Many thanks to Charles and Corinna for the help. I have modified the
> code to use the POSIX functions. I still have one problem I cannot
> seem to conquer.
>
> I need to be able to read and write the (yes, I know it's evil)
> archive bit. Unless the
Many thanks to Charles and Corinna for the help. I have modified the code to
use the POSIX functions. I still have one problem I cannot seem to conquer.
I need to be able to read and write the (yes, I know it's evil) archive bit.
Unless there is a POSIX function (which I seriously doubt) fo
On Nov 3 17:56, Charles Wilson wrote:
> On 11/3/2011 4:48 PM, Leon Vanderploeg wrote:
> > With cygwin 1.7.5, cFileName with a special characters such as ñ (n
> > with tidle above it) fail be properly extracted from a
> > WIN32_FIND_DATA structure with findFirstFile (or findNextFile).
> >
> > To s
On 11/3/2011 4:48 PM, Leon Vanderploeg wrote:
> With cygwin 1.7.5, cFileName with a special characters such as ñ (n
> with tidle above it) fail be properly extracted from a
> WIN32_FIND_DATA structure with findFirstFile (or findNextFile).
>
> To set up a simple test scenario, I created a file in C
Greetings,
This issue is making my head flat from pounding it against the wall. It
appears to be a bug in Cygwin 1.7, but I can't say with any certainty. I've
been down too many dead end trails already...
With cygwin 1.7.5, cFileName with a special characters such as ñ (n with tidle
above it
Hi,
On Wed, Nov 2, 2011 at 12:36 AM, Leon Vanderploeg wrote:
> Greetings,
>
> This issue is making my head flat from pounding it against the wall. It
> appears to be a bug in Cygwin 1.7, but I can't say with any certainty. I've
> been down too many dead end trails already...
>
> With cygwin 1
Greetings,
This issue is making my head flat from pounding it against the wall. It
appears to be a bug in Cygwin 1.7, but I can't say with any certainty. I've
been down too many dead end trails already...
With cygwin 1.7.5, file name with a special characters such as ñ (n with tidle
above it
On Oct 25 07:06, Leon Vanderploeg wrote:
> I have been fighting a problem with a compiled C program and seem to have
> narrowed it down. When file names contain special characters such as the n
> with the tilde above it (ñ), stat() works fine on 32 bit machines, but fails
> on 64 bit machines (bot
I have been fighting a problem with a compiled C program and seem to have
narrowed it down. When file names contain special characters such as the n
with the tilde above it (ñ), stat() works fine on 32 bit machines, but fails
on 64 bit machines (both windows 7 and server 2008 R2).
At the end of
On 02/01/2011 15:30, Jim Reisert AD1C wrote:
> I'm re-installing Cygwin from scratch, using the latest setup.exe on a
> Windows 7 64-bit system
>
> I had downloaded and installed gcc4, then discovered I had failed to
> download the corresponding g++ package. I ran "setup -M" and selected
> gcc4-g
I'm re-installing Cygwin from scratch, using the latest setup.exe on a
Windows 7 64-bit system
I had downloaded and installed gcc4, then discovered I had failed to
download the corresponding g++ package. I ran "setup -M" and selected
gcc4-g++. When setup tried to check for dependencies, it got i
Corinna Vinschen wrote:
> On Dec 2 12:07, Christian Franke wrote:
> >
> > Another test:
> >
> > This sends one UDP package on 1.5, but two on 1.7:
> >
> > int sd = socket(AF_LOCAL, SOCK_DGRAM, 0);
> >
> > struct sockaddr_un sa; sa.sun_family = AF_LOCAL;
> > strcpy(sa.sun_path, "/dev/log");
> >
On Dec 2 15:17, Corinna Vinschen wrote:
> On Dec 2 12:07, Christian Franke wrote:
> > Corinna Vinschen wrote:
> > > On Dec 2 10:31, Christian Franke wrote:
> > > > I presume that the root of the problem is that the
> > > >
> > > > writev(fd, { {"< PRI >", . }, { "MSG", . } }, 2)
> > > > used w
On Dec 2 12:07, Christian Franke wrote:
> Corinna Vinschen wrote:
> > On Dec 2 10:31, Christian Franke wrote:
> > > I presume that the root of the problem is that the
> > >
> > > writev(fd, { {"< PRI >", . }, { "MSG", . } }, 2)
> > > used within syslog() sends "< PRI >" and "MSG" in
> > > two s
Corinna Vinschen wrote:
> On Dec 2 10:31, Christian Franke wrote:
> > I presume that the root of the problem is that the
> >
> > writev(fd, { {"< PRI >", . }, { "MSG", . } }, 2)
> > used within syslog() sends "< PRI >" and "MSG" in
> > two separate datagrams to /dev/log.
> >
>
> Probably not.
On Dec 2 10:31, Christian Franke wrote:
> syslog() produces bogus lines in /var/log/messages.
>
> Testcase (with syslog-ng):
>
> $ echo -e 'one\ntwo\nthree' | logger -t test
>
> $ tail /var/log/messages
> ...
> Dec 2 10:12:31 localhost kernel:
> Dec 2 10:12:31 localhost test: one
> Dec 2 10:
syslog() produces bogus lines in /var/log/messages.
Testcase (with syslog-ng):
$ echo -e 'one\ntwo\nthree' | logger -t test
$ tail /var/log/messages
...
Dec 2 10:12:31 localhost kernel:
Dec 2 10:12:31 localhost test: one
Dec 2 10:12:31 localhost kernel:
Dec 2 10:12:31 localhost test: two
Dec
snip<
I just discovered some additional information that may help get to the
bottom of this. Not sure what made me think of this, but I decided to try
an older version of rsync. If I run rsync 3.0.4-1 or 3.0.5-1, I
experience the problem. However, when I run 2.6.9-2, the only other
version of
On Jul 1 07:36, Lists wrote:
I tried it 6 times in a row, every time erasing the destination files.
Works fine for me.
Corinna
Perhaps you have hit upon the problem. I am just downloading and
running
setup-1.7.exe and it definetly has this problem. I tried to download
and
Setup-1.7.exe
On Jul 1 07:36, Lists wrote:
I tried it 6 times in a row, every time erasing the destination files.
Works fine for me.
Corinna
Perhaps you have hit upon the problem. I am just downloading and running
setup-1.7.exe and it definetly has this problem. I tried to download and
Setup-1.7.exe c
On Jul 1 07:36, Lists wrote:
>> I tried it 6 times in a row, every time erasing the destination files.
>> Works fine for me.
>>
>>
>> Corinna
>>
> Perhaps you have hit upon the problem. I am just downloading and running
> setup-1.7.exe and it definetly has this problem. I tried to download and
On Jun 26 23:42, Lists wrote:
On Jun 19 15:55, Lists wrote:
Works fine for me under the latest Cygwin 1.7.0-50 using your perl
script and your rsync options. I tend to agree to Larry's assumption
that some 3PP is interferring.
Sorry to just now be replying but I have been out of the country
On Jun 26 23:42, Lists wrote:
>> On Jun 19 15:55, Lists wrote:
>>>
>> Works fine for me under the latest Cygwin 1.7.0-50 using your perl
>> script and your rsync options. I tend to agree to Larry's assumption
>> that some 3PP is interferring.
>
> Sorry to just now be replying but I have been out
On Jun 19 15:55, Lists wrote:
Can you upgrade to the latest Cygwin 1.7 package and try again. From
your
cygcheck output, it looks like things are not correct but this may be
just
a problem with an old cygcheck that doesn't know how to find the
implicit
mounts. If the issue is still the sam
On Jun 19 15:55, Lists wrote:
>
>> Can you upgrade to the latest Cygwin 1.7 package and try again. From your
>> cygcheck output, it looks like things are not correct but this may be just
>> a problem with an old cygcheck that doesn't know how to find the implicit
>> mounts. If the issue is still
Lists wrote:
Lists wrote:
Larry Hall wrote:
Can you upgrade to the latest Cygwin 1.7 package and try again.
From your
cygcheck output, it looks like things are not correct but this may
be just
a problem with an old cygcheck that doesn't know how to find the
implicit
mounts. If the issue i
Lists wrote:
Larry Hall wrote:
Can you upgrade to the latest Cygwin 1.7 package and try again. From
your
cygcheck output, it looks like things are not correct but this may be
just
a problem with an old cygcheck that doesn't know how to find the
implicit
mounts. If the issue is still the s
Lists wrote:
Larry Hall wrote:
Can you upgrade to the latest Cygwin 1.7 package and try again. From
your
cygcheck output, it looks like things are not correct but this may be
just
a problem with an old cygcheck that doesn't know how to find the implicit
mounts. If the issue is still the sa
Can you upgrade to the latest Cygwin 1.7 package and try again. From your
cygcheck output, it looks like things are not correct but this may be just
a problem with an old cygcheck that doesn't know how to find the implicit
mounts. If the issue is still the same, resending the output of the new
lists wrote:
See the attached cygcheck.out as per posting instructions. Note I have
also tried this on machines with much stronger hardware with the exact same
results. ALso note that the machine never runs out of memory so that doesn't
appear to be the problem either.
Not Found: awk
Not
I'm not sure if this is a bug or a limitation that can be worked around with a
setting somewhere, but I have found a problem with cygwin 1.7 while using
rsync. I have been using rsync and cygwin v1.5 for quite some time. I
recently started testing cygwin v1.7 and I ran into a problem with an a
On Jun 16 16:52, Jerry A wrote:
> Hi,
>
> I am a "local administrator" on an otherwise locked down corporate
> laptop that is running XP and currently, cygwin 1.7, the beta.
>
> I was running the released version of cygwin and having problems
> installing sshd and passwd. I found a thread from b
Hi,
I am a "local administrator" on an otherwise locked down corporate
laptop that is running XP and currently, cygwin 1.7, the beta.
I was running the released version of cygwin and having problems
installing sshd and passwd. I found a thread from back in March
regarding passwd working in domai
That certainly fixed it. Thanks.
-Greg
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Corinna Vinschen
> Sent: Tuesday, February 19, 2008 1:00 PM
> To: cygwin@cygwin.com
> Subject: Re: Possible Bug: Spurious SIGTERM from
On Feb 19 12:43, Greg Gibeling wrote:
> Program: cygrunsrv 1.20-1
> OS: Windows 2003 Server Enterprise Edition SP2
> Problem: The child process of cygrunsrv (openSSH/sshd in this case) receives
> a SIGTERM ~10-30 seconds after cygrunsrv is started.
Looks like a really dumb last-minute change on my
Program: cygrunsrv 1.20-1
OS: Windows 2003 Server Enterprise Edition SP2
Problem: The child process of cygrunsrv (openSSH/sshd in this case) receives
a SIGTERM ~10-30 seconds after cygrunsrv is started.
Steps to reproduce:
1) Install Cygwin with OpenSSH
2) Use ssh-host-config to set
* Dave Korn (Fri, 10 Aug 2007 17:48:13 +0100)
> On 10 August 2007 17:23, Thorsten Kampe wrote:
> > * Phil Betts (Fri, 10 Aug 2007 17:05:18 +0100)
> >> Thorsten Kampe wrote on Friday, August 10, 2007 4:09 PM::
> >>> Phil, please, you don't know what you're talking about and you don't
> >>> know what
Dave Korn wrote:
On 10 August 2007 17:23, Thorsten Kampe wrote:
* Phil Betts (Fri, 10 Aug 2007 17:05:18 +0100)
[...]
As a matter of fact I stopped reading his article
after the line where he says d does not read ~/.d.conf because this
matched my own experience.
Bad practice. Stopping read
On 10 August 2007 17:23, Thorsten Kampe wrote:
> * Phil Betts (Fri, 10 Aug 2007 17:05:18 +0100)
>> Thorsten Kampe wrote on Friday, August 10, 2007 4:09 PM::
>>> Phil, please, you don't know what you're talking about and you don't
>>> know what I and Ronald were talking about.
>>
>> If you re-read
* Phil Betts (Fri, 10 Aug 2007 17:05:18 +0100)
> Thorsten Kampe wrote on Friday, August 10, 2007 4:09 PM::
> > Phil, please, you don't know what you're talking about and you don't
> > know what I and Ronald were talking about.
>
> If you re-read what was posted, you'll find I was totally correct
>
* Dave Korn (Fri, 10 Aug 2007 16:49:31 +0100)
> On 10 August 2007 16:44, Thorsten Kampe wrote:
> > Fact is that d under Cygwin ignores ~/.d.conf while under Linux it works
> > as expected.
>
> >> Thorsten, he may or may not know what you're talking about, but your
> >> statement
> >>
>
Thorsten Kampe wrote on Friday, August 10, 2007 4:09 PM::
> Phil, please, you don't know what you're talking about and you don't
> know what I and Ronald were talking about.
I'm so sorry, but my telepathy module has a malfunction. Until it's
fixed, I can only respond to what is actually written
* Dave Korn (Fri, 10 Aug 2007 16:37:23 +0100)
> On 10 August 2007 16:22, Thorsten Kampe wrote:
>
>
> > The problem (/my/ problem and maybe Ronald's) is that d reads the home
> > directory from /etc/passwd and not from the environment variable
> > $HOME. In my setup these differ.
>
> Is that ev
On 10 August 2007 16:44, Thorsten Kampe wrote:
> Fact is that d under Cygwin ignores ~/.d.conf while under Linux it works
> as expected.
>> Thorsten, he may or may not know what you're talking about, but your
>> statement
>>
>> "d under Cygwin ignores ~/.d.conf "
>>
>> is demonstra
* Dave Korn (Fri, 10 Aug 2007 16:19:22 +0100)
> On 10 August 2007 16:09, Thorsten Kampe wrote:
> > * Phil Betts (Fri, 10 Aug 2007 15:04:11 +0100)
> >> Thorsten Kampe wrote on Friday, August 10, 2007 2:21 PM::
>
> >>> These resources don't contradict the info file but state the same.
> >>> Fact is
On 10 August 2007 16:22, Thorsten Kampe wrote:
> The problem (/my/ problem and maybe Ronald's) is that d reads the home
> directory from /etc/passwd and not from the environment variable
> $HOME. In my setup these differ.
Is that even valid? Hmmm. Posix does say:
http://www.opengroup.org/on
* Dave Korn (Fri, 10 Aug 2007 15:02:03 +0100)
> On 10 August 2007 14:21, Thorsten Kampe wrote:
> > * Yaakov (Cygwin Ports) (Fri, 10 Aug 2007 07:09:11 -0500)
> >> Ronald Fischer wrote:
> >>> From
> >>>
> >>>info d
> >>>
> >>> we can see that /usr/bin/d is supposed to honour a configuration fil
On 10 August 2007 16:09, Thorsten Kampe wrote:
> * Phil Betts (Fri, 10 Aug 2007 15:04:11 +0100)
>> Thorsten Kampe wrote on Friday, August 10, 2007 2:21 PM::
>>> These resources don't contradict the info file but state the same.
>>> Fact is that d under Cygwin ignores ~/.d.conf while under Linux i
* Phil Betts (Fri, 10 Aug 2007 15:04:11 +0100)
> Thorsten Kampe wrote on Friday, August 10, 2007 2:21 PM::
> > * Yaakov (Cygwin Ports) (Fri, 10 Aug 2007 07:09:11 -0500)
> >> Ronald Fischer wrote:
> >>> From
> >>>
> >>>info d
> >>>
> >>> we can see that /usr/bin/d is supposed to honour a confi
Thorsten Kampe wrote on Friday, August 10, 2007 2:21 PM::
> * Yaakov (Cygwin Ports) (Fri, 10 Aug 2007 07:09:11 -0500)
>> Ronald Fischer wrote:
>>> From
>>>
>>>info d
>>>
>>> we can see that /usr/bin/d is supposed to honour a configuration
>>> file ~/.d.conf and that in this file, the boolean
1 - 100 of 211 matches
Mail list logo
