change email address

[Wells, Roger K. [US-US] via Cygwin]

I have attempted to change the email address for my cygwin info and it never 
succeeds.
I would prefer to get it at: roger.k.we...@alum.mit.edu

Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

How to change email address

[Wells, Roger K. [US-US] via Cygwin]

For the lists I am currently subscribed?
I've tried several times but nothing works.
current: roger.k.we...@leidos.com
desired: roger.k.we...@alum.mit.edu
TIA,

Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: EXTERNAL: Re: sshd high cpu load

[Wells, Roger K. via Cygwin]

On 5/20/21 4:35 PM, Andrey Repin wrote:
> CAUTION: This email originated from outside of Leidos. Be cautious when 
> clicking or opening content.
>
> Greetings, Wells, Roger K.!
>
>>> On 5/19/2021 12:48 AM, A. Doggy wrote:
>>>>
>>>> I am running cygwin openssh as a windows service. I have been doing
>>>> so for many years with out issue. Recently, I have been running into
>>>> an issue where it maxes out my cpu on any version newer than 8.4p1-1.
>>>> The solution is to downgrade to 8.4p1-1. My server machine is a dell
>>>> t330 running windows 10. I am not a business despite using business
>>>> grade hardware.I have tried both 20h2 and 21h1 but no luck. There are
>>>> no users signed in when the issues occur and occurs within minutes of
>>>> booting up. The only change from the default config is I have it
>>>> running on a nonstandard port. Any advice is welcome as I really
>>>> would like to upgrade to a newer version. Thanks
>> I noticed your initial contact and tried to duplicate what you observed
>> to no avail.
> https://cygwin.com/pipermail/cygwin/2021-April/248299.html
>
>> I set up cygwin openssh as a windows service as you described and also
>> have been doing it this way for many years.
>> sshd.exe doesn't show any cpu load on task manager even after days (yes
>> it still works when I log in from another machine)
>> My system is a Lenovo Thinkpad-x240 running updated W10. Cygwin is at
>> 3.2.0(0.340/5/3)
>> and ssh is at OpenSSH_8.5p1, OpenSSL 1.1.1f  31 Mar 2020.
>> Let me know if you would like me to try something else.
> Connect from remote machine to the usual shell prompt and force kill remote
> ssh process.
> The hung SSH session will cause full core CPU load.
will do & report back
>
>
> --
> With best regards,
> Andrey Repin
> Thursday, May 20, 2021 23:31:39
>
> Sorry for my terrible english...
>

-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: EXTERNAL: Re: sshd high cpu load

[Wells, Roger K. via Cygwin]

On 5/20/21 12:02 PM, A. Doggy via Cygwin wrote:
> Anyone?

Sorry,
I noticed your initial contact and tried to duplicate what you observed
to no avail.
I set up cygwin openssh as a windows service as you described and also
have been doing it this way for many years.
sshd.exe doesn't show any cpu load on task manager even after days (yes
it still works when I log in from another machine)
My system is a Lenovo Thinkpad-x240 running updated W10. Cygwin is at
3.2.0(0.340/5/3)
and ssh is at OpenSSH_8.5p1, OpenSSL 1.1.1f  31 Mar 2020.
Let me know if you would like me to try something else.

>
> On 5/19/2021 12:48 AM, A. Doggy wrote:
>> To Cygwin,
>>
>>
>> I am running cygwin openssh as a windows service. I have been doing
>> so for many years with out issue. Recently, I have been running into
>> an issue where it maxes out my cpu on any version newer than 8.4p1-1.
>> The solution is to downgrade to 8.4p1-1. My server machine is a dell
>> t330 running windows 10. I am not a business despite using business
>> grade hardware.I have tried both 20h2 and 21h1 but no luck. There are
>> no users signed in when the issues occur and occurs within minutes of
>> booting up. The only change from the default config is I have it
>> running on a nonstandard port. Any advice is welcome as I really
>> would like to upgrade to a newer version. Thanks
>>
>

-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: EXTERNAL: Re: ifconfig

[Wells, Roger K. via Cygwin]

On 4/5/21 11:17 AM, Marco Atzeri via Cygwin wrote:
> On 05.04.2021 14:57, Daniel L Newhouse via Cygwin wrote:
>> Cygwin no longer responds to ifconfig.  What is the story?
>>
>
> I do not remember ifconfig ever been in any cygwin package.
>
nor do I
> the Windows nearest is "ipconfig"
>
>
> -- 
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Is it possible to define the root directory in a cross compiled program

[Roger Kaufman]

Hi All,


On 1/5/2021 10:02 AM, Bill Stewart wrote:
> On Tue, Jan 5, 2021 at 6:34 AM Eliot Moss wrote:
>
>> Is there a Windows equivalent to chroot (either the program or the 
library/system call)?

>
> See: https://cygwin.com/cygwin-ug-net/highlights.html
>
> Quoting:
>
> "Chroot is supported. Kind of. Chroot is not a concept known by
> Windows. This implies some serious restrictions. First of all, the
> chroot call isn't a privileged call. Any user may call it. Second, the
> chroot environment isn't safe against native windows processes. Given
> that, chroot in Cygwin is only a hack which pretends security where
> there is none. For that reason the usage of chroot is discouraged.
> Don't use it unless you really, really know what you're doing."
>
> What I have found is that the cygwin chroot is not a security boundary

Right.  My impression was that the OP was more interested in having the
functionality of where / is, though I could be wrong, of course.

I also saw web posts about Windows' RUNAS command, which deals with 
some of

the security implications, but does not re-root your file hierarchy.

Best - Eliot 


This is the OP. We can close this out. Brian Inglis mentioned the 
Windows /dev/null is "nul"
and so that solved the problem in this case. In the code below, both 
fopen's succeed

when compiled with gcc and the "nul" fopen succeeds when cross compiled with
x86_64-w64-mingw32-g++

The backstory is, I cross compile because I have code only compatible 
when cross
compiled. However, I run the code in the bash shell. Now in the bash 
shell, I can't change

directory higher than / which is expected (I know of cygdrive/c of course)

However since it is now technically a windows  program it can "see out" 
into the
file system. I have for that program, an environment variable path I 
also have to prefix e.g.
/cygwin64/home... its just something I have to live with. But it does 
make portability

imperfect as the same code compiles in Linux.

#include 

int main(int argc, char **argv)
{
  FILE *errfile1 = fopen("/dev/null", "w");
  if (!errfile1) // must be a valid pointer
    errfile1 = stderr;

  FILE *errfile2 = fopen("nul", "w");
  if (!errfile2) // must be a valid pointer
    errfile2 = stderr;

  fprintf(errfile1, "/dev/null did not succeed\n");
  fprintf(errfile2, "nul did not succeed\n");

  return 0;
}

Roger

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Is it possible to define the root directory in a cross compiled program

[Roger Kaufman]

When I cross compile the following program, opening /dev/null fails and 
instead the whole install path of /cygwin64/dev/null is visible.


Is there a way to make fopen respect / as the root directory in a cross 
compiled program for windows?


example output...

Roger@interocitor:~
$ x86_64-w64-mingw32-g++ -o writenull.exe write2null.cc

Roger@interocitor:~
$ writenull.exe
/dev/null did not succeed


Roger@interocitor:~
$ gcc -o writenull write2null.cc

Roger@interocitor:~
$ writenull
/cygwin64/dev/null did not succeed


C Code that was compiled...

#include 

int main(int argc, char **argv)
{
  FILE *errfile1 = fopen("/dev/null", "w");
  if (!errfile1) // must be a valid pointer
    errfile1 = stderr;

  FILE *errfile2 = fopen("/cygwin64/dev/null", "w");
  if (!errfile2) // must be a valid pointer
    errfile2 = stderr;

  fprintf(errfile1, "/dev/null did not succeed\n");
  fprintf(errfile2, "/cygwin64/dev/null did not succeed\n");

  return 0;
}
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: EXTERNAL: open descriptor to named pipes sometimes fail

[Wells, Roger K. via Cygwin]

On 4/7/20 11:10 AM, Kristian Ivarsson via Cygwin wrote:

Opening a (second) descriptor for (blocking) write sometimes fail

The provided test case sometimes succeed, but quite often fail with ENOENT
(in various indexes)

I haven't dug deeper to find the underlaying cause yet

Have anyone experienced this before ?

Kristian



I ran your code here. (many times)
uname -r   ->  Cygwin 3.1.4(0.340/5/3)
No problem




--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple



--
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com<mailto:roger.k.we...@leidos.com>

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: EXTERNAL: Re: Is who -b command available? Need to know when computer was started.

[Wells, Roger K.]

On 10/16/18 12:57 PM, Gary Johnson wrote:
> On 2018-10-16, Peder Sverdrup via cygwin wrote:
>> Hi,
>>
>> I am making a script and need to know when the computer was last booted.
>> This can be done with
>>
>> who -b command. I have installed the minimum cygwin and this command is not
>> available.
>>
>> Which package do I need to install in order to have this command available
>> (or any other command
>>
>> that can tell when the computer was last booted).
> The procps-ng package provides the uptime command which will tell
> you how long it has been since the computer was last booted.
>
> Regards,
> Gary

FWIW
on my cygwin, 2.11.0(0.329/5/3), I have who (GNU coreutils) 8.26.
Of all the options -a/--all gives:
$ who --all
roger- pty1 2018-10-16 13:05   .   276 (10.40.90.15)
-u, -H, -m, -s, -u gives the same (plus/minus a '-' or '.')
-q seems reasonable, at least similar to the same command on fedora
--version, --help give expected output.
The rest return nothing, including -b


>
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation:     http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>
>

-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: EXTERNAL: Re: [ANNOUNCEMENT] Updated: mintty 2.9.0

[Wells, Roger K.]

On 07/02/2018 04:27 PM, Achim Gratz wrote:
> Thomas Wolff writes:
>> I have uploaded mintty 2.9.0 with the following changes:
> […]
>
> No good deed goes unpunished, I guess.  One of these changes makes the
> cursor come out as static underline instead of blinking block whenever
> I'm going into my usual screen or tmux session.  I have not yet figured
> out what exactly is changing the cursor, but once I'm in screen nor tmux
> I can't change it for whatever reason (it might actually change and gets
> reset quickly enough so I can't see it).  Dropping out of the session I
> can send the escape sequence to switch back to blinking block (or
> whatever other cursor available), but reconnecting into the session
> brings the static underline back.  The best I have managed so far by
> compiling my own terminfo database is to get a static block cursor (not
> blinking) for a local session, but it breaks down as soon as I log into
> a remote system again.
>
> Can there be an option please to keep the cursor just as I've set it up
> in the options?
>
>
> Regards,
> Achim.

Hi,
I just did the same install and do not observe what you do.
Everything seems fine regarding the cursor type.
One thing though is that I have not used mintty before. 
Do you think that my fresh ".minttyrc" file is different than your's?
Just a thought..

-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: EXTERNAL: umask not working?

[Wells, Roger K.]

On 03/19/2018 08:49 AM, David Allsopp wrote:

Is this expected behaviour:

OPAM+DRA@OPAM ~
$ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar ;
touch /tmp/bar/foo ; ls -l /tmp/bar/foo
CYGWIN_NT-6.1-WOW OPAM 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin
0022
-rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo
-rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo

Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm not sure
what to look at on my system to diagnose what I may have inadvertently
tweaked. The directory itself is:

drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar

Thanks!


David


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



FWIW
$ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar ; 
touch /tmp/bar/foo ; ls -l /tmp/bar/foo

CYGWIN_NT-10.0 rwells-x240 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64 Cygwin
0022
-rw-r--r-- 1 roger None 0 Mar 19 09:29 /tmp/foo
mkdir: created directory '/tmp/bar'
-rw-r--r-- 1 roger None 0 Mar 19 09:29 /tmp/bar/foo

HTH

--

Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: EXTERNAL: Re: sort utility goes berzerk (x86_64)

[Wells, Roger K.]

On 11/28/2017 04:04 AM, Corinna Vinschen wrote:

On Nov 28 08:21, Houder wrote:

On 2017-11-25 14:23, Houder wrote:

Hi,

Anyone seeing this as well? sort goes berzerk on my system when piped
into
head (or less) when it is fed with a 'specially prepared' input file.

  - only happens on x86_64
  - does not happen for 'LC_COLLATE=C sort tt | head'

'specially prepared' input file? (see bottom of post).

Anyone ** NOT ** seeing this?

Yes.  I just tried it under tcsh and bash with 6000, 8000, and 8150 lines,
and it works for me.  LANG=en_US.UTF-8 implies LC_COLLATE=en_US.UTF-8
but I also set LC_COLLATE explicitely and retried.  sort tt | head
always prints

   abcde1x0123456789
   abcde2x0123456789
   abcde3x0123456789
   abcde4x0123456789
   abcde5x0123456789
   abcde6x0123456789
   abcde7x0123456789
   abcde8x0123456789
   abcde9x0123456789
   abcde   10x0123456789

and then returns to the prompt.

Same here, at least using bash


Corinna



--
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: EXTERNAL: Re: Requesting updated unzip for Zip64 Support

[Wells, Roger K.]

On 11/10/2017 10:04 AM, Brian Inglis wrote:

On 2017-11-09 23:25, OwN-3m-All wrote:

Any chance unzip can be updated to support Zip64?
http://www.paehl.com/open_source/downloads/unzip.7z
http://www.paehl.com/open_source/?ZIP_UNZIP

Current zip has supported Zip64 since 2008 and unzip since 2009.
$ zip -v; unzip -v
should both show ZIP64_SUPPORT.


as it does on my cygwin install, uname -a:
CYGWIN_NT-10.0 rwells-x240 2.9.0(0.318/5/3) 2017-09-12 10:18 x86_64 Cygwin

zip -v
.
.
Zip special compilation options:
    USE_EF_UT_TIME   (store Universal Time)
    BZIP2_SUPPORT    (bzip2 library version 1.0.6, 6-Sept-2010)
        bzip2 code and library copyright (c) Julian R Seward
        (See the bzip2 license for terms of use)
    SYMLINK_SUPPORT  (symbolic links supported)
    LARGE_FILE_SUPPORT   (can read and write large files on file system)
    ZIP64_SUPPORT    (use Zip64 to store large files in archives)
    UNICODE_SUPPORT  (store and read UTF-8 Unicode paths)
    STORE_UNIX_UIDs_GIDs (store UID/GID sizes/values using new extra field)
    UIDGID_NOT_16BIT (old Unix 16-bit UID/GID extra field not used)
    [encryption, version 2.91 of 05 Jan 2007] (modified for Zip 3)


unzip -v
.
.
UnZip special compilation options:
    COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
    SET_DIR_ATTRIB
    SYMLINKS (symbolic links supported, if RTL and file system permit)
    TIMESTAMP
    UNIXBACKUP
    USE_EF_UT_TIME
    USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
    USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
    UNICODE_SUPPORT [wide-chars, char coding: UTF-8] (handle UTF-8 
paths)

    MBCS-support (multibyte character support, MB_CUR_MAX = 6)
    LARGE_FILE_SUPPORT (large files over 2 GiB supported)
    ZIP64_SUPPORT (archives using Zip64 for large files supported)
    USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.6, 6-Sept-2010)
    VMS_TEXT_CONV
    [decryption, version 2.11 of 05 Jan 2007]

--
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

AW: gawk 4.1.4: CR separate char for CRLF files

[Roger Krebs]

Hi,

I've added a BEGIN section at the beginning awk sript file setting the record 
separator explicitly for the input file (RS) as well as for the output file 
(ORS):

BEGIN {
RS="\r\n"
ORS="\r\n"
}
{
   ... your script
}

Especially the RS parameter wasn't necessary in the past but now it is.

It works in all my cases. The only disadvantage: you have to know what kind of 
files you want to handle in the awk script. The same awk script will not work 
for DOS files as well as for linux files.

Best

Roger
-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von 
Jannick
Gesendet: Mittwoch, 9. August 2017 02:48
An: cygwin@cygwin.com
Betreff: RE: gawk 4.1.4: CR separate char for CRLF files

On Tue, 08 Aug 2017 16:23:40 -0700 (PDT), Steven Penny wrote:
> On Wed, 9 Aug 2017 01:15:08, "Jannick" wrote:
> > the current version 4.1.4 of gawk appears to unpleasantly treat CR for
> > CRLF files, i.e. CR is not gracefully swallowed, but is a separate
character.
> >
> > This makes some, if not all, of the scripts we are working with here
> > useless, unless the input files are converted to LF which certainly is
> > not feasible. IIRC the issue did not show up some versions back.
> >
> > Is this a bug - or am I missing something here?
> 
> Learn to read:
> 
> http://cygwin.com/ml/cygwin/2017-08/msg00033.html

Thanks - quickly done.

The link reveals that CRLF/LF conversion is now mandatory to work with
cygwin's gawk on DOS machines. As far as I can see there is no legacy
solution like for, e.g., sed (-b switch) to have an easy solution for the
issue, especially when invoking gawk from makefiles (piping). 

I consider this bad news while admittedly not fully understanding the whole
background of the move which is not necessary for now. 


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

AW: when using cygwin version 2.8.2 the behavior of CR/LF changed completely compared to previous versions

[Roger Krebs]

Hi,

I've seen that there were some changes regarding CR/LLF in sed and cygcheck, 
but I havn't recognized that several other tool has also changed their behavior 
in the past. We haven't done an update for a longer period of time (why update 
when anything runs well) and therefor now we've been faced with several similar 
changes in the behavior of different tools. That's the reason why we've thought 
that this must be something general.

Many thanks to bring me into the right context. We've made some smaller changes 
in our scripts and everything seems to work fine now.

Again many thanks for the very quick and helpful response.

Best Regards
Roger Krebs

-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von 
David Macek
Gesendet: Mittwoch, 2. August 2017 17:46
An: cygwin@cygwin.com
Betreff: Re: when using cygwin version 2.8.2 the behavior of CR/LF changed 
completely compared to previous versions

On 2. 8. 2017 17:34, Roger Krebs wrote:
> Hi,
> 
> after updating from version 1.7.33 to version 2.8.2 the behavior of CR-LF 
> handling completely changed. This results in several srcipt errors etc.

See announcements:

* <https://cygwin.com/ml/cygwin-announce/2017-02/msg00036.html> for sed
* <https://cygwin.com/ml/cygwin-announce/2017-02/msg00035.html> for grep
* <https://cygwin.com/ml/cygwin-announce/2017-02/msg00034.html> for gawk

There was also a discussion about these changes at 
<https://cygwin.com/ml/cygwin/2017-06/msg00040.html>.

-- 
David Macek


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

when using cygwin version 2.8.2 the behavior of CR/LF changed completely compared to previous versions

[Roger Krebs]

Hi,

after updating from version 1.7.33 to version 2.8.2 the behavior of CR-LF 
handling completely changed. This results in several srcipt errors etc.

Two examples:
1) using wmic together with grep

Executing "wmic process get ExecutablePath,processID,commandline /FORMAT:CSV | 
od -t a" shows that each line from the output of wmic ends with CR CR LF. 
That's normal and works in the same way under both cygwin versions.
Executing "wmic process get ExecutablePath,processID,commandline /FORMAT:CSV | 
grep "," |od -t a" has different outputs. Under version 1.7.33 the lines ends 
with LF, under version 2.8.2 the lines still ends with CR CR LF.
If you use cut to extract the last field (the processID) you will get the pure 
processID (number) under version 1.7.33 but the processID followed by CR CR 
(string) under version 2.8.2.
When using grep CR characters at the end of the line should usually be cut of 
to make sure the $ sign can be used in regexp as end of line marker.

2) using awk and reading from DOS files
===
When reading number values from a DOS file (each line contains only a number) 
using awk and writing this number into an array variable works perfectly under 
version 1.7.33. But under version 2.8.2 all array variables are filled with the 
number followed by a CR.
   { WebOrderID[$1] = NR; }
This issue can be solved by defining RS="\r\n" in the BEGIN section of the awk 
script. But in the past it works fine without setting the record separator.

In addition we have now problems using svn under cygwin: when using a working 
copy that isn't located on a local drive but on a remote (SMB) filing system it 
will not recognized as working copy anymore. Error message:  isn't 
a valid working copy. Doing exact the same (for example "svn info") from a 
machine with cygwin 1.7.33 installed everything works fine.

First I was unsure if something general has changed since version 1.7.33 that 
has to be taken into account now. But after spending hours on reading mail 
list, FAQ and searching the internet without finding a solution I assume, this 
may be an error in cygwin. Especially because it's one of the key features of 
cygwin to map CR LF <=> LF on the fly.

I've also downgraded the cygwin.dd to version 2.8.1.1 without any change in the 
behavior. And it doesn't matter, if it is a fresh install of version 2.8.2 or 
an update from a previous version.

Also the mount point hasn't changed
Version 1.7.33
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,noacl,posix=0,noumount,auto)

Version 2.8.2:
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,noacl,posix=0,noumount,auto)

Attached you will find the "cygcheck -sv" output from version 2.8.2 as well as 
from the previously used version 1.7.33 (it's still installed on some machines).

Best Regards

Roger Krebs



Cygwin Configuration Diagnostics
Current System Time: Wed Aug 02 10:37:52 2017

Windows 2008 R2 Server Standard Ver 6.1 Build 7601 Service Pack 1

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0

Output from C:\cygwin\bin\id.exe
UID: 112961(itse_d_operator10) GID: 100513(Domänen-Benutzer)
=100513(Domänen-Benutzer) 545(Benutzer)
544(Administratoren)   555(Remotedesktopbenutzer)
4(INTERAKTIV)  66049(KONSOLENANMELDUNG)
11(Authentifizierte Benutzer)  15(Diese Organisation)
4095(CurrentSession)   1056993(D_HAM_KoMaTo)
1054666(DE_Alle)   1064339(mediaportal-de-light)
1056937(D_CRM_Presse_Verwalter)1063234(D_HAM_SVN_User)
1057038(D_HAM_Ticket_IT)   1059959(4232 User DE SE)
1061243(D_Appl_CCBu)   1056981(D_Elektra)
1057174(D_PARMA_VERWALTER) 1071014(D_CRM_Presse_Verwalter)
1075183(D_HAM_KoMaTo)  1052553(DE_Alle)
1070980(D_PARMA_VERWALTER) 1049832(D_Elektra)
405504(Hohe Verbindlichkeitsstufe)

SysDir: C:\Windows\system32
WinDir: C:\Windows

USER = 'itse_d_operator10'
PWD = '/home/itse_d_operator10'
HOME = '/home/itse_d_operator10'

USERDOMAIN = 'SEDE'
OS = 'Windows_NT'
PROCESSOR_LEVEL = '6'
PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\'
CommonProgramW6432 = 'C:\Program Files\Common Files'
SSH_CONNECTION = '10.49.141.81 57407 10.49.143.73 22'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
FP_NO_HOST_CHECK = 'NO'
LANG = 'de_DE.UTF-8'
TZ = 'Europe/Berlin'
CommonProgramFiles = 'C:\Program Files\Common Files'
HOSTNAME = 'SDEHAMGWM11'
PUBLIC = 'C:\Users\Public

Re: cygpath -w converts relative paths to absolute windows paths

[Roger Qiu]

Hi Andrey,

That was probably true in the past, but no longer!

I just tested this: `mklink /D testlink "..\All Users"` in cmd and then 
I went to Cygwin ZSH, and ran `ll`.


This showed me: `testlink -> '../All Users'/`.

Up one directory relative links do work on Windows! This is a directory 
symbolic link, which is superior to directory junctions.


Regardless of directory junction support (which I didn't test), I think 
`cygpath` should give the right results, when I don't specify an 
absolute path, I really mean give me the windows version of the relative 
path.


Now maybe there's some backwards compatibility issues, then perhaps a 
flag that can be set to mean `--really-relative`.


Thanks,

Roger

On 8/02/2017 2:30 AM, Andrey Repin wrote:

Greetings, Roger Qiu!


Hi,
I've found that `cygpath --windows '../` will give back an absolute
windows path.
I thought this would only happen if you provide the `--absolute` flag,
or when the path is a special cygwin path.

".." is a special path, that can't be safely converted.
In all cases, using absolute path is preferred for many reasons.


But this occurs just for normal directories.
I have come across a situation where I need to convert ntfs symlinks to
unix symlinks and back. Sometimes these symlinks have relative paths
them. Now by using cygpath --windows, I get back absolute paths, which
means the integrity of the symlink isn't preserved.
Can `cygpath --windows '../directory'` give back `..\directory` for
paths aren't special cygwin paths? These relative backslashes are
supported in Windows right now.

AFAIK, Windows do not support relative junction points.




--
Founder of Polycademy
http://polycademy.com/
+61420925975


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

cygpath -w converts relative paths to absolute windows paths

[Roger Qiu]

Hi,

I've found that `cygpath --windows '../` will give back an absolute 
windows path.


I thought this would only happen if you provide the `--absolute` flag, 
or when the path is a special cygwin path.


But this occurs just for normal directories.

I have come across a situation where I need to convert ntfs symlinks to 
unix symlinks and back. Sometimes these symlinks have relative paths 
them. Now by using cygpath --windows, I get back absolute paths, which 
means the integrity of the symlink isn't preserved.


Can `cygpath --windows '../directory'` give back `..\directory` for 
paths aren't special cygwin paths? These relative backslashes are 
supported in Windows right now.


Thanks,

Roger

--
https://github.com/CMCDragonkai
+61420925975


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Is it OK to mount cygdrive on / ?

[Wells, Roger K.]

On 02/03/2017 04:10 PM, Rustam wrote:

I've added an extra / mountpoint in /etc/fstab in order to be able to
access C: without /cygdrive like this:

none /cygdrive cygdrive binary,posix=0,user 0 0
none / cygdrive binary,posix=0,user 0 0

It seems to work, I can access the C: drive with just /c.

But normally an "ls /cygdrive" should list the drives, whereas "ls /"
lists the contents of the Cygwin root. So it seems there are now two
root mountpoints overlaying each other.

So I was wondering if my approach is if this is technically undefined
behavior and might conceivably break something or is it OK (less the
drive listing limitation mentioned above).

Thanks,
Rustam


The way that I do it (and have for a long time) is a line in my 
.bash_profile file:

mount --change-cygdrive-prefix /

then ls /c does what you want
but ls / may not

HTH

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple





--
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Mosh connection errors

[Roger Qiu]

Hi Everybody,

Upon trying to execute mosh 1.2.5 from the official packages, it gives 
back this:


```

mosh root@host

bash: No such file or directory
write: Broken pipe
/usr/bin/mosh: Did not find remote IP address (is SSH ProxyCommand 
disabled?).


```

No idea what could be causing, but this doesn't happen when I'm on Linux.

Thanks,

Roger

--
https://github.com/CMCDragonkai
+61420925975


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: ssh-host-config: patch fix debug option + broken for me on Vista (non-domain)

[Wells, Roger K.]

On 01/23/2017 02:50 PM, Achim Gratz wrote:

Corinna Vinschen writes:

COMPUTERNAME is the same as LOGONSERVER on non-domain machines as well
as on domain controllers.  So this `if' test if the machine is a domain
member machine.

I can supply another cornercase where LOGONSERVER is not set: if you run
an sshd under the (only) user that can log in, that ssh session has no
LOGONSERVER set.


Regards,
Achim.


FWIW

On my W10 machine  (CYGWIN_NT-10.0 rwells-x220 2.6.0(0.304/5/3) 
2016-08-31 14:32 x86_64 Cygwin)


they are both defined and different.

AFAICS I am the only configured user.


--
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Issues with PHP PCRE and with libass4 vs libass5

[Roger Qiu]

Hi All,

I was struggling to get the new PHP version working in cygwin until I 
found this: https://www.cygwin.com/ml/cygwin/2016-11/msg00336.html


Is it a good idea to make `pcre.jit=0;` to be false for php-pcre 
package? Otherwise there's no other information as to why PHP7 fails now 
for many common applications like `composer`.


Another issue is `libass4` no longer exists, and yet it is still 
required by things like `mplayer`. I used to use `mplayer` from cygwin 
ports relying the `libass4` library from official cygwin packages, but 
`libass5` only exists. Is there a way to bring back `libass4` or can 
something else can be done?


Thanks,

Roger

--
Founder of Matrix AI
https://matrix.ai/
+61420925975


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] llvm 3.8.1-1

[Roger Pack]

On 12/7/16, Yaakov Selkowitz <yselkow...@cygwin.com> wrote:
> On 2016-12-07 17:57, Roger Pack wrote:
>> Awesome. I tried building 3.9.0 today and ran into
>>
>> llvm-3.9.0.src/lib/Support/Unix/Signals.inc:418:5: error: ‘Dl_info’
>> was not declared in this scope
>>  Dl_info dlinfo;
>
> Already fixed upstream:
>
> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Support/Unix/Signals.inc?r1=282919=283427
>

> I plan to look at rebasing sometime after 3.9.1 is out.

OK that fixed my initial problem with 3.9.0
the next failure after that (with both 3.9.0 and 3.9.1) is

Scanning dependencies of target LLVMPasses
[ 64%] Building CXX object
lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/../../../../x86_64-pc-cygwin/bin/as:
CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o: too many sections (34877)
/tmp/ccTGhQkv.s: Assembler messages:
/tmp/ccTGhQkv.s: Fatal error: can't write
CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o: File too big


so I guess I'll look forward to your release, I guess 3.9.1 was just cut.
Thanks!
-roger-

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] llvm 3.8.1-1

[Roger Pack]

On 7/21/16, Yaakov Selkowitz  wrote:
> The following packages have been uploaded to the Cygwin distribution:
>
> * llvm-3.8.1-1
> * llvm-doc-3.8.1-1
> * libllvm3.8-3.8.1-1
> * libllvm-devel-3.8.1-1

Awesome. I tried building 3.9.0 today and ran into

llvm-3.9.0.src/lib/Support/Unix/Signals.inc:418:5: error: ‘Dl_info’
was not declared in this scope
 Dl_info dlinfo;

then when I kind of worked around that by modifying Signals.cpp and
change it to include windows.inc

at link time I end up with this:

Linking CXX executable ../../bin/llvm-tblgen.exe
CMakeFiles/obj.llvm-tblgen.dir/TableGen.cpp.o: In function `main':
/home/packrd/llvm/llvm-3.9.0.src/utils/TableGen/TableGen.cpp:188:
undefined reference to
`llvm::sys::PrintStackTraceOnErrorSignal(llvm::StringRef, bool)'


Any hints/suggestions there?
Thanks!

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

curl doesn't follow redirection?

[Roger Pack]

As a note, the following "seems" to work fine in Linux, but not Cygwin:


curl -v 
https://bitbucket.org/mpyne/game-music-emu/downloads/game-music-emu-0.6.0.tar.bz2
-O -L


Reporting it here.
Cheers!
-roger-

curl --version
curl 7.49.1 (i686-pc-cygwin) libcurl/7.49.1 OpenSSL/1.0.2h zlib/1.2.8
libidn/1.29 libpsl/0.13.0 (+libidn/1.29) libssh2/1.7.0 nghttp2/1.7.1
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: Debug IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM
NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets Metalink PSL

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: ldd differences

[Roger Wells]

On 03/14/2016 03:50 PM, Roger Wells wrote:
> On 03/14/2016 03:09 PM, Achim Gratz wrote:
>> Roger Wells writes:
>>>> Try cygcheck rather than ldd.
>>>>
>>> Thanks for responding.
>>>
>>> Here's what happens:
>>>
>>> $ cygcheck ./z12.exe
>>> C:\cygwin64\home\roger\src\z12\z12.exe
>>>
>>> or
>>>
>>> $ cygcheck --verbose ./z12.exe
>>> C:\cygwin64\home\roger\src\z12\z12.exe (not x86_64 dll)
>>
>> Then it doesn't seem to be a Cygwin binary.  Is that the product of some
>> cross-compilation, perhaps?
>>
> 
> It was built with MinGW GCC 4.9.3 (32 bit)
> However, recall that the older 32 bit cygwin ldd had no problem with it.
> We have been using MinGW in a Cygwin environment for over two decades
> with out surprises.  I wonder if the fact that the executable is 32-bit
> is the culprit and the 64 bit Cygwin tools are expecting 64 bit items to
> work on?  I expect that ldd etc are attempting to do what the OS does
> when it loads the executable wrt identifying what resources (i.e. dll's)
> are required.  It shouldn't matter what tool built it and both 32 bit
> and 64 bit items are going to be around for a while and both need to be
> handled correctly.  I'll probably install 32 bit Cygwin and test the
> hypothesis.  I'll let you know.
> 
> 
> cheers,
> roger
> 
Here is what happens with cygcheck from a new 32 bit Cygwin install:

$ c:/cygwin/bin/cygcheck ./z12.exe
C:\cygwin64\home\roger\src\z12\z12.exe
  C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNELBASE.dll
  C:\WINDOWS\system32\api-ms-win-eventing-provider-l1-1-0.dll
C:\Program Files\TortoiseSVN\bin\api-ms-win-core-handle-l1-1-0.dll
C:\WINDOWS\system32\api-ms-win-core-synch-l1-2-0.dll
C:\WINDOWS\system32\api-ms-win-core-timezone-l1-1-0.dll
C:\Program Files\TortoiseSVN\bin\api-ms-win-core-string-l1-1-0.dll
C:\Program Files\TortoiseSVN\bin\api-ms-win-core-util-l1-1-0.dll
C:\Program Files\TortoiseSVN\bin\api-ms-win-core-profile-l1-1-0.dll
C:\WINDOWS\system32\api-ms-win-core-xstate-l2-1-0.dll
C:\Program Files\TortoiseSVN\bin\api-ms-win-core-console-l1-1-0.dll
  C:\WINDOWS\system32\msvcrt.dll
  C:\cygwin64\home\roger\lib\libnmea0183.dll
C:\MinGW\bin\libgcc_s_dw2-1.dll
C:\MinGW\bin\libstdc++-6.dll
  C:\cygwin64\home\roger\lib\libsensors.dll
C:\cygwin64\home\roger\lib\libutility.dll
  C:\WINDOWS\system32\ADVAPI32.DLL
C:\WINDOWS\system32\SECHOST.dll
  C:\WINDOWS\system32\RPCRT4.dll
C:\WINDOWS\system32\SspiCli.dll
  C:\WINDOWS\system32\CRYPTBASE.dll
C:\WINDOWS\system32\bcryptPrimitives.dll
  C:\WINDOWS\system32\USER32.dll
    C:\WINDOWS\system32\GDI32.dll
  C:\WINDOWS\system32\WINMM.DLL
C:\WINDOWS\system32\WINMMBASE.dll
  C:\WINDOWS\system32\WSOCK32.DLL
C:\WINDOWS\system32\WS2_32.dll
  C:\cygwin64\home\roger\lib\libfilters.dll

Much more useful.

cheers again,
roger

>>
>> Regards,
>> Achim.
>>
> 
> 


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: ldd differences

[Roger Wells]

On 03/14/2016 03:09 PM, Achim Gratz wrote:
> Roger Wells writes:
>>> Try cygcheck rather than ldd.
>>>
>> Thanks for responding.
>>
>> Here's what happens:
>>
>> $ cygcheck ./z12.exe
>> C:\cygwin64\home\roger\src\z12\z12.exe
>>
>> or
>>
>> $ cygcheck --verbose ./z12.exe
>> C:\cygwin64\home\roger\src\z12\z12.exe (not x86_64 dll)
> 
> Then it doesn't seem to be a Cygwin binary.  Is that the product of some
> cross-compilation, perhaps?
> 

It was built with MinGW GCC 4.9.3 (32 bit)
However, recall that the older 32 bit cygwin ldd had no problem with it.
We have been using MinGW in a Cygwin environment for over two decades
with out surprises.  I wonder if the fact that the executable is 32-bit
is the culprit and the 64 bit Cygwin tools are expecting 64 bit items to
work on?  I expect that ldd etc are attempting to do what the OS does
when it loads the executable wrt identifying what resources (i.e. dll's)
are required.  It shouldn't matter what tool built it and both 32 bit
and 64 bit items are going to be around for a while and both need to be
handled correctly.  I'll probably install 32 bit Cygwin and test the
hypothesis.  I'll let you know.


cheers,
roger

> 
> Regards,
> Achim.
> 


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: ldd differences

[Roger Wells]

On 03/14/2016 01:38 PM, Achim Gratz wrote:
> Roger Wells writes:
>> running ldd on a newly built executable gives:
> […]
>> What I really need is a reliable way to get a recursive listing of the
>> complete path to all dependencies.
>> I tried using Dependency Walker (both 32 & 64 bit) but it does not seem
>> to run on W10.
> 
> Try cygcheck rather than ldd.
> 
Thanks for responding.

Here's what happens:

$ cygcheck ./z12.exe
C:\cygwin64\home\roger\src\z12\z12.exe

or

$ cygcheck --verbose ./z12.exe
C:\cygwin64\home\roger\src\z12\z12.exe (not x86_64 dll)


> 
> Regards,
> Achim.
> 


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

ldd differences

[Roger Wells]

On a 32 bit Cygwin installation on a Windows 7 host that is a few years old:

$ uname -a
CYGWIN_NT-6.1-WOW64 DET000-DAC1 1.7.17(0.262/5/3) 2012-10-19 14:39 i686
Cygwin

running ldd on a newly built executable gives:

$ ldd z12.exe
ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77df)
kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75b4)
KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll
(0x766c)
msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x75c5)
libnmea0183.dll => /cygdrive/d/iss60/dll/libnmea0183.dll (0x614c)
libsensors.dll => /cygdrive/d/iss60/dll/libsensors.dll (0x68cc)
libutility.dll => /cygdrive/d/iss60/dll/libutility.dll (0x70cc)
ADVAPI32.DLL => /cygdrive/c/Windows/syswow64/ADVAPI32.DLL (0x75a7)
sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x7615)
RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x762d)
SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x754b)
CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x754a)
USER32.dll => /cygdrive/c/Windows/syswow64/USER32.dll (0x7584)
GDI32.dll => /cygdrive/c/Windows/syswow64/GDI32.dll (0x7572)
LPK.dll => /cygdrive/c/Windows/syswow64/LPK.dll (0x766b)
USP10.dll => /cygdrive/c/Windows/syswow64/USP10.dll (0x763c)
WINMM.DLL => /cygdrive/c/Windows/system32/WINMM.DLL (0x71ee)
WSOCK32.DLL => /cygdrive/c/Windows/system32/WSOCK32.DLL (0x72b1)
WS2_32.dll => /cygdrive/c/Windows/syswow64/WS2_32.dll (0x75f2)
NSI.dll => /cygdrive/c/Windows/syswow64/NSI.dll (0x7571)
libfilters.dll => /cygdrive/d/iss60/dll/libfilters.dll (0x6dc4)
IMM32.DLL => /cygdrive/c/Windows/system32/IMM32.DLL (0x756b)
MSCTF.dll => /cygdrive/c/Windows/syswow64/MSCTF.dll (0x75ff)

An expected list containing dependencies on Windows and our own DLL's.

On a quite new 64 bit Cygwin running on a Windows 10 host:

$ uname -a
CYGWIN_NT-10.0 rwells-x220 2.4.1(0.293/5/3) 2016-01-24 11:26 x86_64 Cygwin

Running ldd on the same executable file gives:

$ ldd z12.exe
ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe2bfd)
ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x774b)
wow64.dll => /cygdrive/c/WINDOWS/system32/wow64.dll (0x7229)
wow64win.dll => /cygdrive/c/WINDOWS/system32/wow64win.dll (0x722e)
??? => ??? (0xc)
KERNEL32.DLL => /cygdrive/c/WINDOWS/SYSTEM32/KERNEL32.DLL (0x76a6)
??? => ??? (0xc)
??? => ??? (0x65)
wow64cpu.dll => /cygdrive/c/WINDOWS/system32/wow64cpu.dll (0x7228)
KERNEL32.DLL => /cygdrive/c/WINDOWS/SYSTEM32/KERNEL32.DLL (0x76a6)
KERNELBASE.dll => /cygdrive/c/WINDOWS/SYSTEM32/KERNELBASE.dll
(0x7587)
msvcrt.dll => /cygdrive/c/WINDOWS/SYSTEM32/msvcrt.dll (0x76e5)


And the executable, z12.exe, does run correctly on both systems.

What I really need is a reliable way to get a recursive listing of the
complete path to all dependencies.
I tried using Dependency Walker (both 32 & 64 bit) but it does not seem
to run on W10.

TIA


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: Compiling gcc trunk under cygwin

[Roger Orr]

FYI
Fixes for both issues now released to gcc trunk.
Roger.

-Original Message-
From: Roger Orr [mailto:rog...@howzatt.demon.co.uk] 
Sent: 27 January 2016 00:16
To: 'cygwin@cygwin.com'
Subject: RE: Compiling gcc trunk under cygwin

FYI
(1) Revision 232071 problem

The pr66655 has a new proposed patch, which does appear to build on cygwin,
and is awaiting final approval.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655

(2) Revision 232454 problem

I've now reported the revision 232454 problem as pr69506 (as it's been well
over a week since the problematic check-in)

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506

Regards,
Roger.

-Original Message-
From: Roger Orr [mailto:rog...@howzatt.demon.co.uk] 
Sent: 23 January 2016 14:19
To: cygwin@cygwin.com
Subject: Re: Compiling gcc trunk under cygwin

David Wohlferd  LimeGreenSocks.com> writes:

> Until recently, I've been able to build gcc under cygwin just fine. But 
> (relatively) recent checkins (232454 &  232071) are causing problems.

Have you reported the problems with 232454 to gcc yet?

I've already reported the 232071 problem, on the original bug report this
was trying to fix. See gcc's bugzilla:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
 
Roger.



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: Compiling gcc trunk under cygwin

[Roger Orr]

FYI
(1) Revision 232071 problem

The pr66655 has a new proposed patch, which does appear to build on cygwin,
and is awaiting final approval.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655

(2) Revision 232454 problem

I've now reported the revision 232454 problem as pr69506 (as it's been well
over a week since the problematic check-in)

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506

Regards,
Roger.

-Original Message-
From: Roger Orr [mailto:rog...@howzatt.demon.co.uk] 
Sent: 23 January 2016 14:19
To: cygwin@cygwin.com
Subject: Re: Compiling gcc trunk under cygwin

David Wohlferd  LimeGreenSocks.com> writes:

> Until recently, I've been able to build gcc under cygwin just fine. But 
> (relatively) recent checkins (232454 &  232071) are causing problems.

Have you reported the problems with 232454 to gcc yet?

I've already reported the 232071 problem, on the original bug report this
was trying to fix. See gcc's bugzilla:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
 
Roger.



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Compiling gcc trunk under cygwin

[Roger Orr]

David Wohlferd  LimeGreenSocks.com> writes:

> Until recently, I've been able to build gcc under cygwin just fine. But 
> (relatively) recent checkins (232454 &  232071) are causing problems.

Have you reported the problems with 232454 to gcc yet?

I've already reported the 232071 problem, on the original bug report this
was trying to fix. See gcc's bugzilla:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
 
Roger.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: CTRL-C does not work in Cygwin when using pipes

[Roger Wells]

On 12/29/2015 03:29 PM, Warren Young wrote:
> On Dec 29, 2015, at 1:03 PM, Bill Smith <bsm...@progress.com> wrote:
>>
>> echo foo | perl -e 'while(1) {sleep 1;}'
>>
>> CTRL-C does not work.  I have to use Task Manager to kill the perl program.
> 
> Works for me on Windows 10, under both the Cygwin Terminal (mintty) and in a 
> raw cmd.exe window.
> 

a bit more:
windows 10, mintty, works as hoped.
windows 10, bash, observe what the OP reported originally

HTH

> You’ll have to narrow the conditions.
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> 
> 


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Ability to specify /cygdrive mount value in setup

[Roger Wells]

On 11/25/2015 10:56 AM, cyg Simple wrote:
> Friends,
> 
> I find /cygdrive/ just unbearable and I always change it to / after an
> install.  The issue with this is that post install activities will
> create symlinks using /cygdrive moniker so I must go change those if I
> find them.  Would it be possible for setup to ask for the value and
> setup the /etc/fstab with the value?  Do others find this bit of annoying?
> 

yep

-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: BSOD when running from network share

[Roger Wells]

On 11/19/2015 05:13 PM, Patrick Herbst wrote:
> I have cygwin installed on a windows network share folder.  Most
> everything works fine.
> 
> But I get a BSOD when in bash running the following
> 
> cat > /tmp/junk < asdf
> asdf
> asdf
> asdf
> EOF
> 
> As soon as i hit enter on "EOF" I get a BSOD RDR_FILE_SYSTEM STOP: 0x0027
> 
> Can anyone else
> 1) reproduce this?
> 2) confirm this?
> 3) fix this?
> 
> thanks!
> 
FWIW, no problem here:

roger@rwells-x220 ~
$ cat > /tmp/junk < asdf
> asdf
> asdf
> asdf
> EOF

roger@rwells-x220 ~
$ cat /tmp/junk
asdf
asdf
asdf
asdf

roger@rwells-x220 ~
$ uname -a
CYGWIN_NT-10.0 rwells-x220 2.3.0(0.291/5/3) 2015-11-09 10:24 x86_64 Cygwin

HTH

> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> 
> 


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Mounting a network share

[Roger Wells]

On 11/02/2015 11:18 AM, Corinna Vinschen wrote:
> On Nov  1 23:35, Mike Brown wrote:
>> On Mon, Nov 02, 2015 at 04:40:33AM +0300, Andrey Repin wrote:
>>> net use //host/resource[/path] P: * /PERSISTENT /SAVECRED
>>
>> I got the following to be accepted:
>>
>> net use \\192.168.1.40\Public password /user:brown /persistant:yes
>>
>> The syntax doesn't have a place to where it should be mounted.
> 
> I missed that in my reply.  It has:
> 
>   net use X: \\server\share
> 
> when using this command in a Cygwin shell, keep in mind that backslashes
> need to be escaped in Unix shells:
> 
>   net use X: server\\share

or this works:
    net use x: '\\server\share'
(single quotes)

> 
> 
> Corinna
> 


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

setup.exe with packages specified downloads multiple versions [?]

[Roger Pack]

As a note, running this:


setup-x86.exe ^
--quiet-mode ^
--no-admin ^
--no-startmenu ^
--no-shortcuts ^
--no-desktop ^
--site http://mirrors.xmission.com/cygwin/ ^
--root %cd% ^
--packages ^
ed,curl,wget,subversion,texinfo,gcc-g++,bison,flex,cvs,yasm,automake,libtool,autoconf,gcc-core,cmake,git,make,pkg-config,zlib1g-dev,mercurial,unzip,pax,ncurses,patch

downloads seemingly lots of versions of particular packages [?] (note
the duplicates of autoconf and automake, various versions:

Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm
peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin
%2f/x86/release/autoconf/autoconf-13-1.tar.bz2
Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm
peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin
%2f/x86/release/autoconf2.1/autoconf2.1-2.13-12.tar.bz2
Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm
peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin
%2f/x86/release/autoconf2.5/autoconf2.5-2.69-3.tar.xz
Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm
peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin
%2f/x86/release/automake/automake-9-1.tar.bz2
Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm
peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin
%2f/x86/release/automake1.10/automake1.10-1.10.3-2.tar.bz2
Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm
peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin
%2f/x86/release/automake1.11/automake1.11-1.11.6-2.tar.bz2
Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm
peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin
%2f/x86/release/automake1.12/automake1.12-1.12.6-2.tar.bz2
Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm

Not sure if that's expected or not.
Cheers!
-roger-

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

64 bit has different dependencies somehow?

[Roger Pack]

As a note, when installing these packages:

setup-x86.exe ^
--quiet-mode ^
--no-admin ^
--no-startmenu ^
--no-shortcuts ^
--no-desktop ^
--site http://mirrors.xmission.com/cygwin/ ^
--root %cd% ^
--packages ^
ed,curl,wget,subversion,texinfo,gcc-g++,bison,flex,cvs,yasm,automake,libtool,autoconf,gcc-core,cmake,git,make,pkg-config,zlib1g-dev,mercurial,unzip,pax,ncurses,patch

and

setup-x86_64.exe ^
--quiet-mode ^
--no-admin ^
--no-startmenu ^
--no-shortcuts ^
--no-desktop ^
--site http://mirrors.xmission.com/cygwin/ ^
--root %cd% ^
--packages ^
ed,curl,wget,subversion,texinfo,gcc-g++,bison,flex,cvs,yasm,automake,libtool,autoconf,gcc-core,cmake,git,make,pkg-config,zlib1g-dev,mercurial,unzip,pax,ncurses,patch


for some reason with the 32 bit install, I get "libintl.a" installed:


 Directory of 
C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffmpeg_local_builds.good2\cygwin_local_install\lib

09/20/2015  02:02 PM   205,162 libintl.a
09/20/2015  02:02 PM39,098 libintl.dll.a
09/20/2015  02:02 PM   899 libintl.la

But not the same libs for the 64 bit install.
Just calling it out in case it's unexpected

Cheers!
-roger-

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: setup.exe with packages specified downloads multiple versions [?]

[Roger Pack]

On 10/29/15, Marco Atzeri <marco.atz...@gmail.com> wrote:
>
>
> On 29/10/2015 20:53, Roger Pack wrote:
>> As a note, running this:
>>
>>
>> setup-x86.exe ^
>> --quiet-mode ^
>> --no-admin ^
>> --no-startmenu ^
>> --no-shortcuts ^
>> --no-desktop ^
>> --site http://mirrors.xmission.com/cygwin/ ^
>> --root %cd% ^
>> --packages ^
>> ed,curl,wget,subversion,texinfo,gcc-g++,bison,flex,cvs,yasm,automake,libtool,autoconf,gcc-core,cmake,git,make,pkg-config,zlib1g-dev,mercurial,unzip,pax,ncurses,patch
>>
>> downloads seemingly lots of versions of particular packages [?] (note
>> the duplicates of autoconf and automake, various versions:
>>
> [cut]
>>
>> Not sure if that's expected or not.
>> Cheers!
>> -roger-
>
> Setup is correct.
> Autoconf and automake are wrapper managing
>   alternative version of the same package.
> If you looks on setup.ini content:
>
> @ autoconf
> sdesc: "Wrapper scripts for autoconf commands"
> ldesc: "Wrapper scripts for autoconf commands"
> category: Devel
> requires: bash sed autoconf2.1 autoconf2.5 cygwin
> 
> @ automake
> sdesc: "Wrapper scripts for automake and aclocal"
> ldesc: "Wrapper scripts for automake and aclocal"
> category: Devel
> requires: bash gawk automake1.4 automake1.5 automake1.6 automake1.7
> automake1.8 automake1.9 automake1.10 automake1.11 automake1.12
> automake1.13 automake1.14 automake1.15 cygwin

OK thanks for the clarification.
-roger-

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: "permission denied" issues when removing files/folders created by cygwin

[Roger Pack]

On 9/1/15, Corinna Vinschen <corinna-cyg...@cygwin.com> wrote:
> On Sep  1 13:05, Michael Enright wrote:
>> On Tue, Sep 1, 2015 at 12:48 PM, Roger Pack  wrote:
>> > It appears the problem lies with creating a file named "NUL" windows
>> > utilities just don't know how to deal with it (you can recreate it by
>> > creating a folder, then from cygwin bash $ touch NUL) then try and
>> > remove the folder with windows explorer.
>>
>> The utilities "know" how to deal with it, given their design:
>> http://blogs.msdn.com/b/oldnewthing/archive/2003/10/22/55388.aspx
>
> And then there's
>
> https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-dosdevices
>
> You can create and delete those files even in CMD, btw.  You just have
> to use the long pathname prefix "\\?\", e.g.:
>
>   bash$ cmd /c 'echo foo > \\?\c:\cygwin64\home\corinna\nul'
>   bash$ ls -l nul
>   -rwxr-xr-x 1 corinna vinschen 6 Sep  1 22:30 nul
>
> delete with
>
>   bash$ rm nul
>
> or
>
>   bash$ cmd /c 'del \\?\c:\cygwin64\home\corinna\nul'

Yeah this works.  Windows explorer is not as clever unfortunately, so
lay users would find trouble here (my particular case is they install
a local copy of cygwin which cross compile's something for them--no
knowledge of cygwin required--but then suddenly they find they cannot
remove folders through any easy means...)
Cheers!

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

"permission denied" issues when removing files/folders created by cygwin

[Roger Pack]

As a note, after using cygwin to build some libraries (worked well,
thanks team!) when trying to delete a folder via windows explorer, I
got the message  "Destination folder access denied, you need to
confirm this action"  (followed by a UAC prompt) and also
"Delete folder, Invalid MS-DOS function"

It appears the problem lies with creating a file named "NUL" windows
utilities just don't know how to deal with it (you can recreate it by
creating a folder, then from cygwin bash $ touch NUL) then try and
remove the folder with windows explorer.

I would not have expected cygwin to allow itself the privilege of
creating files that are unremovable by windows explorer, but I just
thought I'd throw it out there.

Cheers!
-roger-

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: suggestion for setup.exe: on quiet mode start window minimized option

[Roger Pack]

On 8/28/15, Buchbinder, Barry (NIH/NIAID) [E] <bbuchbin...@niaid.nih.gov> wrote:
> Roger Pack sent the following at Friday, August 28, 2015 1:29 PM
>>Today I wanted to script an unattended install of cygwin. It works well.
>>However, I also wanted to be able to do it without showing a window to
>>the user at all. Suggestion/feature request: for --quiet-mode start
>>minimized, or perhaps add a "--start-minimized" option. Cheers. -roger-
>
> How do you start setup?  Maybe one of the following will work for you.
>
> A Windows shortcut can be set up to start minimized.  My impression is
> that one can use and mechanism to launch a Windows shortcut and then
> Windows will follow the instructions ("Start in:", "Run:", etc.) in the
> shortcut.
>
> In cmd:
> start /min
>
> From a command line (though not a bash shell when cygwin, bash, or maybe
> mintty are being updated):
> cygstart --minimize
> or
> cmd /c start /min

Thanks that did it!

For followers, I ended up using

start /min /wait setup-x86.exe -P ...

(since I wanted to wait for it to terminate before proceeding in my
batch script, like it does when run as straight setup-x86.exe).

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

suggestion for setup.exe: on quiet mode start window minimized option

[Roger Pack]

Today I wanted to script an unattended install of cygwin.
It works well.  However, I also wanted to be able to do it without
showing a window to the user at all.
Suggestion/feature request:
for --quiet-mode start minimized, or perhaps add  a --start-minimized option.
Cheers.
-roger-

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

feature request: easier auto select a close mirror for me

[Roger Pack]

It would be awesome if the top option for servers were auto select
closest or something like that.
Possibly a web server that would do the redirects for you [?] (or you
could do local pings and see which one answers quickest).  Possibly
like what VLC does for its distro's [1] or some other offering already
available.

Related, it would be nice to have a command line option for unattended
install that were --auto-select-server for the downloads...
FWIW.
Cheers and thank you.
-roger-
[1] https://github.com/etix/mirrorbits

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

feature request: setup.exe: fail on -P misnamed_package

[Roger Pack]

Hello.
As a note, today if you run setup*.exe with -P g++ it silently
continues, even though you've used an unnamed package.  Might be nice
to kick out to the prompt if there is a package not found.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: strace -f hangs forever with process who creates child process

[Roger Wells]

On 08/24/2015 09:05 AM, Nellis, Kenneth wrote:
 From: Qian Hong
 I just found `strace -f` hangs forever for me.

 $ uname -a
 CYGWIN_NT-6.1 fracting-PC 2.2.1(0.289/5/3) 2015-08-15 11:00 i686 Cygwin)

 $ cat parent.sh
 ./child.sh

 $ cat child.sh
 echo haha

 $ strace -f -o out.txt bash -c parent.sh #hangs forever.
 
 FWIW, this also seems to hang for me, but can't confirm that it 
 hangs forever, as I didn't wait that long. Ctrl/C-ing out works, 
 but that takes several seconds to take effect. And then I can't 
 delete out.txt:
 
 $ rm -f out.txt

I also can confirm this on the same cygwin release but for x86_64:

uname -a
CYGWIN_NT-6.1 rwells-x220 2.2.1(0.289/5/3) 2015-08-20 11:42 x86_64 Cygwin



-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

man segmentation fault

[Roger Qiu]

Hi,

I just discovered recently that `man *` where * is anything results in a 
segmentation fault.


The stackdump is:

Exception: STATUS_ACCESS_VIOLATION at rip=0018017855D
rax=766972646779632F rbx=000100418290 rcx=000600049E30
rdx= rsi=000100418280 rdi=000100418288
r8 = r9 = r10=0024
r11=00010040A1BA r12=000600049E30 r13=
r14= r15=0023CA60
rbp= rsp=0023C938
program=C:\cygwin64\bin\man.exe, pid 8116, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
FrameFunctionArgs
000  0018017855D (00600046FC0, 006000465C0, 001800C52B3, 
000)
000  0010040A1C8 (00600047090, 0010048, 0010008, 
00100418174)
00100411AD3  0010040E195 (023CB70, 3000101FF00, 001800484E0, 
000)
023CBD0  00180048551 (000, 000, 000, 
000)
000  001800463EC (000, 000, 000, 
000)
000  00180046494 (000, 000, 000, 
000)
000  0010040D4D1 (000, 000, 000, 
000)
000  00100401010 (000, 000, 000, 
00100401000)
000  7FFD575B13D2 (000, 000, 000, 
000)
000  7FFD57705444 (000, 000, 000, 
000)

End of stack trace

Everything else seems to work, and I have no idea when this error 
started occuring, because I've been using Cygwin and updating to the 
latest when possible.


Current cygwin version 2.871.

Thanks,
Roger

--
Founder of Matrix AI
http://matrix.ai/
+61420925975


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: g++4.9.2 fails to compile standard C++11 code

[Roger Wells]

On 03/11/2015 06:55 PM, Vlad Gheorghiu wrote:

The following code fails to compile under latest cygwin, Windows 7,
g++4.9.2. Compiled with g++ -std=c++11 test.cpp. The compiler
complains that std::log2 is not a member of std.

 #include cmath
 #include iostream

 int main()
 {
 auto x = std::log2(10);
 std::cout  x  std::endl;
 }


Verbatim error:

 g++ -std=c++11 test.cpp
 test.cpp: In function ‘int main()’:
 test.cpp:5:11: error: ‘log2’ is not a member of ‘std’
   auto x = std::log2(10);
^
 test.cpp:5:11: note: suggested alternative:
 In file included from
/usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/cmath:44:0,
  from test.cpp:1:
 /usr/include/math.h:305:15: note:   ‘log2’
  extern double log2 _PARAMS((double));


FWIW
I get the same error on cygwin64 gcc 4.9.2
but
it is fine on:
Linux, gcc 4.9.2 (Fedora 21)
MinGW, 32 bit, gcc 4.7.0 (Windows 7)
MinGW, 64 bit, gcc 4.9.0 (Windows 7)

HTH


--
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: net user completed with one or more errors

[Roger Wells]

On 03/09/2015 09:43 AM, Kizito Porta Balanyà wrote:

Hello,

Executing net user or cmd.exe /c net user inside a ssh console
returns:  The command completed with one or more errors.

This doesn't happen locally with or without cygwin.

Is this a bug or similar ?

Thanks a lot for your time.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple




FWIW
I tried your test and I think it is ok:

In an SSH session (from a Fedora client to a Cygwin64/Win7 sshd server):

roger@rwells-x220 ~
$ net user

User accounts for \\RWELLS-X220

---
Administratorcyg_server Guest
rogersshd
The command completed successfully.


And:

$ uname -a
CYGWIN_NT-6.1 rwells-x220 1.7.34(0.285/5/3) 2015-02-04 12:14 x86_64 Cygwin

HTH


--
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: slow startup after upgrade

[Roger Orr]

Good work -- at least in my environment ;-)

20150225 DLL:
mkgroup 0.63s
mkpasswd 0.289s

compared to

20150220 DLL:
mkgroup 45.8s
mkpasswd: 4572.7s

Output is
 mkgroup: 53kb, 681 lines
 mkpasswd: 132kb, 1081 lines.

And the output *is* the same :-)

Roger.

-Original Message-
From: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com] 
Sent: 25 February 2015 12:52
To: cygwin@cygwin.com
Subject: Re: slow startup after upgrade

On Feb 25 12:29, Achim Gratz wrote:
 Corinna Vinschen corinna-cygwin at cygwin.com writes:
While you're at it, does the new snapshot still stop after 3.5K
accounts even though you think there are 8K accounts?
 
 $ mkpasswd -d | wc
 
 I get ~30k AD accounts back in 75s instead of 315s and the network traffic
 is only half of the former value as well comparing the 20150224 vs. the
 latest 20150223 snapshot.

Cool!  Thanks for your feedback.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: slow startup after upgrade

[Roger Orr]

Hello Corinna,
It seems slightly faster than the previous patch and I've not noticed a
downside yet.


CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35s(0.286/5/3) 20150220 15:47:55 i686
Cygwin:

~37ms to run echo.exe from Windows command prompt
~60ms to run .\id.exe -a from Windows command prompt

CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35s(0.286/5/3) 20150223 21:02:38 i686
Cygwin: 

~35ms to run echo.exe from Windows command prompt
~53ms to run .\id.exe -a from Windows command prompt

nsswitch.conf: passwd and group both set to 'db'

Regards,
Roger.

-Original Message-
From: Roger Orr [mailto:rog...@howzatt.demon.co.uk] 
Sent: 23 February 2015 23:33
To: 'cygwin@cygwin.com'
Subject: RE: slow startup after upgrade

Hi Corinna,
sounds good. I'll give this a go, all being well, tomorrow.

In other news it appears that the ADInsightDll uses some shared data to
communicate, so in order to get ADInsight to work with injection one has to
ensure that the DLL injected is the same actual *file* as the one loaded by
the ADInsight program (in the (windows) %TEMP% directory) - a copy of the
DLL doesn't seem to be effective.

Regards,
Roger.

-Original Message-
From: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com] 
Sent: 23 February 2015 21:16
To: cygwin@cygwin.com
Cc: Roger Orr
Subject: Re: slow startup after upgrade

Hi Roger,

On Feb 16 20:02, Roger Orr wrote:
 Corinna Vinschen wrote:
  So I'd think the best way forward is to update to the
  1.7.35-0.1 test release and report further from there. 
 
 Thanks, this does help a little. However I will still be using the 'files'
 setting.
 
 Here are some results in case they're of interest. (Windows 7/64 with
 cygwin/64.)
 
 1) Running cygwin echo.exe from a cmd.exe command shell
 
 a) With passwd: files and group: files in /etc/nsswitch.conf
   0.03 - 0.4 s
 
 b) With 1.7.34 and default /etc/nsswitch.conf
 
   around 120s
 
 C) With 1.7.35 and default /etc/nsswitch.conf
 
   4.4 - 4.6s

I rewrote the function responsible for the slow startup, the one
fetching all the group information for the groups in your user token.

As I just wrote in my mail to Dennis Hagarty, the performance improvement
should be noticable, even with /etc/nsswitch.conf only using the db
setting for groups.  The group info for a user token with 150 groups was
fetched in ~50 ms rather than the ~300ms of the former code.

Can you test this again with the Cygwin DLL from the latest developer
snaphshot at https://cygwin.com/snapshots/ please?


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: slow startup after upgrade

[Roger Orr]

Corinna Vinschen wrote:
 Hi Roger,
 
 On Feb 24 19:55, Roger Orr wrote:
 Hello Corinna,
 It seems slightly faster than the previous patch and I've not
 noticed a downside yet. 
 
 
 CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35s(0.286/5/3) 20150220 15:47:55
 i686 Cygwin:
 
 ~37ms to run echo.exe from Windows command prompt
 ~60ms to run .\id.exe -a from Windows command prompt
 
 CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35s(0.286/5/3) 20150223 21:02:38
 i686 Cygwin:
 
 ~35ms to run echo.exe from Windows command prompt
 ~53ms to run .\id.exe -a from Windows command prompt
 
 That's a nice result.
 
 However, I don't quite understand this result for the older DLL.
 Weren't you reporting 4 secs as startup time from 1.7.35?!? 

The slow (4s) startup was from an early 1.7.35 DLL before that of 20150220.

From an earlier message (2015-02-17):

1) Running cygwin echo.exe from a cmd.exe command shell

a) With passwd: files and group: files in /etc/nsswitch.conf
  0.03 - 0.4 s

b) With 1.7.34 and default /etc/nsswitch.conf

  around 120s

C) With 1.7.35 and default /etc/nsswitch.conf

  4.4 - 4.6s

 On another note:
 
 I just uploaded a new developer snapshot (2015-02-24).  This snapshot
 should improve mkpasswd/mkgroup or, generally speaking, enumerating
 AD accounts, a lot.  Can you give it a try?  
 
 While you're at it, does the new snapshot still stop after 3.5K
 accounts even though you think there are 8K accounts?  If so, I'd be
 interested to investigate this further.  The reason is, while testing
 my today's performance improvements, I stumbled over a bug in my code
 which also resulted in enumerating less accounts as desired.  So I'm
 not entirely sure your problem isn't related to a bug either. 


I'll try to find time to give this a go too.

 
 
 Thanks,
 Corinna



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: slow startup after upgrade

[Roger Orr]

Hi Corinna,
sounds good. I'll give this a go, all being well, tomorrow.

In other news it appears that the ADInsightDll uses some shared data to
communicate, so in order to get ADInsight to work with injection one has to
ensure that the DLL injected is the same actual *file* as the one loaded by
the ADInsight program (in the (windows) %TEMP% directory) - a copy of the
DLL doesn't seem to be effective.

Regards,
Roger.

-Original Message-
From: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com] 
Sent: 23 February 2015 21:16
To: cygwin@cygwin.com
Cc: Roger Orr
Subject: Re: slow startup after upgrade

Hi Roger,

On Feb 16 20:02, Roger Orr wrote:
 Corinna Vinschen wrote:
  So I'd think the best way forward is to update to the
  1.7.35-0.1 test release and report further from there. 
 
 Thanks, this does help a little. However I will still be using the 'files'
 setting.
 
 Here are some results in case they're of interest. (Windows 7/64 with
 cygwin/64.)
 
 1) Running cygwin echo.exe from a cmd.exe command shell
 
 a) With passwd: files and group: files in /etc/nsswitch.conf
   0.03 - 0.4 s
 
 b) With 1.7.34 and default /etc/nsswitch.conf
 
   around 120s
 
 C) With 1.7.35 and default /etc/nsswitch.conf
 
   4.4 - 4.6s

I rewrote the function responsible for the slow startup, the one
fetching all the group information for the groups in your user token.

As I just wrote in my mail to Dennis Hagarty, the performance improvement
should be noticable, even with /etc/nsswitch.conf only using the db
setting for groups.  The group info for a user token with 150 groups was
fetched in ~50 ms rather than the ~300ms of the former code.

Can you test this again with the Cygwin DLL from the latest developer
snaphshot at https://cygwin.com/snapshots/ please?


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: Very slow Cygwin startup on Windows 7

[Roger Orr]

  Sysinternals ADInsight is a 32bit only tool and, in order to work on
  a 64bit Windows you seem to have to manually inject the DLL
  ADInsightDll.dll (which is extracted into %TEMP%) into the target
  (32-bit!) process.

 So, it seems ADInsight seems a non-starter - for my skill level anyway.

In case it helps you, or another reader of the list, here is a simple
program that injects a named dll into a target process.

Example of using it to examine the ldap calls for cygwin's echo.exe:

- Compile as a 32-bit program using *32bit* cygwin (as ADInsight is a 32bit
process): g++ inject.cpp -o inject.exe
- Start ADInsight from SysInternals
- Start Windows command shell
- Invoke: inject.exe %TEMP%\ADInsightDll.dll c:\cygwin\bin\echo.exe hello

Regards,
Roger.

- inject.cpp -
/*
NAME
Inject.cpp

DESCRIPTION
Inject a DLL into another process

COPYRIGHT
Copyright (C) 2002,2015 by Roger Orr rog...@howzatt.demon.co.uk

This software is distributed in the hope that it will be useful, but
without WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Permission is granted to anyone to make or distribute verbatim
copies of this software provided that the copyright notice and
this permission notice are preserved, and that the distributor
grants the recipient permission for further distribution as permitted
by this notice.

Comments and suggestions are always welcome.
Please report bugs to rog...@howzatt.demon.co.uk.

EXAMPLE
Inject MyDll fred.exe
*/

#include windows.h

#include string
#include iostream

//
// Local functions
int CreateProcessHelper(char ** it, char ** end, HANDLE  hProcess,
HANDLE  hThread);
int InjectDLL(std::string const dllName, HANDLE hProcess);

//
int main(int argc, char **argv)
{
if (argc  3)
{
std::cerr  Syntax: inject dllname progname  std::endl;
return 1;
}

std::string const dllName = argv[1];
std::string const progName = argv[2];

HANDLE hProcess = 0;
HANDLE hThread = 0;
if (CreateProcessHelper(argv+2, argv+argc, hProcess, hThread) != 0)
{
return 1;
}

if (InjectDLL(dllName, hProcess) != 0)
{
TerminateProcess(hProcess, GetLastError());
return 1;
}

// resume the created process once we've loaded the DLL
if (::ResumeThread(hThread) == (DWORD)-1)
{
std::cout  ResumeThread failed with   GetLastError()
 std::endl;
return 1;
}

DWORD ret = ::WaitForSingleObject(hProcess, INFINITE);
if (ret == WAIT_OBJECT_0)
{
DWORD exitCode;
if (GetExitCodeProcess(hProcess, exitCode))
{
std::cout  Process   progName   terminated: 
 return code:   exitCode  std::endl;
ret = exitCode;
}
else
{
ret = GetLastError();
std::cout  Process terminated: return code unavailable: 
 ret  std::endl;
}
}
else if (ret == WAIT_FAILED)
{
std::cout  Process wait failed:   GetLastError()  std::endl;
}
else
{
std::cout  Process wait failed:   ret  std::endl;
}

return ret;
}

//
// Inject DLL 'dllName' into process 'hProcess'
int InjectDLL(std::string const dllName, HANDLE hProcess)
{
LPTHREAD_START_ROUTINE lpStartAddress = 0;

// Create memory in target process
LPVOID const chDllName = VirtualAllocEx(hProcess, 0, dllName.size() + 1,
MEM_COMMIT, PAGE_READWRITE);
if (chDllName == 0)
{
std::cerr  VirtualAllocEx failed:   GetLastError()
 std::endl;
return 1;
}

// Map into my process
if (! WriteProcessMemory(hProcess, chDllName,
dllName.c_str(), dllName.size()+1, 0))
{
std::cerr  WriteProcessMemory failed:   GetLastError()
 std::endl;
return 1;
}

lpStartAddress = (LPTHREAD_START_ROUTINE)LoadLibrary;

// Start a remote thread, at LoadLibraryA in the target process
// Note we assume KERNEL32 has a fixed load address
DWORD threadId(0);
HANDLE const hRemoteThread = CreateRemoteThread(hProcess, 0, 0,
lpStartAddress, chDllName, 0, threadId);
if (hRemoteThread == 0)
{
std::cerr  CreateRemoteThread failed:   GetLastError()
 std::endl;
return 1;
}

WaitForSingleObject(hRemoteThread, 1);
DWORD exitCode;
if (! GetExitCodeThread(hRemoteThread, exitCode))
{
std::cerr  GetExitCodeThread failed:   GetLastError()
 std::endl;
return 1;
}

if (exitCode == STILL_ACTIVE)
{
std::cout  Remote thread still running...  std::endl;
return 1

RE: slow startup after upgrade

[Roger Orr]

I've tested again with the first patched cygwin1.dll:
CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35(0.286/5/3) 2015-02-16 13:18 i686 Cygwin

I can confirm the connections are occurring within the ldap_search_s call - 
here is one of the call stacks:

00ebc31c 76e5c451 0278 0045dd28 0010 WS2_32!connect (FPO: [Non-Fpo])
00ebc87c 76e5cad5 00462758 00ebc8a4 0185 wldap32!LdapParallelConnect+0x2e3 
(FPO: [Non-Fpo])
00ebca70 76e597a2 00462758 004568a0  wldap32!ConnectToSRVrecs+0x21b 
(FPO: [Non-Fpo])
00ebcac8 76e59688   00462758 wldap32!OpenLdapServer+0x612 (FPO: 
[Non-Fpo])
00ebcae8 76e62ca9 00462758   wldap32!LdapConnect+0x2cf (FPO: 
[Non-Fpo])
00ebcb58 76e63021 00432670  76e8e158 wldap32!LdapChaseReferral+0xb27 
(FPO: [Non-Fpo])
00ebcb98 76e62e1d 0042ca00 004328b0 00432670 wldap32!HandleReferral+0x7ac (FPO: 
[Non-Fpo])
00ebcbd4 76e553e2 0042cab8 00ebcc04  wldap32!HandleReferrals+0x151 
(FPO: [Non-Fpo])
00ebcc08 76e5b0f8 0042cab8 0005 0001 
wldap32!ldap_result_with_error+0x30e (FPO: [Non-Fpo])
00ebcc3c 76e5e584 0042cce4 80039620 0002 wldap32!ldap_search_ext_sW+0x87 
(FPO: [Non-Fpo])
00ebcc80 76e5e783 0042cce4 80039620 0002 wldap32!ldap_search_stW+0x45 (FPO: 
[Non-Fpo])
00ebcca8 610818e2 0042cce4 80039620 0002 wldap32!ldap_search_sW+0x21 (FPO: 
[Non-Fpo])

I can see this occurring with ldp.exe (from Windows Server 2003 support 
tools; also works on newer version of windows) and netstat.exe

Connection-Connect (default server, default port 389)
(1 TCP/IP session to DC1:389)

Connection-Bind (enter username and password)
(no new sessions)

Browse-Search

Base Dn - first naming context
Filter: ((objectClass=trustedDomain)(name=wibble))
Gets 0 entries, quickly, no extra sessions visible


Click 'Options'
Select 'Chase Referrals'
Click Ok

Search again.
Gets 0 entries, takes some seconds, and establishes nuermous TCP/IP connections.

(1) LDAP_OPT_REFERRALS is on by default
(2) The fix added CN=System to the Base Dn - this seems to turn off referrals

--
*aside*
Sysinternals ADInsight is a 32bit only tool and, in order to work on a 64bit 
Windows you seem to have to manually inject the DLL ADInsightDll.dll (which is 
extracted into %TEMP%) into the target (32-bit!) process.

Regards,
Roger.


From: Roger Orr
Sent: 18 February 2015 11:26
To: Corinna Vinschen
Cc: cygwin@cygwin.com
Subject: RE: slow startup after upgrade

Hello Corinna,

I've just been trying out both the 2015-02-18 10:30:19/44 UTC and 2015-02-17 
21:27:23/48 UTC patches.

Both are now down to the same timings as with a 'files' entry in 
/etc/nsswitch.cfg, (and there's no detectable speed difference between them.)

The scope restriction in the second query to \System reduces the query time to 
1.1 - 1.3 ms (was 4 seconds) and also it no longer opens 14 TCP/IP sessions to 
various ldap servers around the planet (!)

I note that mkpasswd and mkgroup do still open many sessions to the ldap 
servers, but that may be inevitable. It's not an issue directly, of course, 
since I'll no longer need to make use of these, but it perhaps might indicate 
another place where the ldap queries are sub-optimal.

Thanks for your rapid response on this issue!
Regards,
Roger.

From: Corinna Vinschen [corinna-cyg...@cygwin.com]
Sent: 18 February 2015 11:18
To: cygwin@cygwin.com
Cc: Roger Orr
Subject: Re: slow startup after upgrade

Hi Roger,

On Feb 17 22:32, Corinna Vinschen wrote:
 On Feb 17 19:13, Roger Orr wrote:
  According to nltest /dclist:
  Our environment has 6 London based DCs
 
  According to ldp.exe Live Enterprise Tree we have a tree structure for LDAP.
 
  6 leaf nodes at the top matching ther 6 DCs
  4 leaf nodes under an AUS (Australia) node
  3 leaf nodes under a CHI (Chicago) node
  and a few more similar to this in other regions.
 
  When running mkpasswd I see active sessions to all the nodes in the tree on
  port 389 (ldap)
 
  I have tried using Sysinternals ADInsight (with a 32bit cygwin) to see what
  requests are made with 'echo.exe'
 
  There are two searches shown:
 
  A) RootDSE:LDAP_SCOPE_BASE:(objectclass=*)  (1.113ms)
  B) London DNS:LDAP_SCOPE_SUBTREE:((objectClass=trustedDomain) AND
  (name=Australian DNS)) (4.426s)
 
  I don't know why the second query is being made with the Australian DNS name
  but I suspect this is the problem.

 Thanks for doing that!  It's really cool to get this info since it seems
 to point to the culprit.

 It's not the problem that the Australian DNS is mentioned here.  This is
 perfectly valid.  The LDAP query is going to the London DNS DC
 (apparently, I hope that's right in your case) and the query is for
 information on a trusted domain.  It looks like you have a group from
 the australian domain in your user token.  To compute the gid of the
 group, cygwin asks *your* DC for a value called posixOffset for *that*
 trusted domain.

 The bottom line

RE: slow startup after upgrade

[Roger Orr]

Hello Corinna,

I've just been trying out both the 2015-02-18 10:30:19/44 UTC and 2015-02-17 
21:27:23/48 UTC patches.

Both are now down to the same timings as with a 'files' entry in 
/etc/nsswitch.cfg, (and there's no detectable speed difference between them.)

The scope restriction in the second query to \System reduces the query time to 
1.1 - 1.3 ms (was 4 seconds) and also it no longer opens 14 TCP/IP sessions to 
various ldap servers around the planet (!)

I note that mkpasswd and mkgroup do still open many sessions to the ldap 
servers, but that may be inevitable. It's not an issue directly, of course, 
since I'll no longer need to make use of these, but it perhaps might indicate 
another place where the ldap queries are sub-optimal.

Thanks for your rapid response on this issue!
Regards,
Roger.

From: Corinna Vinschen [corinna-cyg...@cygwin.com]
Sent: 18 February 2015 11:18
To: cygwin@cygwin.com
Cc: Roger Orr
Subject: Re: slow startup after upgrade

Hi Roger,

On Feb 17 22:32, Corinna Vinschen wrote:
 On Feb 17 19:13, Roger Orr wrote:
  According to nltest /dclist:
  Our environment has 6 London based DCs
 
  According to ldp.exe Live Enterprise Tree we have a tree structure for LDAP.
 
  6 leaf nodes at the top matching ther 6 DCs
  4 leaf nodes under an AUS (Australia) node
  3 leaf nodes under a CHI (Chicago) node
  and a few more similar to this in other regions.
 
  When running mkpasswd I see active sessions to all the nodes in the tree on
  port 389 (ldap)
 
  I have tried using Sysinternals ADInsight (with a 32bit cygwin) to see what
  requests are made with 'echo.exe'
 
  There are two searches shown:
 
  A) RootDSE:LDAP_SCOPE_BASE:(objectclass=*)  (1.113ms)
  B) London DNS:LDAP_SCOPE_SUBTREE:((objectClass=trustedDomain) AND
  (name=Australian DNS)) (4.426s)
 
  I don't know why the second query is being made with the Australian DNS name
  but I suspect this is the problem.

 Thanks for doing that!  It's really cool to get this info since it seems
 to point to the culprit.

 It's not the problem that the Australian DNS is mentioned here.  This is
 perfectly valid.  The LDAP query is going to the London DNS DC
 (apparently, I hope that's right in your case) and the query is for
 information on a trusted domain.  It looks like you have a group from
 the australian domain in your user token.  To compute the gid of the
 group, cygwin asks *your* DC for a value called posixOffset for *that*
 trusted domain.

 The bottom line is, this is not going to Australia, because all DCs have
 this info for their trusted domains in their own DB so it's a planly
 local query.

 However, that mean this local LDAP query is *extremly* slow.  I changed
 the query now to limit the scope of the database search.  This should speed
 up the request a lot.
 [...etc...]

I just release a new test release, 1.7.35-0.3, see
https://cygwin.com/ml/cygwin-announce/2015-02/msg00133.html

This should speed up the search for the trustedDomain info a lot.

Can you please give it a try and perform your fantastic timing test as
above?


Thanks in advance,
Corinna

--
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: slow startup after upgrade

[Roger Orr]

  and also it no longer opens 14
  TCP/IP sessions to various ldap servers around the planet (!)

 Uh, that might be the result of the other changes which don't open an
 LDAP connection to fetch group info.  14 connections probably means,
 you're in 14 groups in other domains than your login domain.

There weren't any other LDAP requests logged (I was testing with the first
patch 1.7.35-0.1 that reduced the time for running echo.exe from 120s to
4.5s) so I don't think it was related to another query.  I may be able to
test this out again tomorrow and get the call stacks of the connect calss.

Incidentally how can you tell the patch level of cygwin1.dll -- the DLL
versions all seem to be 1007.35.0.0 ?

Regards,
Roger.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: slow startup after upgrade

[Roger Orr]

Corinna Vinschen wrote:
 On Feb 16 20:02, Roger Orr wrote:
 Corinna Vinschen wrote:
 So I'd think the best way forward is to update to the
 1.7.35-0.1 test release and report further from there.
 
 Thanks, this does help a little. However I will still be using the
 'files' setting.
 
 The idea was to test this stuff to find a better solution which is
 acceptable.  If you simply revert to files without helping to test
 we'll probably never find the culprit.  

I'm very happy to continue testing; I was merely meaning the 1.7.35
performance is still not adequate in my environment.

 It would be nice to know what part of the code is so slow.  The
 LookupAccountSid calls shouldn't be so slow because they only fetch
 information already cached on the local machine.  So it's probably
 the LDAP call.  Why does an LDAP call take 4 secs?!?   
 
 Are you remote from your DC, by any chance?

I have made some progress with analysis (slightly handicapped as I'm a
novice with ldap and am not an admin)

According to nltest /dclist:
Our environment has 6 London based DCs 

According to ldp.exe Live Enterprise Tree we have a tree structure for LDAP.

6 leaf nodes at the top matching ther 6 DCs
4 leaf nodes under an AUS (Australia) node
3 leaf nodes under a CHI (Chicago) node
and a few more similar to this in other regions.

When running mkpasswd I see active sessions to all the nodes in the tree on
port 389 (ldap)

I have tried using Sysinternals ADInsight (with a 32bit cygwin) to see what
requests are made with 'echo.exe'

There are two searches shown:

A) RootDSE:LDAP_SCOPE_BASE:(objectclass=*)  (1.113ms)
B) London DNS:LDAP_SCOPE_SUBTREE:((objectClass=trustedDomain) AND
(name=Australian DNS)) (4.426s)

I don't know why the second query is being made with the Australian DNS name
but I suspect this is the problem.
(Perhaps it as simple as A coming first in the alphabet ...)

Happy to investigate further if someone can suggest some useful avenues.

Regards,
Roger.





--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: slow startup after upgrade

[Roger Orr]

Corinna Vinschen wrote:
 So I'd think the best way forward is to update to the
 1.7.35-0.1 test release and report further from there. 

Thanks, this does help a little. However I will still be using the 'files'
setting.

Here are some results in case they're of interest. (Windows 7/64 with
cygwin/64.)

1) Running cygwin echo.exe from a cmd.exe command shell

a) With passwd: files and group: files in /etc/nsswitch.conf
  0.03 - 0.4 s

b) With 1.7.34 and default /etc/nsswitch.conf

  around 120s

C) With 1.7.35 and default /etc/nsswitch.conf

  4.4 - 4.6s

2) mkgroup

1.7.34 took 46m 4s
1.7.35 took 39s

output is 53kb, 681 lines

3) mkpasswd

1.7.34 took 1h 14m 6s
1.7.35 took 59m 0s

output is 132kb, 1081 lines

Regards,
Roger.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: slow startup after upgrade

[Roger Orr]

I am also hit by the slow AD issue; so thanks for the solution.

mkpasswd takes an hour and mkgroup takes longer -- is there anything I can
suggest to our administrators that would help make this time less?

We have not had previous problems reported with our AD being slow.

Regards,
Roger.

-Original Message-
From: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com] 
Sent: 11 February 2015 08:53
To: cygwin@cygwin.com
Subject: Re: slow startup after upgrade

On Feb 10 15:52, Warren Young wrote:
  On Feb 10, 2015, at 2:38 AM, Corinna Vinschen
corinna-cyg...@cygwin.com wrote:
  
   Starting a Cygwin shell is slow, what's going on?
  
  I'd not be overly grudgy if somebody wants to come up with a FAQ text.
 
 I'm not entirely sure I understand the problem, but I've attached a
 starting point.
 
 I'm pretty sure the issue brought up in this thread isn't the only
 possible cause of slow launches.  DNS can do it, too, and I suspect if
 I wracked my brain some more on it, I could come up with other causes.
 
 The DocBook isn't validated.  It may need to be adjusted before it
 will let the FAQ document build correctly.  It might also be good to
 include olinks or ulinks to other parts of the Cygwin docs.

Thanks a lot.  I added this to the FAQ in CVS with just the changes
necessary to make it a FAQ entry.  If somebody has to add something,
feel free to send text.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: CYGWIN - As admin setup other users SSH for them?

[Roger Vicker, CCP]

On 6/5/2014 2:46 AM, Warren Young arranged the binary bits such that:

 On 6/4/2014 16:05, Roger Vicker, CCP wrote:
 3) deliver the private key to the user along with the rest of the
 instructions on how to use it in the provided apps.
 How were you planning on delivering these sensitive private keys?  Via
 insecure email, perhaps?

These particular users are barely computer literate so I would be
copying the private keys directly to their Android devices and setting
up the apps that need to use SSH as a tunnel to connect to their server
side apps.

 Use ssh as it was designed: have the users generate their own local
 keypairs, and have them email the public key to you.  The words we use
 here mean something.  The *public* key goes out over the public link,
 and the *private* key stays at home.

I know security. That is why we are implementing SSH with keys to
further secure a remote protocol. VPN is not as practical given the
level of the users, the specific remote devices and app.

 It's not like the commands are difficult.  They set up a local Cygwin,
 add the openssh package, then say:

 $ ssh-keygen
 ...press Enter a bunch of times...
 $ cat ~/.ssh/id_rsa.pub  /dev/clipboard
 ...compose email to rvicker, paste

 With out their passwords I can't login to establish their $home
 directory structure,
 Take a look at /etc/profile, starting at line 75.  See the stuff about
 /etc/skel?  That's how the user's home directory gets set up.  Nothing
 magic here.  You could cut those couple-dozen lines into a new script
 and tweak it for your purposes.

 The only trick is that if you do all this as administrator, you'll
 have to say something like

 # chown -R otheruser.otheruser ~otheruser

 after you get done setting up the user's home directory.



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: CYGWIN - As admin setup other users SSH for them?

[Roger Vicker, CCP]

On 6/10/2014 4:36 PM, Warren Young arranged the binary bits such that:
 On 6/10/2014 14:56, Roger Vicker, CCP wrote:
 These particular users are barely computer literate so I would be
 copying the private keys directly to their Android devices

 In that case, why not just replicate the effect of ssh-copy-id from
 each Android device before it leaves your hands?

1) The point of using keys is to eliminate password login (there are
other layers involved elsewhere).
2) Even if I temporarily enabled password login I would need the
user's password to this network.
3) The usual after necessary sharing a password changing of it upsets
the user as the periodic change is always too frequent.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

CYGWIN - As admin setup other users SSH for them?

[Roger Vicker, CCP]

I've got a Windows system setup with SSH in CYGWIN working.

I've used mkpaswd to install the users in /etc/passwd.

As administrator I want to:
1) generate the key pairs for the other users.
2) install the public key in the users $home/.ssh/authorized_keys.
3) deliver the private key to the user along with the rest of the
instructions on how to use it in the provided apps.

With out their passwords I can't login to establish their $home
directory structure, run ssh-keygen, copy the key files.

Thanks.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: cygcheck and literal plus sign

[Gates, Roger]

On Friday, January 24, 2014 9:26 PM Steven Penny wrote
On Wed, Jan 22, 2014 at 10:05 AM, David Boyce wrote
 How about 'g[+][+]' or 'g[+]{2}'?

Please, no more lazy answers

$ cygcheck -p 'g[+][+].exe'
Found 0 matches for g[ ][ ].exe

$ ascii +
ASCII 2/11 is decimal 043, hex 2b, octal 053, bits 00101011: prints as `+'
Official name: Plus Sign
Other names: Add, Cross

$ cygcheck -p 'g\x{2b}\x{2b}.exe'
Found 11 matches for g\x{2b}\x{2b}.exe
x86/cygwin64-gcc-g++/cygwin64-gcc-g++-4.8.2-1
x86/cygwin64-gcc-g++/cygwin64-gcc-g++-4.8.2-2
x86/gcc-g++/gcc-g++-4.8.2-1
x86/gcc-g++/gcc-g++-4.8.2-2
x86/gcc4-g++/gcc4-g++-4.7.3-2
x86/mingw-gcc-g++/mingw-gcc-g++-4.5.2-1
x86/mingw-gcc-g++/mingw-gcc-g++-4.7.3-1
x86/mingw64-i686-gcc-g++/mingw64-i686-gcc-g++-4.8.2-1
x86/mingw64-i686-gcc-g++/mingw64-i686-gcc-g++-4.8.2-2
x86/mingw64-x86_64-gcc-g++/mingw64-x86_64-gcc-g++-4.8.2-1
x86/mingw64-x86_64-gcc-g++/mingw64-x86_64-gcc-g++-4.8.2-2
$

Roger L. Gates

__
This e-mail has been scanned by Verizon Managed Email Content Service, using 
Skeptic(tm) technology powered by MessageLabs. For more information on 
Verizon's Managed Email  Content Service, visit http://www.verizonbusiness.com.
__

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: Problem with Cygwin 1.7.17 + Bash and Grep...

[Gates, Roger]

I'm essentially trying to take the contents of one file, and use it as
input for a grep command against another file, but I do not get any
results, even though I know the 2nd file contains a match.  In the
one-liner below, I include an echo to confirm the output is in the
variable that should be used with the grep command.

[vmorales@D630-Vmorales ~]# for i in `cat file-a.txt`; do echo $i;
grep $i file-b.txt; done
alpha
beta
charlie
delta
echo

[vmorales@D630-Vmorales ~]# grep charlie file-b.txt
charlie,13

File-a.txt must be in DOS format. Try this. 

for i in `cat file-a.txt | d2u`; do echo $i;
grep $i file-b.txt; done
alpha
beta
charlie
charlie,13
delta
echo

Roger



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

suggestion/feature request: some help to pick a mirror for setup.exe

[Roger Pack]

it might be interesting/useful to have the list of mirrors ordered
somehow, it is a bit bewildering (at least for this user) to get this
large list of mirros to unfamiliar mirror sites and I think
ok...so...which one should I pick here?
So maybe if it could ping all of them and order by that, or anything
else like that.
A suggestion to make it more understandable, the install process.
Thanks!
-roger-

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: disk format question

[Roger K. Wells]

On 01/08/2013 10:14 AM, Warren Young wrote:

On 1/8/2013 06:59, bartels wrote:


The windows format.com


format.com hasn't existed since the DOS days.  That includes the 
DOS-based versions of Windows, up through Windows ME.  Under 
NT-derived versions of Windows, format is a built-in command in 
cmd.exe.

FWIW in Windows 7:

objdump -p c:/Windows/System32/format.com

c:/Windows/System32/format.com: file format pei-i386

Characteristics 0x102
executable
32 bit words

Time/Date   Tue Jul 14 00:15:15 2009
Magic   010b(PE32)

I don't know if that changes anything here though.

Roger Wells


 claims the fs is write protected, but I hope dd

can help out.


It's worth a try, but if I had to take a blind bet on it, I'd say 
you're going to find that dd will give the same result.  Cygwin is 
essentially a user-level process.  If cmd.exe cannot do a thing, 
dd.exe probably can't, either.


It is *possible* that unmounting the filesystem with the 
task/c/Windows/System32/format.combar button will let you write to the 
raw device.  But Windows being Windows, it's possible that will make 
it disappear from the system entirely, too.



The mtab is not very helpful:


That's because Cygwin proper does not mount local filesystems. The 
Cygwin mount table just shows you Cygwin-specific mappings that it has 
added on top of what the underlying NT kernel has done.


In this case...


  D: /cygdrive/d udf binary,posix=0,user,noumount,auto 1 1


...it is showing you the /cygdrive/d alias Cygwin has provided for you.


My question is this: which device in /dev do I use?


According to [this][1] it's probably /dev/sdb.  But please do read 
through what I pointed you to first, and check its applicability 
carefully before attempting this.


[1] 
http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple





--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Ctrl+C not working with windows programs in Cygwin 1.7.16

[Roger K. Wells]

On 08/02/2012 07:03 PM, Daniel Colascione wrote:

On 8/2/2012 4:00 PM, Christopher Faylor wrote:

On Thu, Aug 02, 2012 at 09:32:09PM +0200, Marcin Kielar wrote:

Steps to reproduce:

1. Start cygwin using cygwin.bat
2. Run `ping -t google.com`
3. Try breaking it with Ctrl+C

Expected behaviur:
The ping breaks execution and the command prompt is shown and available

Actual behaviour:
Nothing happens, ping loops until killed with `/usr/bin/kill -f PID`

I don't have a cygwin.bat but if I start bash via Start-Run this
works for me.  ping is interrupted by CTRL-C.

I can repro the problem using exactly those steps. I'm using CYGWIN_NT-6.1-WOW64
xyzzy 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin. Does the most recent
snapshot have something that would make the results different?




so can I


--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Ctrl+C not working with windows programs in Cygwin 1.7.16

[Roger K. Wells]

On 08/03/2012 08:48 AM, Nellis, Kenneth wrote:

-Original Message-
From: Roger K. Wells
snip
Getting a PID  using kill just takes too long.
-END Original Message-

pkill from the procps package might mitigate the pain.
--Ken Nellis

that too is a work around.
The point here is what is the rationale for changing the way Cygwin bash 
works after fifteen years?

It used to behave like bash on any other OS, now it doesn't.
rkw

--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Ctrl+C not working with windows programs in Cygwin 1.7.16

[Roger K. Wells]

On 08/03/2012 12:23 PM, Christopher Faylor wrote:

On Thu, Aug 02, 2012 at 09:32:09PM +0200, Marcin Kielar wrote:

Steps to reproduce:

1. Start cygwin using cygwin.bat
2. Run `ping -t google.com`
3. Try breaking it with Ctrl+C

Expected behaviur:
The ping breaks execution and the command prompt is shown and available

I've uploaded a snapshot which should fix this issue.

seems to have fixed it. Thanks

It's likely that
we will now hear from the other contingent of people who will be outraged
that Cygwin now behaves differently.

Welcome to Cygwin Open Source development.

http://cygwin.com/snapshots/

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple






--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: CTRL+C is not working with java on latest cygwin 1.7.15

[Roger K. Wells]

On 07/11/2012 04:07 PM, saltnlight5 wrote:

Thanks for the reply K Stahl, but it didn't work for me. I ran the same
Test, then press CTRL+C. But the cygwin terminal did nothing. It did not
stop the java process, and it did not print any thing further. I must
manually terminate the process by going into Windows TaskManager.

Again, here is my cygwin version:
$ uname -srv
CYGWIN_NT-5.1 1.7.15(0.260/5/3) 2012-05-09 10:25

Am I on the latest version as you said? Did I miss any other config?

Thanks
Zemian


saltnlight5 wrote:

I do have the latest cygwin install. In fact I re-installed just today and
it's still not working.

I printed the full version in my previous email. Was that not the lastest
cygwin version?


K Stahl wrote:

Just tested with this against the latest release version (1.7.15) and
everything works as expected.

Example:
public final class Test {
 public static void main(String[] args) {
 System.out.println(This shall hang until CTRL-C is pressed...);
 for (;;);
 }
}

javac -cp . Test.java
java -cp . Test

Press CTRL-C and you are returned to the terminal.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple







-

Zemian Deng

This is still a problem.
CYGWIN_NT-6.1 rwells-w7 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin

We have been developing CLI applications for close to 20 years and have 
never had a
problem with the cygwin bash shell failing to pass Ctrl-C signals to the 
application until now.

Luckily the cmd.exe still does.

Let me know if it something that I can help track down.  Glad to help if 
possible.



--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Ctrl+C not working with windows programs in Cygwin 1.7.16

[Roger K. Wells]

On 08/02/2012 04:26 PM, Daniel Colascione wrote:

On 8/2/2012 12:32 PM, Marcin Kielar wrote:

Steps to reproduce:

1. Start cygwin using cygwin.bat
2. Run `ping -t google.com`
3. Try breaking it with Ctrl+C

This problem arises from Cygwin's use of CREATE_NEW_PROCESS_GROUP. From MSDN:

When a process is created with CREATE_NEW_PROCESS_GROUP specified, an implicit
call to SetConsoleCtrlHandler(NULL,TRUE) is made on behalf of the new process;
this means that the new process has CTRL+C disabled. This lets shells handle
CTRL+C themselves, and selectively pass that signal on to sub-processes.
CTRL+BREAK is not disabled, and may be used to interrupt the process/process 
group.

SetConsoleCtrlHandler(NULL,TRUE) tells a process and all its children to ignore
control-C. This problem only affects programs run in a console --- in a pty,
Cygwin just terminates Windows processes in response to SIGINT.


This may be true but it is a recent development.
From the similar thread that specifies a java process my remarks:


This is still a problem.
CYGWIN_NT-6.1 rwells-w7 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin

We have been developing CLI applications for close to 20 years and 
have never had a
problem with the cygwin bash shell failing to pass Ctrl-C signals to 
the application until now.

Luckily the cmd.exe still does.

Let me know if it something that I can help track down.  Glad to help 
if possible.




--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Ctrl+C not working with windows programs in Cygwin 1.7.16

[Roger K. Wells]

On 08/02/2012 05:21 PM, Daniel Colascione wrote:

On 8/2/2012 2:02 PM, Roger K. Wells wrote:

On 08/02/2012 04:26 PM, Daniel Colascione wrote:

On 8/2/2012 12:32 PM, Marcin Kielar wrote:

Steps to reproduce:

1. Start cygwin using cygwin.bat
2. Run `ping -t google.com`
3. Try breaking it with Ctrl+C

This problem arises from Cygwin's use of CREATE_NEW_PROCESS_GROUP. From MSDN:

When a process is created with CREATE_NEW_PROCESS_GROUP specified, an implicit
call to SetConsoleCtrlHandler(NULL,TRUE) is made on behalf of the new process;
this means that the new process has CTRL+C disabled. This lets shells handle
CTRL+C themselves, and selectively pass that signal on to sub-processes.
CTRL+BREAK is not disabled, and may be used to interrupt the process/process
group.

SetConsoleCtrlHandler(NULL,TRUE) tells a process and all its children to ignore
control-C. This problem only affects programs run in a console --- in a pty,
Cygwin just terminates Windows processes in response to SIGINT.


This may be true but it is a recent development.

ISTR a change a little while ago that made Cygwin not send SIGINT to processes
controlled by actual consoles (as opposed to ptys) under the assumption that the
Windows console machinery would do the job. It looks like the two changes
interact unpleasantly.


I can't tell how much I want the old way back.  I'll have to start using 
the MS command prompt.

Getting a PID  using kill just takes too long.

--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Trusted Software Vendor

[Roger K. Wells]

On 06/12/2012 11:10 AM, Earnie Boyd wrote:

On Tue, Jun 12, 2012 at 10:46 AM, James Johnston wrote:

  Wikipedia says that ...

Wikipedia isn't the keeper of the information relevant to Cygwin.  You
can only find the truth at cygwin.com.  Besides, companies do support
open source projects by providing man hours to it.  It doesn't mean
that the company providing those hours has any other right to it than
you or I do.  Cygwin is a separate entity from Red Hat.

What's this then?

http://www.redhat.com/software/cygwin/  a link on: http://cygwin.com/

If they are a separate entity this will certainly mislead some of us






--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 'more' segment faults with latest cygwin1.dll (1.7.11)

[Roger K. Wells]

On 02/27/2012 12:14 PM, Jim Reisert AD1C wrote:

'more' is segment faulting with the latest Cygwin .DLL (1.7.11).  I
can reproduce this problem on both a Windows 7 64-bit machine and a
Windows XP 32-bit machine.

I've attached the stackdump and cygcheck output.

Here's how to reproduce the problem:

1.  'more' a long text file
2.  Use / to search for some text, more will stop at the first match
3.  Use 'n' to search for another match.  At this point, it will segment fault

I can verify that this is also the case on Windows 7, 32bit
uname -r: 1.7.11(0.260/5/3)



-rwxr-xr-x 1 reisert root 31246 Jun 24  2010 /usr/bin/more

same here




--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7.9-1 Patch command mangles permissions on windows 7

[Roger Pack]

 When you're running Cygwin tools outside cygwin shell, you need to let Windows
 do the security handling for you.

Thanks!
-r

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7.9-1 Patch command mangles permissions on windows 7

[Roger Pack]

 This could be related to the problem discussed starting at

  http://cygwin.com/ml/cygwin/2009-11/msg00922.html

 The issue there was ACLs on the temporary directory used by patch.  The
 resolution of that was to set TMP and TEMP to /tmp in Cygwin's default
 startup files (see /etc/defaults/profile).  But you appear to be running
 patch outside of a Cygwin shell, so you're not benefiting from that fix.
  (I'm basing this guess on the fact that you start patch by giving its
 Windows path.)

Thanks sounds about right.
Thanks for the help.
-r

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Executing a basic program

[Roger K. Wells]

On 05/20/2011 10:10 PM, Agnelomaria wrote:

Hi,

I am just learning to program in C++ . I am following  a book called
Exploring C++ . The first task is to execute the code which I will paste
below. I have compiled the code . I tried executing the code using ./a.exe
command but the code does not seem to terminate. I have no idea what the
code means. the book asks the user to try the code so as to get familiarized
with the coding environment. Could someone please help me execute the code.
I am not sure what input I should provide

Code :



///sort the standard input alphabetically
///read teh lines of the text sort themand print theresults tothe standard
output.
///if the command line names a file, read from that file. Otherwise, read
fromt he standard input.
///the entire file is stored int he memory so donot tyr thiswiht input files
that ecxeed the size of the ram




#include
#include
#include
#include
#include
#include
#include


we need some filenames here.
roger wells

void read(std::istream  in, std::vector  text)
{
std::string line;
while (std::getline(in, line))
text.push_back(line);
}

int main(int argc, char* argv[])
{
//Part1.read the entire input into the text.. If the command line names 
a
file, read that file. Otherwise ,read the standard input
std::vector text; ///(std::cout, \n));

}





--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Executing a basic program

[Roger K. Wells]

On 05/20/2011 10:10 PM, Agnelomaria wrote:

Hi,

I am just learning to program in C++ . I am following  a book called
Exploring C++ . The first task is to execute the code which I will paste
below. I have compiled the code . I tried executing the code using ./a.exe
command but the code does not seem to terminate. I have no idea what the
code means. the book asks the user to try the code so as to get familiarized
with the coding environment. Could someone please help me execute the code.
I am not sure what input I should provide

Code :



///sort the standard input alphabetically
///read teh lines of the text sort themand print theresults tothe standard
output.
///if the command line names a file, read from that file. Otherwise, read
fromt he standard input.
///the entire file is stored int he memory so donot tyr thiswiht input files
that ecxeed the size of the ram




#include
#include
#include
#include
#include
#include
#include


we need some filenames here.
then I'll try to help.
roger wells

void read(std::istream  in, std::vector  text)
{
std::string line;
while (std::getline(in, line))
text.push_back(line);
}

int main(int argc, char* argv[])
{
//Part1.read the entire input into the text.. If the command line names 
a
file, read that file. Otherwise ,read the standard input
std::vector text; ///(std::cout, \n));

}





--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: ITP dos2unix 5.2.1-1

[Roger K. Wells]

On 03/17/2011 03:56 PM, Erwin Waterlander wrote:

Op 17-3-2011 17:57, Charles Wilson schreef:

Final point: I realize nobody wants to maintain a non-upstreamable
forked version of software.  Everybody wants to be able to build
software on cygwin out of the box.

So...if the upstream people really really hate --follow/--no-follow and
won't accept it, then maybe an all-at-once change here on cygwin would
be okay.  Ditto --safe.

But...that's not an issue here, because *you* are the upstream people!

So let's rephrase: What is the upstream objection to providing a few
new options, with no change in upstream's current default behavior:

--followfollow symbolic links and modify the pointed-to
file. This differs from --force, which breaks
the symbolic link, replaces it with a local
copy, and modifies the copy. If --force, then
--follow has no effect.

--no-followdo not follow symbolic links.  If --force, then
--no-follow has no effect.
...
--safe  Do not modify binary files; opposite of --force.
(default)

Time to create the patch?  Patch requires too many internal changes that
are too ugly, due to internal architecture (can't imagine this is the
objection to --safe; that's a two-liner)?  Style?


Hi Chuck,

I'm willing to maintain patches for Cygwin, to make the transition 
easier. But if there is no chance that the package gets accepted, I 
rather save myself the trouble.


My 2cents worth:  I for one look forward to the new package.  All of the 
software we develop runs on both platforms and I personally use the 
dos2unix, etc tools often.  Same tools on both platforms gets my vote 
anytime.

roger wells


best regards,

Erwin


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple





--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: dd to thumb drive, W7 permission problem

[Roger K. Wells]

On 03/14/2011 11:29 AM, Charles Russell wrote:
The following works on Windows XP, but fails on Windows 7, apparently 
because of some permission setting (even in Administrator mode).


# dd if=binary.img of=/dev/sdb
dd: writing to `/dev/sdb': Permission denied
3+0 records in
2+0 records out
1024 bytes (1.0 kB) copied, 0.081 s, 12.6 kB/s

I would be grateful for suggestions of what to change and where to 
find it.



Here's what I had to do to get any usb drive to be accessible on Windows 7
in fstab:

e:/ /mnt/e ntfs noacl, nouser, binary

obviously pick your own mount point(/mnt/e), source(e:/), and filesystem 
type (ntfs).
I put four of these lines in for e:/, f:/, g:/, h:/  to cover all 
(hopefully) eventualities.

May not be the only, best, approved, etc way but it got me going.

HTH,
roger wells



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple





--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7.8: Fortran I/O rounding inaccuracy

[Roger K. Wells]

On 03/07/2011 04:39 AM, Thomas Henlich wrote:

Hi,

I found the following bug in cygwin 1.7.8 on Windows XP:

Fortran I/O rounding truncates the result after a certain number of
digits. The following program:
===
write(*, '(f35.32)') 0.14285714285714285d0
end
===
gives this output:
  0.142857142857142849212690
The expected output is:
  0.14285714285714284921269268124888

This is in violation of the Fortran 2008 standard which demands:

===
10.7.2.3.7 I/O rounding mode

2. In what follows, the term decimal value means the exact decimal number as
given by the character string, while the term internal value means the number
actually stored in the processor.  For example, in dealing with the decimal
constant 0.1, the decimal value is the mathematical quantity 1/10, which has no
exact representation in binary form.  Formatted output of real data involves
conversion from an internal value to a decimal value; formatted input involves
conversion from a decimal value to an internal value.

3.  When the I/O rounding mode is UP, the value resulting from conversion shall
be the smallest representable value that is greater than or equal to the
original value. When the I/O rounding mode is DOWN, the value resulting
from conversion shall be the largest representable value that is less than or
equal to the original value. ...
===

Applied to the example this means, 0.14285714285714284921269268124888
is the largest representable
(with 32 decimal digits) value that is less than the original value (binary
1.001001001001001001001001001001001001001001001001001 * 2^-3 = decimal
0.1428571428571428492126926812488818...), but
0.142857142857142849212690 is NOT.

The problem seems limited to the Fortran language, because the C call
printf(%35.32f\n, 0.14285714285714285) prints the expected result:
  0.14285714285714284921269268124888

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple


uname -a: CYGWIN_NT-6.1 rwells-w7 1.7.8(0.236/5/3) 2011-03-01 09:36 i686 
Cygwin


round.f:
  program round
  write(*,'(f35.32)') 0.14285714285714285d0
  end

output:
 0.14285714285714284921269268124888

did I miss something?

HTH,
roger wells



--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7.8: Fortran I/O rounding inaccuracy

[Roger K. Wells]

On 03/07/2011 10:44 AM, Roger K. Wells wrote:

On 03/07/2011 04:39 AM, Thomas Henlich wrote:

Hi,

I found the following bug in cygwin 1.7.8 on Windows XP:

Fortran I/O rounding truncates the result after a certain number of
digits. The following program:
===
write(*, '(f35.32)') 0.14285714285714285d0
end
===
gives this output:
  0.142857142857142849212690
The expected output is:
  0.14285714285714284921269268124888

This is in violation of the Fortran 2008 standard which demands:

===
10.7.2.3.7 I/O rounding mode

2. In what follows, the term decimal value means the exact decimal 
number as
given by the character string, while the term internal value means 
the number
actually stored in the processor.  For example, in dealing with the 
decimal
constant 0.1, the decimal value is the mathematical quantity 1/10, 
which has no
exact representation in binary form.  Formatted output of real data 
involves
conversion from an internal value to a decimal value; formatted input 
involves

conversion from a decimal value to an internal value.

3.  When the I/O rounding mode is UP, the value resulting from 
conversion shall

be the smallest representable value that is greater than or equal to the
original value. When the I/O rounding mode is DOWN, the value resulting
from conversion shall be the largest representable value that is less 
than or

equal to the original value. ...
===

Applied to the example this means, 0.14285714285714284921269268124888
is the largest representable
(with 32 decimal digits) value that is less than the original value 
(binary

1.001001001001001001001001001001001001001001001001001 * 2^-3 = decimal
0.1428571428571428492126926812488818...), but
0.142857142857142849212690 is NOT.

The problem seems limited to the Fortran language, because the C call
printf(%35.32f\n, 0.14285714285714285) prints the expected result:
  0.14285714285714284921269268124888

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple


uname -a: CYGWIN_NT-6.1 rwells-w7 1.7.8(0.236/5/3) 2011-03-01 09:36 
i686 Cygwin


round.f:
  program round
  write(*,'(f35.32)') 0.14285714285714285d0
  end

output:
 0.14285714285714284921269268124888

did I miss something?

answer to my own question: yes

if compiling with g77
output: 0.14285714285714284921269268124888

if compiling with gfortran:
output: 0.142857142857142849212690

a bit of a surprise.

rkw


HTH,
roger wells






--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7.8: Fortran I/O rounding inaccuracy

[Roger K. Wells]

On 03/07/2011 12:15 PM, Peter Brown wrote:

Roger K. WellsROGER.K.WELLSat  saic.com  writes:


On 03/07/2011 10:44 AM, Roger K. Wells wrote:

On 03/07/2011 04:39 AM, Thomas Henlich wrote:

Hi,

I found the following bug in cygwin 1.7.8 on Windows XP:

Fortran I/O rounding truncates the result after a certain number of
digits. The following program:
===
write(*, '(f35.32)') 0.14285714285714285d0
end
===
gives this output:
   0.142857142857142849212690
The expected output is:
   0.14285714285714284921269268124888


I don't think this has anything to do with cygin. On our linux system I get

With Intel ifort:
  0.14285714285714284921269268124888

With gfortran 4.1.2s544
  0.1428571428571428492126927000


I agree.  It's a GCC problem.  I get the same results on Cygwin  Linux:
compiling with g77 gives correct output
compiling with gfortran does not.
rkw


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple





--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: cygpath

[Roger K. Wells]

On 03/02/2011 09:05 AM, Jim P wrote:

I just updated my cygwin install,

so did I (an hour ago)

  and cygpath appears to be broken.  Issuing the
command cygpath, with any or no command-line options, returns nothing and a
status of 127.


cygpath works as expected
roger wells

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple





--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Installing Pine

[ROGER CARSLEY]

Apologies if I have missed the obvious but as a newby I was expecting to be 
able 
find that installing pine would be relatively straightforward.  Although it 
appears in the Setup Package Search I cannot seem to find it in set.exe either 
under mail or by search.

Thanks in anticipation for any help.

Roger

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

gettext/libiconv and libtool problem

[Roger While]

Charles Wilson wrote

Roger While wrote:

 gettext has a requirement on libiconv2.
 libiconv2 contains only the cygiconv dll and nothing else.

 OK. So we have a typical (libtooled) autoconf/automake configure which has
 a AM_GNU_GETTEXT([external]).

 Fine, the configure proceeds and produces something like -

 checking for GNU gettext in libc... no
 checking for iconv... no, consider installing GNU libiconv
 checking for GNU gettext in libintl... yes
 checking whether to use NLS... yes
 checking where the gettext function comes from... external libintl
 checking how to link with libintl... -lintl

 etc.
 Also fine.

 We then do the make which blows up with -

 libtool: link: cannot find the library `/usr/lib/libiconv.la' or
 unhandled argument
 `/usr/lib/libiconv.la'

This means that the libiconv development files are a *build-time*
dependency of whatever you're compiling.  They are not *run-time*
dependencies of any of the binaries in the gettext package.

gettext.exe works just fine, without libiconv.la
ditto ngettext.exe
ditto ditto envsubst.exe

The cygwin setup.hint requires: flag is used to represent *run-time*
dependencies, not stuff that would probably be nice to have installed
along with package A, IF you are using package A in /this/ particular
way, and then later run all this other stuff while compiling package C.

The gettext binaries run without error.  They may, perhaps, leave traces
in configure scripts -- such that when you run that configure script,
and then later run make, which runs gcc, which runs ld, you may find
that at THAT time, you'd need libiconv.la.

No way is that a run-time requirement of the original gettext binaries.

--
Chuck


Well, that's not how I interpret the instructions for setup.hint at
http://cygwin.com/setup.html
Quote -
The requires line indicates the packages that this package relies on. If 
your package is dependent on a file provided by another package that other 
package should be included here. The requires field may be missing or empty 
if your package truly does not require any other package.

End-quote.

Note that dependent on a file.

gettext supplies libintl.la.
That file requires libiconv.la.

Note that the configure is using the standard documented way of testing
the usability of gettext -
AM_GNU_GETTEXT([external])
and then testing the (libtool) variable LTLIBINTL for a non-empty string
(It isn't; it contains -lintl).

It is not clear to me how one could check for this situation in configure.

Roger






--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

gettext/libiconv and libtool problem

[Roger While]

gettext has a requirement on libiconv2.
libiconv2 contains only the cygiconv dll and nothing else.

OK. So we have a typical (libtooled) autoconf/automake configure which has
a AM_GNU_GETTEXT([external]).

Fine, the configure proceeds and produces something like -

checking for GNU gettext in libc... no
checking for iconv... no, consider installing GNU libiconv
checking for GNU gettext in libintl... yes
checking whether to use NLS... yes
checking where the gettext function comes from... external libintl
checking how to link with libintl... -lintl

etc.
Also fine.

We then do the make which blows up with -

libtool: link: cannot find the library `/usr/lib/libiconv.la' or unhandled 
argument

`/usr/lib/libiconv.la'

It looks to me as though libiconv2 should be supplying libiconv.la
as the gettext libintl.la has these lines -

# Libraries that this one depends upon.
dependency_libs=' -L/usr/lib /usr/lib/libiconv.la'

In fact I wonder whether or not gettext should require libiconv
instead of/as well as libiconv2.

Roger


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Why require ps -W and kill -f

[Roger K. Wells]

Don Beusee wrote:

ps -e on Unix displays “every process running on the system”.  This command
doesn't do that under cygwin.  Why should it be necessary to supply -W to
see all processes running on the system?  This makes it incompatible with
Linux/Unix, and such scripts that rely on -e doing this will not work the
same on Cygwin.  What is the point to not showing all other processes on the
system like Linux/Unix does?  This is a silly design and causes headaches
and frustration for people trying to write scripts that work on cygwin and
Linux/Unix. Can this be changed please?

  

FWIW I just alias: ps='ps -W'
works fine
roger wells


-Don



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple


  



--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [Fwd: Blue screen when running installation *.sh]

[Roger K. Wells]

*%20ThinkCentre%20A50%20%28type%208084%2C%208085%2C%208126%2C%208147%2C%208148%2C%208149%2C%208174%2C%208175%2C%208176%2C%208177%2C%208178%2C%208089%2C%208090%2C%208320%2C%208419%29%0A%20%20%20%20*%20ThinkCentre%20A50p%20%28type%208192%2C%208193%2C%208194%2C%208195%2C%208196%2C%208197%2C%208432%2C%208433%29%0A%20%20%20%20*%20ThinkCentre%20A51%20%28type%208424%2C%208425%2C%208428%29%0A%20%20%20%20*%20ThinkCentre%20A51p%20%28type%208420%2C%208421%2C%208422%2C%208423%2C%208426%2C%208427%29%0A%20%20%20%20*%20ThinkCentre%20M50%20%28type%208128%2C%208185%2C%208186%2C%208187%2C%208188%2C%208189%2C%208190%2C%208413%2C%208414%2C%208415%2C%208430%2C%208431%29%0A%20%20%20%20*%20ThinkCentre%20M50e%20%28type%208179%29%0A%20%20%20%20*%20ThinkCentre%20M51%20%28type%208095%2C%208141%2C%208142%2C%208143%2C%208144%2C%208145%2C%208146%29%0A%20%20%20%20*%20ThinkCentre%20S50%20%28type%208086%2C%208087%2C%208088%2C%208094%2C%208127%2C%208183%2C%208184%2C%208416%2C%208417%2C%208418%2C%208429%29%0A%20%20%20%20*%20ThinkCentre%20S51%20%28type%208098%2C%208171%2C%208172%2C%208173%29%0A%20%20%20%20*%20NetVista%20%28type%202273%2C%202289%2C%202292%2C%206043%2C%206343%2C%206349%2C%206350%2C%206790%2C%206791%2C%206792%2C%206793%2C%206794%2C%206795%2C%206823%2C%206824%2C%206825%2C%206826%2C%208181%2C%208182%2C%208301%2C%208303%2C%208304%2C%208305%2C%208306%2C%208307%2C%208308%2C%208309%2C%208310%2C%208311%2C%208312%2C%208313%2C%208314%2C%208315%2C%208317%2C%208318%2C%208319%29%0A%0A%0ASolution%0AUpdate%20the%20Rescue%20and%20Recovery%20software%20for%20Windows%202000%2FXP%20to%20version%203.1%20or%20later.%0A 
http://www.google.com/search?q=IBMFILTER.SYS%20may%20cause%20a%20Stop%20Error%20Message%2C%20or%20Microsoft%20Windows%20may%20stop%20responding%20with%20an%20error%20message%20on%20a%20blue%20screen%2C%20or%20the%20system%20may%20restart%20just%20after%20the%20error%20message.%0A%0AAffected%20configuration%0AAny%20of%20the%20following%20systems%20with%20an%20installed%20version%20of%202.00.0170%20or%20older%20of%20the%20Rescue%20and%20Recovery%20software%20and%20running%20Microsoft%20Windows%202000%20or%20Windows%20XP%3A%0A%0A%20%20%20%20*%20ThinkPad%20A31%2C%20A31p%0A%20%20%20%20*%20ThinkPad%20G40%2C%20G41%0A%20%20%20%20*%20ThinkPad%20R30%2C%20R31%2C%20R32%2C%20R40%2C%20R40e%2C%20R50%2C%20R50e%2C%20R50p%2C%20R51%2C%20R52%2C%20R60%2C%20R60e%0A%20%20%20%20*%20ThinkPad%20T23%2C%20T30%2C%20T40%2C%20T40p%2C%20T41%2C%20T41p%2C%20T42%2C%20T42p%2C%20T43%2C%20T43p%2C%20T60%2C%20T60p%0A%20%20%20%20*%20ThinkPad%20X22%2C%20X23%2C%20X24%2C%20X30%2C%20X31%2C%20X40%2C%20X41%2C%20X41%20Tablet%2C%20X60%2C%20X60s%0A%20%20%20%20*%20ThinkPad%20Z60m%2C%20Z60t%2C%20Z61e%2C%20Z61m%2C%20Z61p%2C%20Z61t%0A%20%20%20%20*%20ThinkCentre%20A30%20%28type%202296%2C%208191%2C%208198%2C%208199%2C%208316%2C%208434%29%0A%20%20%20%20*%20ThinkCentre%20A50%20%28type%208084%2C%208085%2C%208126%2C%208147%2C%208148%2C%208149%2C%208174%2C%208175%2C%208176%2C%208177%2C%208178%2C%208089%2C%208090%2C%208320%2C%208419%29%0A%20%20%20%20*%20ThinkCentre%20A50p%20%28type%208192%2C%208193%2C%208194%2C%208195%2C%208196%2C%208197%2C%208432%2C%208433%29%0A%20%20%20%20*%20ThinkCentre%20A51%20%28type%208424%2C%208425%2C%208428%29%0A%20%20%20%20*%20ThinkCentre%20A51p%20%28type%208420%2C%208421%2C%208422%2C%208423%2C%208426%2C%208427%29%0A%20%20%20%20*%20ThinkCentre%20M50%20%28type%208128%2C%208185%2C%208186%2C%208187%2C%208188%2C%208189%2C%208190%2C%208413%2C%208414%2C%208415%2C%208430%2C%208431%29%0A%20%20%20%20*%20ThinkCentre%20M50e%20%28type%208179%29%0A%20%20%20%20*%20ThinkCentre%20M51%20%28type%208095%2C%208141%2C%208142%2C%208143%2C%208144%2C%208145%2C%208146%29%0A%20%20%20%20*%20ThinkCentre%20S50%20%28type%208086%2C%208087%2C%208088%2C%208094%2C%208127%2C%208183%2C%208184%2C%208416%2C%208417%2C%208418%2C%208429%29%0A%20%20%20%20*%20ThinkCentre%20S51%20%28type%208098%2C%208171%2C%208172%2C%208173%29%0A%20%20%20%20*%20NetVista%20%28type%202273%2C%202289%2C%202292%2C%206043%2C%206343%2C%206349%2C%206350%2C%206790%2C%206791%2C%206792%2C%206793%2C%206794%2C%206795%2C%206823%2C%206824%2C%206825%2C%206826%2C%208181%2C%208182%2C%208301%2C%208303%2C%208304%2C%208305%2C%208306%2C%208307%2C%208308%2C%208309%2C%208310%2C%208311%2C%208312%2C%208313%2C%208314%2C%208315%2C%208317%2C%208318%2C%208319%29%0A%0A%0ASolution%0AUpdate%20the%20Rescue%20and%20Recovery%20software%20for%20Windows%202000%2FXP%20to%20version%203.1%20or%20later.%0A


--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Why does exiting bash window kill off Gvim? (Windows version, but X-would be same question)

[Roger K. Wells]

Linda Walsh wrote:
In bash I start a copy of gvim.exe (64-bit windows version) in 
background.
I disown the job in bash so bash no longer manages the job -- it 
should be

a free and clear process (unaffected by bash exiting).

Yet when I exit the bash window (bash running in a console window), Gvim
is killed.  Why should bash or the console exiting kill off any processes
running in the background?

I have had the same frustration for a while.  When in a bash shell start 
gvim with:

cmd /c gvim
then you can exit the bash shell without killing gvim.
FWIW:
I am using gvim v7.0 for 32bit MS-Windows
it is set up as a server by sourcing the following in .bash_profile:

function gvim
{
   if [ -z $1 ] ; then
   $VIMRUNTIME/gvim.exe --servername GVIM 
   else
   $VIMRUNTIME/gvim.exe --servername GVIM --remote-silent $1 
   fi
}

cheera,
roger wells
It would be the same question of it was the win32-X based Gvim -- it 
would

be killed as well, but one could argue that cygwin has to shut down all
cygwin processes when it exits -- but I still don't see that as being
necessary.

It's certainly not what happens when I log into a linux workstation and
bring up Gvim displaying locally (an X version, not a Windows
version...:-)).  I can terminate the tty window to a linux box and the X
program just keeps on running (unless I was running it's display 
through a

copy of SSH that terminates with the window's exit.  I try to avoid that
on my local network.

So why does cygwin have to terminate any processes when I exit the shell
window?  If I've disowned the job, I obviously don't care about any 
output

-- I could use nohup in front of it, if I wanted to capture such, but it
wouldn't matter, they all seem to be required to die, and I don't
understand why.

I find it ironic to think about the discussion about characters when
something important like jobs running in background normally doesn't even
work right, but I don't understand why it has to be that way. 
I find it *especially* annoying, when it kills off a windows program --

there can be no good reason for that.

I guess I also don't quite get why I don't get back immediate control
when I start gvim under bash.exe, but if I start cmd.exe within bash,
then gvim behaves 'normally' (auto backgrounds and doesn't terminate
when cygwin does).  So it's obvious that there's no reason, at least,
why cygwin should go out of its way to kill off any launched
processes.  Or does it not do that? 


linda


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple





--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [BUG] fopen(..., a) does not seek to end of file until some write operation

[Roger K. Wells]

Eric Blake wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Salvador Fandino on 11/13/2009 1:36 PM:
  

Hii

Using ftell() after fopen(..., a) returns 0 even when the file open for 
appending is not empty. AFAIK, it should return the size of the file.



Not a bug.  POSIX allows this behavior, and Linux does it as well.  POSIX
also allows BSD behavior of seeking to the end, although this is less
friendly to reading back a file opened with fopen(...,a+).  So portable
programs can't expect either situation, and you MUST use fseek when
opening for append if you expect a particular position.

  

however writing will always take place at the end of the file.
Opening a file with append mode (a as the first character in the mode 
argument) shall cause all
subsequent writes to the file to be forced to the then current 
end-of-file, regardless of intervening

calls to fseek( ).
rw

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr9xGoACgkQ84KuGfSFAYC8CACgtx1ZxOtKVaGF2xk2UHg+1B7c
7cUAniO/T6EOm0gxRRx/1wsCM6P2HXXl
=xedo
-END PGP SIGNATURE-

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple


  



--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Win2k Command Window Can't Execute G++

[Roger Head]

Alexey Borzenkov snaury at gmail.com writes:

 As an alternative you can try looking into my
 http://git.kitsu.ru/mine/shell-wrapper.git (use snapshot link for
 topmost commit if you don't have git and don't know how to clone)
 

Thanks Alexey, I'll have a look.

Roger




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Win2k Command Window Can't Execute G++

[Roger Head]

Larry Hall (Cygwin reply-to-list-only-lh at cygwin.com writes:

 
 Roger Head wrote:
  Hi All,

  Cygwin installation I had to manually add \Cygwin\bin and \Cygwin\usr\bin 
to the PATH. That hasn't been altered.  

 If you want Windows applications to be able to see Cygwin apps without
 adding explicit paths to the invocation, you'll need to add 'C:\cygwin\bin'
 or equivalent to your Windows PATH environment variable.  You can do so
 using the System applet from the Control Panel.
 

Roger Head rlincolnh at yahoo.com writes:
Errr, yeah, thanks for the reply Larry, but as you see in my last para. I've 
already done that right from the start. My system is actually on L:, so my PATH 
has L:\Cygwin\bin and L:\Cygwin\usr\bin

Roger
 




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Win2k Command Window Can't Execute G++

[Roger Head]

Matt Wozniski godlygeek at gmail.com writes:

 
 Don't have a cygwin install in front of me ATM, but - isn't g++ a
 cygwin symlink these days?  cmd.exe can't follow those even if they're
 in the path, of course.
 
 ~Matt
 

Thanks for the reply, Matt. I don't have a really good idea of how Cygwin and 
Windows are both supposed to be able to handle .LNKs to e.g. G++, but a dump of 
g++.exe.lnk shows strings for /etc/alternatives and L:\cygwin\etc\alternatives. 
So yes, I don't know if Windows is supposed to be able follow that, but as I 
said in my original post, I'm almost certain that I was able to invoke it from 
a CMD window. The reason that I tried that at the time was because I was using 
a set of pages that appeared to give me good idea of how an installation should 
go - remember, I don't speak unix/linux at all - and it was illustrated there. 
The link to installing GCC that I was looking at is

http://www2.warwick.ac.uk/fac/sci/moac/currentstudents/peter_cock/cygwin/part2/

That was directed specifically to XP, but it was a good enough beginners guide 
for Win2k.

I'm sure that I can come up with a hack that will let me do what I want, but I 
wouldn't have thought it would be necessary.

Roger


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Win2k Command Window Can't Execute G++

[Roger Head]

Hi Andy,
 
  I'm almost certain that I was able to invoke it from a CMD window.
 
 Afaik, gcc and g++ changed into links only recently, to help with the
 transition from gcc-3.4 to 4.3.


There are still some remnants of AVR-GCC hanging around on my system from a few 
years ago. Maybe a connection there... ...somehow.
 
  I'm sure that I can come up with a hack that will let me do what I want
 
 The easiest thing to do would be to overwrite the link with the file
 it points to, e.g. 'cp /bin/g++-4.exe /bin/g++.exe'. You'd have to
 remember to do that after every gcc update though.
 

Yeah, I'd have to automate it. I've just about given up on writing notes to 
myself, because when the time comes that I need them, I've forgotten that I 
ever wrote them in the first place! The joys of advancing years...

Roger
 





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Win2k Command Window Can't Execute G++

[Roger Head]

Dave Korn dave.korn.cygwin at googlemail.com writes:

   How about just typing g++-4 (or g++-3) instead of g++ when trying to
 invoke the compiler from a DOS shell?
 
 cheers,
   DaveK
 
 
U... e no, no, that's too easy. There must be a harder way to do it.

Thanks Dave.

Roger




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Win2k Command Window Can't Execute G++

[Roger Head]

Hi All,

I'm a noob to Cygwin and all things non-Windows. I installed Cygwin on my Win2k 
system (a couple of hiccups, but nothing major), then installed the GCC. When 
that completed, I did g++ -v in a bash window, and got the expected response. I 
am *sure* (99% anyway) that I was also able to do it in a normal CMD window amd 
get the identical response. I then proceeded to install X-Windows with no 
problems, and it appears to work (i.e. can bring up calc, etc). However, if I 
now try to invoke g++ from a CMD window I get the usual message '... not 
recognized as an internal or external command ...blah blah blah'. It still 
works in a bash window.

Am I dreaming that I was able to use it in a CMD window before installing X 
Windows, or has something been changed during that installation? If so, what?

I have done all the above while logged on as Administrator. After the initial 
Cygwin installation I had to manually add \Cygwin\bin and \Cygwin\usr\bin to 
the PATH. That hasn't been altered. It doesn't matter what directory I am in 
when using the CMD window, g++ isn't recognized.

I would sure appreciate some help.

Roger



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Roger Wells]

Charles Wilson wrote:

Pursuant to a discussion on the libtool list, I'm trying to get a feel
for how many cygwin users rely on the cygwin environment to drive the
*native* MinGW gcc compiler.  That is, incantations like this:

1a)
cygwin$ some-src-pkg/configure \
  --build=i686-pc-cygwin --host=mingw32 \
  CC=/c/MinGW/bin/gcc.exe \
  CXX=/c/MinGW/bin/g++.exe \
  NM=/c/MinGW/bin/nm.exe \
  DLLTOOL=/c/MinGW/bin/dlltool.exe \
  OBJDUMP=/c/MinGW/bin/objdump.exe \
  LD=/c/MinGW/bin/ld.exe

or possibly

1b)
cygwin$ export PATH=/c/MinGW/bin:$PATH
cygwin$ some-src-pkg/configure \
  --build=i686-pc-cygwin --host=mingw32

Note that this is *DIFFERENT* than installing a true cygwin-hosted
mingw-target cross-compiler, and just doing

2)
cygwin$ some-src-pkg/configure \
  --build=i686-pc-cygwin --host=i686-pc-mingw32

It is ALSO different than the (deprecated, unsupported,
go-away-don't-bother-us) incantation:

3)
cygwin$ some-src-pkg/configure \
  --build=i686-pc-cygwin --host=i686-pc-mingw32 \
  CFLAGS='-mno-cygwin'

I hope this is considered on-topic here, because I'm interested in the
uses of the cygwin environment itself.  I don't want reports of why it
doesn't work, or how hard it is to get one of the incantations above to
work.  I just want to get an idea of how many people are currently,
actually, successfully, doing something like 1a) or 1b) above.

  
Our development group uses native MinGW every day with the Cygwin bash 
shell as the center of operations.  
I believe that we are over ten years into this at this point
Our build environment uses Serena Configuration Builder and PVCS, but I 
can feel a more standard unixish (autoconf,
automake, etc) environment coming in as well.  I also use Cygwin to 
develop using Embedded C++, Visual C++ by starting bash
via a windows batch file that sets the BASHENV environment variable 
to  another script, eg .mingwrc, that  sets the build environment
specifically ensuring in this case that MinGW's gcc, etc is ahead of 
Cygwin's in the PATH.

--
Chuck

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


  


--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Finally managed to create a jailed SFTP server, but how secure?

[Roger Wells]

TheO wrote:

From what we've seen so far, it seems that SFTP responds as expected.
That is all that I want to know.
From this point forward, we must try to close all other access ways
that does not belong to the scenario... but those are not excuses to
not implement the SFTP chroot.




Actually, my real case is even simpler than this. My SFTP users are all friendly, 
they are not unknown to me. It is a cooperative environment and to be honest, I 
don't believe that they would harm my system by hacking into it.


But I don't want them to poke around and see the content of other directories 
which
do not concern them, read my config files, see who other users are or list the 
content
of my C: drive, ...

Yes so far the set up looks as expected. However, I would have preferred better 
if
/cygdrive was not visible too even if they can't do anything with it. Ideally 
there
should not be anything which could give them any hint on the type of my 
platform.

  
if you are concerned about the cygdrive text there is a registry entry 
where you can set that to whatever you want including . That is what I 
do. I would tell you what it is but my windows machine is not here right 
now. Then when you ls / you get /c, /d etc instead of /cygdrive/c, 
/cygdrive/d, etc.

cheers,
roger wells
I don't know who creates /cygdrive here. It is not required in this chroot'ed 
environment. My guess, it is created by sftp-server at start up (regardless whether

it runs under chroot'ed environment or not). Maybe someone can confirm this 
better than
me.



One more thing to add.

According to its RFC (4254), once a session is established, SSH allows the 
client to specify
anycommand to execute or any subsystem to be spawned on the server side.

But I think I am safe here too because;

1. I only put sftp subsystem in the sshd_config so any other subsystem request 
will fail.
2. No command can be executed since it requires /bin/bash (or another shell as 
defined by
   /etc/passwd) to be present in the jail.


  


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


  


--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
[EMAIL PROTECTED]


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/