RE: Is perl-5.8.2 canonized for use on cygwin yet?

[Rick Rankin]

--- "Blair P. Houghton" <[EMAIL PROTECTED]> wrote:
> I think I've found the problem.
> 
> By more careful use of the -d=flags option to make, I traced it down to the
> second of two "subdirs"
> targets, and then turned off the NOECHO command (by taking it out of the
> script line in the Makefile
> under the second subdirs target).
> 
> Then, making only in the .../ext/B directory (as Yitzchak suggested), I got
> this output:
> 
>   % make -f Makefile all
>   cd C && make -f Makefile all LIB="C:\Program Files\Microsoft Visual Studio
> .NET\Vc7\lib\;C:\Program Files\Microsoft.NET\FrameworkSDK\Lib\"
> LIBPERL_A="libperl"
> LINKTYPE="dynamic" PREFIX="" OPTIMIZE="-O2" PASTHRU_DEFINE="" PASTHRU_INC=""
>   Syntax error: Unterminated quoted string
>   make: *** [subdirs] Error 2
> 
> Note the LIB variable.  It's not the spaces that are glaring, it's that
> trailing backslash before
> the closing double-quote.  Leave it to Microsoft to confuse a path with a
> string that is part of the
> computation of a path (they shoulda left the last slash off; it's only there
> as step-saving cruft
> for some string catenation that would probably be better written to do the
> slash insertion itself
> anyway; lamers).
> 
> LIB comes from the calling shell environment, which is a default xterm
> running bash under XFree86.
> 
> So here's the question:
> 
> What sets LIB in the cygwin environment?  It comes verbatim from the DOS
> environment list but I
> don't see the importation in any of the layered rc files (but I could've
> missed it).  And is there a
> way to automatically make cygwin translate these paths from backslash to
> forward slash when
> importing? You'd think that would be the default.  Is there a way to suppress
> all importation or all
> but a list of explicitly named variables?  Obviously I can exclude some by
> redefining them in the
> bashrc files, but what I'd rather do is exclude all except those I want
> included, in case some
> software installs new ones.
> 

The trailing backslashes aren't necessary. I've removed them in my LIB and
INCLUDE environment variables and VC works just fine. You could try removing
them and see if that fixes the perl build.

--Rick

--
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: Question about ash and getopts

[Dario Alcocer]

Peter Seebach wrote:

I know this is a pseudo-FAQ, but I haven't been able to find a clear enough
answer in the archives.
1.  Is it not the case that POSIX provides a specification for the getopts
builtin?
2.  Doesn't ash, as originally written, implement getopts?
I'm trying to figure out why this feature was removed, and I've never gotten
an answer that made much sense.  Every other POSIX-like system I can think
of supports getopts in /bin/sh.  Why is Cygwin different?
 

Use the "set -- `getopt`" idiom instead:

   http://cygwin.com/ml/cygwin/2003-05/msg01114.html



--
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: Question about ash and getopts

[Peter Seebach]

In message <[EMAIL PROTECTED]>, Dario Alcocer writes:
>Peter Seebach wrote:
>
>>I know this is a pseudo-FAQ, but I haven't been able to find a clear enough
>>answer in the archives.
>>
>>1.  Is it not the case that POSIX provides a specification for the getopts
>>builtin?
>>2.  Doesn't ash, as originally written, implement getopts?
>>
>>I'm trying to figure out why this feature was removed, and I've never gotten
>>an answer that made much sense.  Every other POSIX-like system I can think
>>of supports getopts in /bin/sh.  Why is Cygwin different?
>>  
>>
>Use the "set -- `getopt`" idiom instead:
>
>http://cygwin.com/ml/cygwin/2003-05/msg01114.html

Yes, but *why*?  Why not use the thing that's in the POSIX shell spec,
which works everywhere else?

I have a few dozen scripts which have worked on every Unix system I've seen
since the mid-90s, and the feature appears to date back to SVR3 (1986).

I could understand not implementing it; what I can't understand is expending
extra effort to remove it.

-s

--
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: Executing Perl scripts w/o the .pl

[Shaffer, Kenneth]

If using Active Perl with cygwin, put the following as the first line of
your perl scripts:

eval 'exec perl -S `cygpath -w $0`' if 0;

--
Ken Shaffer



 - - - - - - -  Appended by Scientific-Atlanta, Inc.  - - - - - - -  
This e-mail and any attachments may contain information which is confidential, 
proprietary, privileged or otherwise protected by law. The information is solely 
intended for the named addressee (or a person responsible for delivering it to the 
addressee). If you are not the intended recipient of this message, you are not 
authorized to read, print, retain, copy or disseminate this message or any part of it. 
If you have received this e-mail in error, please notify the sender immediately by 
return e-mail and delete it from your computer.


--
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: bash.exe: *** Couldn't reserve space for cygwin's heap

[Jason Tishler]

Kimberlie,

On Tue, Dec 23, 2003 at 11:48:06AM -0500, Kimberlie S wrote:
> Thanks, Jason, for your help.

You are welcome.

> [snip]
> 
> Am I doing something wrong?

I don't think so.

> Thanks for any other suggestions you might have!

I'm sorry but I don't know how to help you further.

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

--
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: Executing Perl scripts w/o the .pl

[Igor Pechtchanski]

On Mon, 29 Dec 2003, Shaffer, Kenneth wrote:

> If using Active Perl with cygwin, put the following as the first line of
> your perl scripts:
>
> eval 'exec perl -S `cygpath -w $0`' if 0;
> --
> Ken Shaffer

...or put the following in your /usr/local/bin:

-- BEGIN /usr/local/bin/wrap --
#!/bin/sh
pname="$1"
fname="`cygpath -w "$2"`"
shift 2 && exec "$pname" "$fname" "$@"
--- END /usr/local/bin/wrap ---

and change the #! line of the perl script to

#!/usr/local/bin/wrap /cygdrive/c/ActivePerl/bin/perl

This should work even if you have Cygwin perl installed as well.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
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: ImageMagick packaging problem

[Timothy J. Luoma]

On Mon, 29 Dec 2003 04:39:50 -, <[EMAIL PROTECTED]> wrote:

This is not an answer to the problem posted, but it reminds me to ask as  
to where can a version of ImageMagick for cygwin is available for  
download ?
I have the same question, assuming you mean a binary version.

(Actually I'm just looking for the 'imgsize' binary at the moment)

TjL

--
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: Is perl-5.8.2 canonized for use on cygwin yet?

[Blair P. Houghton]

>The trailing backslashes aren't necessary. I've removed them in my LIB and
>INCLUDE environment variables and VC works just fine. You could try removing
>them and see if that fixes the perl build.

Well, you can remove them manually; but this is a computer and it should do the work.  
The next
time, VC might break if you remove them, so you couldn't remove them.  Cygwin should 
account for
this sort of behavior in Windows-installed environment strings.  It's a nontrivial 
change to the
code that execs the cygwin program from within the encompassing Windows program, 
though.

--Blair


--
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: Question about ash and getopts

[Blair P. Houghton]

Peter Seebach wrote:
>In message <[EMAIL PROTECTED]>, Dario Alcocer writes:
>>Use the "set -- `getopt`" idiom instead:
>Yes, but *why*?

==
% cygcheck --version
cygcheck version 1.30
System Checker for Cygwin
Copyright 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
Compiled on Feb  8 2003
% cat > bt.sh
#!/bin/sh

set -- `getopt`

echo $0 $2 $4
echo $1 $3 $5
^D
% bt.sh 1 2 3 4 5 6
getopt: missing optstring argument
Try `getopt --help' for more information.
./bt.sh
===

Hey.  It got $0 right.

So I take it this "idiom" is only supposed to work in newer cygwin versions?

And I too am puzzled why someone would defeature a shell instead of letting it work 
with either
method.  I don't see it as a portability issue unless you think a significant number 
of users will
be porting their scripts from systems running cygwin to systems running atavistic 
variants of UNIX.

--Blair


--
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: 'man' shows escape sequences after updating to docbook_xsl 1.64.1-1

[Thorsten Kampe]

* Lynn Wilson (2003-12-23 19:40 +0100)
> It seems that a few months ago the man pages were showing the ESC[1m etc. escape 
> sequences in a bash shell. The problem was quickly fixed.

> I downloaded docbook_xsl 1.64.1-1 yesterday and the problem is back.  I also 
> downloaded a few X-modules.  One of these modules caused the 'man' problem to 
> re-appear.

Same with me. Anyone with a solution (because every man page is 
unreadable). I haven't installed any "X modules".

Thorsten


--
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: Question about ash and getopts

[Peter Seebach]

In message <[EMAIL PROTECTED]>, "Blair P. Houghto
n" writes:
>So I take it this "idiom" is only supposed to work in newer cygwin versions?

I dunno.  It's a very, very, odd idiom, that leaves you stuck with a great
deal of manual parsing anyway.

>And I too am puzzled why someone would defeature a shell instead
>of letting it work with either method.  I don't see it as a
>portability issue unless you think a significant number of users
>will be porting their scripts from systems running cygwin to systems
>running atavistic variants of UNIX.

I did check; SunOS 4.1.3 had getopts too.  So, basically, it's portable
to everything except the 3b1 and 3b2, and possibly old versions of OSF/1.

But, most importantly, it's in POSIX.  I can see no reason for /bin/sh to not
be at least reasonably close to a POSIX shell, when the code is already
written.

The "it saves space" argument is implausible, and frankly counterproductive;
it should be obvious to the casual reader that calls to getopt are MUCH more
expensive than a shell with getopts in it, as is the other option, running
bash instead.  A shell without getopts may be marginally smaller, such that
scripts which don't use getopts are "faster"... But did anyone actually
measure this making a difference, or is this just Little Tin God optimization
at work?

-s

--
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: Question about ash and getopts

[Larry Hall]

At 02:00 PM 12/29/2003, Peter Seebach you wrote:
>In message <[EMAIL PROTECTED]>, "Blair P. Houghto
>n" writes:
>>So I take it this "idiom" is only supposed to work in newer cygwin versions?
>
>I dunno.  It's a very, very, odd idiom, that leaves you stuck with a great
>deal of manual parsing anyway.
>
>>And I too am puzzled why someone would defeature a shell instead
>>of letting it work with either method.  I don't see it as a
>>portability issue unless you think a significant number of users
>>will be porting their scripts from systems running cygwin to systems
>>running atavistic variants of UNIX.
>
>I did check; SunOS 4.1.3 had getopts too.  So, basically, it's portable
>to everything except the 3b1 and 3b2, and possibly old versions of OSF/1.
>
>But, most importantly, it's in POSIX.  I can see no reason for /bin/sh to not
>be at least reasonably close to a POSIX shell, when the code is already
>written.
>
>The "it saves space" argument is implausible, and frankly counterproductive;
>it should be obvious to the casual reader that calls to getopt are MUCH more
>expensive than a shell with getopts in it, as is the other option, running
>bash instead.  A shell without getopts may be marginally smaller, such that
>scripts which don't use getopts are "faster"... But did anyone actually
>measure this making a difference, or is this just Little Tin God optimization
>at work?


If you're curious, I suggest you run some timings on ash with and without 
getopts enabled using a few configure scripts from some of Cygwin's 
packages, large and small.  It was the slowness of configure scripts 
that prompted the streamlining of Cygwin's ash.  If you can provide 
data that suggests that there isn't a performance penalty for these
scripts with getopts on, then a patch to turn it back on may be considered.



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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: Question about ash and getopts

[Peter Seebach]

In message <[EMAIL PROTECTED]>, Larry Hall writes:
>If you're curious, I suggest you run some timings on ash with and without 
>getopts enabled using a few configure scripts from some of Cygwin's 
>packages, large and small.  It was the slowness of configure scripts 
>that prompted the streamlining of Cygwin's ash.  If you can provide 
>data that suggests that there isn't a performance penalty for these
>scripts with getopts on, then a patch to turn it back on may be considered.

Did anyone perform an actual test showing that the getopts code was making
a difference, or was it just a general desire to trim everything in sight?

-s

--
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: 'man' shows escape sequences after updating to docbook_xsl 1.64.1-1

[Larry Hall]

At 01:48 PM 12/29/2003, Thorsten Kampe you wrote:
>* Lynn Wilson (2003-12-23 19:40 +0100)
>> It seems that a few months ago the man pages were showing the ESC[1m etc. escape 
>> sequences in a bash shell. The problem was quickly fixed.
>
>> I downloaded docbook_xsl 1.64.1-1 yesterday and the problem is back.  I also 
>> downloaded a few X-modules.  One of these modules caused the 'man' problem to 
>> re-appear.
>
>Same with me. Anyone with a solution (because every man page is 
>unreadable). I haven't installed any "X modules".


Does that mean that you updated to docbook_xsl 1.64.1-1 as well or did 
you intend to imply that there were no overlaps between the packages you 
installed/updated and Lynn's?


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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: Is perl-5.8.2 canonized for use on cygwin yet?

[Igor Pechtchanski]

On Mon, 29 Dec 2003, Blair P. Houghton wrote:

> >The trailing backslashes aren't necessary. I've removed them in my LIB
> >and INCLUDE environment variables and VC works just fine. You could try
> >removing them and see if that fixes the perl build.
>
> Well, you can remove them manually; but this is a computer and it should
> do the work.  The next time, VC might break if you remove them, so you
> couldn't remove them.  Cygwin should account for this sort of behavior
> in Windows-installed environment strings.  It's a nontrivial change to
> the code that execs the cygwin program from within the encompassing
> Windows program, though.
>
> --Blair

This is not a question of removing the backslashes or unixifying paths.
There is a clash between an environment variable that MSVC needs (and
arrogantly sets in the environment) and an optional one for the perl
build.  If you had another (Cygwin) program that needed $LIB set to
something else (in your .bashrc), you wouldn't hesitate to unset it for
the perl build (once you've discovered the clash), so why the dilemma now?
Cygwin imports the environment variables from the outside (Windows)
environment intact, with two exceptions: (1) those that are needed for the
normal working of Cygwin (e.g., PATH, TMP, HOME) are unixified, and (2)
some are overridden in the default /etc/profile and ~/.bashrc.  This is
done so that Windows programs that may need those variables will still
work.  Further, the first kind of variable is converted back to Win32
format before calling Windows programs (for the exact same reason).  I
doubt that any further kind of transformation is going to be performed by
Cygwin.

If you wish, you can add some code to your ~/.bashrc (or the .rc for your
favorite shell) to eliminate trailing backslashes in all variables (and
perhaps remove quotes inside them, another common problem).  In this
particular case, I'd suggest simply unsetting LIB in your ~/.bashrc since
you're unlikely to invoke MSVC constituent programs from the Cygwin shell.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
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: Question about ash and getopts

[Larry Hall]

At 02:20 PM 12/29/2003, Peter Seebach you wrote:
>In message <[EMAIL PROTECTED]>, Larry Hall writes:
>>If you're curious, I suggest you run some timings on ash with and without 
>>getopts enabled using a few configure scripts from some of Cygwin's 
>>packages, large and small.  It was the slowness of configure scripts 
>>that prompted the streamlining of Cygwin's ash.  If you can provide 
>>data that suggests that there isn't a performance penalty for these
>>scripts with getopts on, then a patch to turn it back on may be considered.
>
>Did anyone perform an actual test showing that the getopts code was making
>a difference, or was it just a general desire to trim everything in sight?


I don't know.  It was a long time ago that this change was made.  I don't
recall the details (even if they were posted at the time).  In any case, 
since ash has been /bin/sh for many, many years now and things have clearly
changed all over Cygwin in this time, the tests run then may have different
results than those run now.  That's why I suggested you run your own tests
and report back the results if you're interested in more details.  Beyond 
that, I can only point to the (very old) email archives and say "whatever
details exist are in there somewhere".  But if it wasn't clear to you what
the reason was for making the change (although it sounds like you were), 
it should be clear now. ;-)



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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: Question about ash and getopts

[Igor Pechtchanski]

On Mon, 29 Dec 2003, Blair P. Houghton wrote:

> Peter Seebach wrote:
> >In message <[EMAIL PROTECTED]>, Dario Alcocer writes:
> >>Use the "set -- `getopt`" idiom instead:
> >Yes, but *why*?
>
> ==
> % cygcheck --version
> cygcheck version 1.30
> System Checker for Cygwin
> Copyright 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
> Compiled on Feb  8 2003

FYI, this doesn't tell us anything about the version of Cygwin or the
associated utilities.  'uname -a' does slightly better.  For the full set
of information you can report about your system, see
.

> % cat > bt.sh
> #!/bin/sh
>
> set -- `getopt`
>
> echo $0 $2 $4
> echo $1 $3 $5
> ^D
> % bt.sh 1 2 3 4 5 6
> getopt: missing optstring argument
> Try `getopt --help' for more information.
> ./bt.sh
> ===
>
> Hey.  It got $0 right.
>
> So I take it this "idiom" is only supposed to work in newer cygwin versions?

Try "getopt --help".  In a shell that does have 'getopts', you wouldn't
use the no-arg form, so why expect it to work here?  'set -- `getopt`' was
called an *idiom*, not the exact command to use.  You give 'getopt' the
same parameters you'd give to 'getopts' in bash.

> And I too am puzzled why someone would defeature a shell instead of
> letting it work with either method.  I don't see it as a portability
> issue unless you think a significant number of users will be porting
> their scripts from systems running cygwin to systems running atavistic
> variants of UNIX.
>
> --Blair

I'm sure this discussion is in the archives somewhere.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
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: Question about ash and getopts

[Peter Seebach]

In message <[EMAIL PROTECTED]>, Igor Pechtcha
nski writes:
>I'm sure this discussion is in the archives somewhere.

A first run of casual searching hasn't turned it up.

However, since I happen to have an unmunged ash source around, I removed
getopts from it.

# Without getopts
$ ls -l obj/sh
-rwxr-xr-x  1 seebs  wheel  116024 Dec 29 12:50 obj/sh
# with getopts
$ ls -l obj/sh
-rwxr-xr-x  1 seebs  wheel  116440 Dec 29 12:51 obj/sh

416 bytes?

Is this some kind of practical joke?  The one thing I saw in the archive
said that removing getopts saved 13k of space.

To remove getopts, I removed:
* getoptscmd
* The reference to getoptscmd in builtin.def
* getopts
* getoptsreset

The entirety of options.c only has about 3k of code in it at all.

416 *bytes*?

Admittedly, I did this compile on NetBSD, but the code in question is 100%
portable, and the same everywhere.  It sounds to me like someone trimmed a
lot of things, without any attention at all to how large the individual things
were.

I don't think anyone can convince me that a 416-byte difference in code, or
even twice that, is big enough to justify thumbing one's nose at POSIX.

-s

--
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: Can't build gcc [tree-ssa] 20031222 on cygwin: libmudflap/mf-hooks2.c:1618 syntax error for ipc...

[Frank Ch. Eigler]

Christian Joensson <[EMAIL PROTECTED]> writes:

> [...]
> In file included from /usr/local/src/branch/gcc/libmudflap/mf-hooks2.c:1618:
> /usr/include/sys/ipc.h:59: error: syntax error before "ushort"
> /usr/include/sys/ipc.h:61: error: syntax error before "cuid"
> /usr/include/sys/ipc.h:62: error: syntax error before "cgid"
> /usr/include/sys/ipc.h:63: error: syntax error before "mode"
> /usr/include/sys/ipc.h:64: error: syntax error before "seq"
> [...]

Would you try again, after adding a "#include " near
the top of mf-hooks2.c?  If it works, we can put in an autoconf-based
conditional permanently.


- FChE

--
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: Question about ash and getopts

[Larry Hall]

At 02:54 PM 12/29/2003, Peter Seebach you wrote:
>In message <[EMAIL PROTECTED]>, Igor Pechtcha
>nski writes:
>>I'm sure this discussion is in the archives somewhere.
>
>A first run of casual searching hasn't turned it up.
>
>However, since I happen to have an unmunged ash source around, I removed
>getopts from it.
>
># Without getopts
>$ ls -l obj/sh
>-rwxr-xr-x  1 seebs  wheel  116024 Dec 29 12:50 obj/sh
># with getopts
>$ ls -l obj/sh
>-rwxr-xr-x  1 seebs  wheel  116440 Dec 29 12:51 obj/sh
>
>416 bytes?
>
>Is this some kind of practical joke?  The one thing I saw in the archive
>said that removing getopts saved 13k of space.
>
>To remove getopts, I removed:
>* getoptscmd
>* The reference to getoptscmd in builtin.def
>* getopts
>* getoptsreset
>
>The entirety of options.c only has about 3k of code in it at all.
>
>416 *bytes*?
>
>Admittedly, I did this compile on NetBSD, but the code in question is 100%
>portable, and the same everywhere.  It sounds to me like someone trimmed a
>lot of things, without any attention at all to how large the individual things
>were.
>
>I don't think anyone can convince me that a 416-byte difference in code, or
>even twice that, is big enough to justify thumbing one's nose at POSIX.


OK, sounds to me like you've convinced yourself that ash should contain 
getopts.  Does that mean that you no longer have a need to keep this thread 
going?  I'm not sure I see the discussion providing any useful benefit beyond
you becoming more comfortable with your original position.  If I'm wrong,
please show us where you're headed.  If not and your main goal was to just 
point out that ash doesn't have getopts, then let's end the thread.  There's 
little point to covering the same ground on this topic again. 


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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: Question about ash and getopts

[Peter Seebach]

In message <[EMAIL PROTECTED]>, Larry Hall writes:
>OK, sounds to me like you've convinced yourself that ash should contain 
>getopts.  Does that mean that you no longer have a need to keep this thread 
>going?  I'm not sure I see the discussion providing any useful benefit beyond
>you becoming more comfortable with your original position.  If I'm wrong,
>please show us where you're headed.  If not and your main goal was to just 
>point out that ash doesn't have getopts, then let's end the thread.  There's 
>little point to covering the same ground on this topic again. 

The goal here is that I would like Cygwin to be the best environment it could
be, since I use it, and I sometimes want to recommend such an environment to
people, and I dislike having to say "it's very much like Unix, except that
standard POSIX shell scripts that have worked on every Unix system anywhere
since the late 80's won't run on it".

In short, I think this mistake should be recognized as just that - a mistaken
devotion to the Little Tin God - and corrected.  Then Cygwin will be one
obvious step closer to POSIX compliance, and there will no longer be periodic
repititions of the question "why doesn't my POSIX-compliant shell script
work with this /bin/sh", followed quickly by the question "why did someone
put special effort into breaking it".

This has already made its way into a book as an example of false efficiency.

-s

--
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: Is perl-5.8.2 canonized for use on cygwin yet?

[Gerrit P. Haase]

Hallo Blair,

Am Montag, 29. Dezember 2003 um 04:51 schriebst du:

> I think I've found the problem.

> By more careful use of the -d=flags option to make, I traced it
> down to the second of two "subdirs"
> targets, and then turned off the NOECHO command (by taking it out
> of the script line in the Makefile
> under the second subdirs target).

> Then, making only in the .../ext/B directory (as Yitzchak
> suggested), I got this output: 

>   % make -f Makefile all
>   cd C && make -f Makefile all LIB="C:\Program Files\Microsoft Visual Studio
> .NET\Vc7\lib\;C:\Program Files\Microsoft.NET\FrameworkSDK\Lib\" LIBPERL_A="libperl"
> LINKTYPE="dynamic" PREFIX="" OPTIMIZE="-O2" PASTHRU_DEFINE="" PASTHRU_INC=""
>   Syntax error: Unterminated quoted string
>   make: *** [subdirs] Error 2

> Note the LIB variable.  It's not the spaces that are glaring,
> it's that trailing backslash before the closing double-quote.  Leave
> it to Microsoft to confuse a path with a string that is part of the
> computation of a path (they shoulda left the last slash off; it's
> only there as step-saving cruft for some string catenation that
> would probably be better written to do the slash insertion itself 
> anyway; lamers).

> LIB comes from the calling shell environment, which is a default
> xterm running bash under XFree86.

> So here's the question:

> What sets LIB in the cygwin environment?  It comes verbatim from the
> DOS environment list but I don't see the importation in any of the
> layered rc files (but I could've missed it).  And is there a way to
> automatically make cygwin translate these paths from backslash to
> forward slash when importing? You'd think that would be the default.
>  Is there a way to suppress all importation or all but a list of
> explicitly named variables?  Obviously I can exclude some by
> redefining them in the bashrc files, but what I'd rather do is
> exclude all except those I want included, in case some software
> installs new ones.

LIB isn't used by Cywin, but it is used by Perl.  Just unset it before
the build, it is not needed.



> It occurs to me that if these environment variables are simply
> imported by the fork that spawns cygwin, that's an insecurity
> (although, as others have noted, if the calling context is already
> insecure, cygwin is hardly the place to expect an extra layer of
> armor). 

All Windows environment settings are visible to system processes,
Cygwin just overwrites the ones it uses, LIB isn't used, so overwrite
it yourself, e.g. in cygwin.bat or in your .bashrc or whatever shell
you're using.


Gerrit
-- 
=^..^=



--
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: Question about ash and getopts

[Larry Hall]

At 03:19 PM 12/29/2003, Peter Seebach you wrote:
>In message <[EMAIL PROTECTED]>, Larry Hall writes:
>>OK, sounds to me like you've convinced yourself that ash should contain 
>>getopts.  Does that mean that you no longer have a need to keep this thread 
>>going?  I'm not sure I see the discussion providing any useful benefit beyond
>>you becoming more comfortable with your original position.  If I'm wrong,
>>please show us where you're headed.  If not and your main goal was to just 
>>point out that ash doesn't have getopts, then let's end the thread.  There's 
>>little point to covering the same ground on this topic again. 
>
>The goal here is that I would like Cygwin to be the best environment it could
>be, since I use it, and I sometimes want to recommend such an environment to
>people, and I dislike having to say "it's very much like Unix, except that
>standard POSIX shell scripts that have worked on every Unix system anywhere
>since the late 80's won't run on it".
>
>In short, I think this mistake should be recognized as just that - a mistaken
>devotion to the Little Tin God - and corrected.  Then Cygwin will be one
>obvious step closer to POSIX compliance, and there will no longer be periodic
>repititions of the question "why doesn't my POSIX-compliant shell script
>work with this /bin/sh", followed quickly by the question "why did someone
>put special effort into breaking it".
>
>This has already made its way into a book as an example of false efficiency.


I see.  So how does this thread differ from previous ones on this subject?
As far as I can see, you simply want to state your case but not contribute 
anything in return.  We've had threads like that.  If you *really* want
to see a change here, you have to put some effort into it.  That means 
looking at the issue objectively, running some tests, and if those tests
bear out, sharing them with the list along with the patch to enable the 
features you want and that your tests validate.  Of course, you can skip 
all this and just voice your opinion and be done with it.  It's your right.
It won't resolve your issue though.  Well, at least not at this point.  But
if that's the direction you want to go then it makes sense to end this 
thread, since it's just covering the same ground as the previous threads on 
this subject.



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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: Question about ash and getopts

[Peter Seebach]

In message <[EMAIL PROTECTED]>, Larry Hall writes:
>I see.  So how does this thread differ from previous ones on this subject?

Well, first off, I've done the obvious test, and verified that there is no
"13k space saving".  There might be 1/2k.

>As far as I can see, you simply want to state your case but not contribute 
>anything in return.  We've had threads like that.  If you *really* want
>to see a change here, you have to put some effort into it.  That means 
>looking at the issue objectively, running some tests, and if those tests
>bear out, sharing them with the list along with the patch to enable the 
>features you want and that your tests validate.

I can indeed run tests, but right now, no one has offered even a TINY SHRED
of actual evidence that the current broken behavior ever saved any space or
time.

The one evidential claim made in the past was that getopts was 13k of
executable size.  It isn't.

The resistence here makes no sense.  The code is already written; it is in
ash, as it has been forever.  There is no evidence showing that removing half
a kilobyte of executable code makes any measurable difference at all.

This suggests to me that no amount of testing matters; the decision here is
an ego one, not an engineering one.  The decision Was Made; therefore it is
the Cygwin Way to break /bin/sh in the name of saving space, even if the space
savings are actually 1/26th of what was claimed.

Can anyone honestly tell me that, if it turns out that enabling getopts
imposes no significant performance penalty, that this will result in fixing
the shell?  I see no reason to believe it, simply because there's never been
any evidence that getopts was causing problems in the first place.

-s

--
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/

A suggestion

[Leandro]

Cygwin.bat
__
REGEDIT4
@echo off
if "%1"=="" goto login

bash -c "$( cygpath -u "%1" )"


goto fim
:login

C:
chdir C:\cygwin\bin
bash --login -i

:fim

cygwin.reg
__
REGEDIT4

[HKEY_LOCAL_MACHINE\Software\CLASSES\.sh]
@="sh_auto_file"

[HKEY_LOCAL_MACHINE\Software\CLASSES\.ssh]
@="sh_auto_file"

[HKEY_LOCAL_MACHINE\Software\CLASSES\.tcsh]
@="sh_auto_file"

[HKEY_LOCAL_MACHINE\Software\CLASSES\.zsh]
@="sh_auto_file"

[HKEY_LOCAL_MACHINE\Software\CLASSES\.awk]
@="sh_auto_file"

[HKEY_LOCAL_MACHINE\Software\CLASSES\.sed]
@="sh_auto_file"

[HKEY_LOCAL_MACHINE\Software\CLASSES\.csh]
@="sh_auto_file"

[HKEY_LOCAL_MACHINE\Software\CLASSES\.ksh]
@="sh_auto_file"

[HKEY_LOCAL_MACHINE\Software\CLASSES\.pl]
@="sh_auto_file"


[HKEY_LOCAL_MACHINE\Software\CLASSES\sh_auto_file]
@="Shell Script"
"EditFlags"=hex:d0,04,00,00

[HKEY_LOCAL_MACHINE\Software\CLASSES\sh_auto_file\shell]
@=""

[HKEY_LOCAL_MACHINE\Software\CLASSES\sh_auto_file\shell\open]
@=""
"EditFlags"=hex:00,00,00,00

[HKEY_LOCAL_MACHINE\Software\CLASSES\sh_auto_file\shell\open\command]
@=C:\\cygwin\\cygwin.bat\" \"%1\" %*"

[HKEY_LOCAL_MACHINE\Software\CLASSES\sh_auto_file\shell\print]
@=""

[HKEY_LOCAL_MACHINE\Software\CLASSES\sh_auto_file\shell\print\command]
@="C:\\WINDOWS\\NOTEPAD.EXE /p %1"

[HKEY_LOCAL_MACHINE\Software\CLASSES\sh_auto_file\shell\edit]
@="&Editar"

[HKEY_LOCAL_MACHINE\Software\CLASSES\sh_auto_file\shell\edit\command]
@="C:\\WINDOWS\\NOTEPAD.EXE %1"


[HKEY_LOCAL_MACHINE\Software\CLASSES\sh_auto_file\shell\Convert]
"EditFlags"=hex:01,00,00,00

[HKEY_LOCAL_MACHINE\Software\CLASSES\sh_auto_file\shell\Convert\command]
@="\"C:\\cygwin\\bin\\conv.exe\" \"-A\" \"%1\""




[HKEY_LOCAL_MACHINE\Software\CLASSES\sh_auto_file\DefaultIcon]
@="C:\\cygwin\\usr\\X11R6\\bin\\run.exe,0"



--
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: Question about ash and getopts

[Robb, Sam]

> Well, first off, I've done the obvious test, and verified 
> that there is no "13k space saving".  There might be 1/2k.

There is no 13k space saving *now*.  There may well have
been with a previous set of sources and build tools.
 
> I can indeed run tests, but right now, no one has offered 
> even a TINY SHRED of actual evidence that the current broken
> behavior ever saved any space or time.

Immaterial, unless you think you somehow deserve an apology?

> The one evidential claim made in the past was that getopts
> was 13k of executable size.  It isn't.

As pointed out, all you know is that it isn't 13k *now*.
Besides, as Larry Hall has mentioned:

  "It was the slowness of configure scripts that prompted the
   streamlining of Cygwin's ash."

Larry's been around and involved in Cygwin for a good while, so
unless someone else can present some information that contradicts
his statement, I'm inclined to take his word on the matter.

> This suggests to me that no amount of testing matters; the 
> decision here is an ego one, not an engineering one.  The
> decision Was Made; therefore it is the Cygwin Way to break
> /bin/sh in the name of saving space, even if the space
> savings are actually 1/26th of what was claimed.

You *do* know what the Cygwin motto is, don't you?

WJM. PTC.

The ball is in your court.  As Larry and others have mentioned,
you need to:

  (a) Show that ash without getopt no longer results in a
  significant space savings (which you've already done)
  (b) Show that ash + getopt no longer results in configure
  script slowness (yet to be done)
  (c) Contingent on (a) and (b), submit a patch to the ash
  maintainer that re-enables getopt in ash
 
> Can anyone honestly tell me that, if it turns out that 
> enabling getopts imposes no significant performance penalty,
> that this will result in fixing the shell?

See (c), above.  I'd wager that without a patch from you,
the maintainer will have little or no reason to re-examine
the issue.

Providing a patch and data showing that there's no regression
to the slow-configure-script issue will probably significantly
increase the chance of the problem being addressed.

> I see no reason to believe it, simply because there's never been
> any evidence that getopts was causing problems in the first place.

Maybe I'm naieve; but my thought is that at some point, people
who knew what they were doing made the decision that removing
getopt support from ash as a Good Thing.

While I have come to know and respect the people who apparently
made this decision, I have no idea who you are.

You've gained some measure of credibility by bringing up the issue,
and doing some simple experimentation to prove your point.  It's a
shame that there is an increasingly shrill tone in your messages that
is swamping out your more reasoned arguments.

-Samrobb

--
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: Question about ash and getopts

[Brian Dessent]

Peter Seebach wrote:

> But, most importantly, it's in POSIX.  I can see no reason for /bin/sh to not
> be at least reasonably close to a POSIX shell, when the code is already
> written.

I was looking at the POSIX specs, and while getopts is listed as a
required utility[1], and it is listed in the table "regular built-in
utilities"[2] it is not in the table "special built-in utilities."[3] 
So, it looks like the command must be present but it does not
necessarily have to be built into the shell.

The earliest discussion of this seems to be[4] a thread from October
2000, where Chris F states the following:

> The "ash maintainer" is either me or Corinna.  FWIW, I don't plan on
> changing this.  I want ash to be small and fast when running configure
> scripts.  I've stripped ash down to support only the minimal set of
> functionality found in older versions of UNIX.  I use the /bin/sh on
> Digital UNIX 3.2 as a reference.
> 
> If you want more functionality, use bash.
> 
> FYI, getopts can also be a separate program although we don't supply it
> with cygwin, currently.

So, it looks like cgf is the one you need to convince.  Perhaps show the
running time differences of a long configure script with and without a
getopts-enabled ash.  I have no idea what the differences may be, if
any.

Brian

[1]
http://www.opengroup.org/onlinepubs/007904975/utilities/getopts.html#tag_04_62
[2]
http://www.opengroup.org/onlinepubs/007904975/utilities/xcu_chap01.html#tagtcjh_5
[3]
http://www.opengroup.org/onlinepubs/007904975/utilities/xcu_chap02.html#tag_02_14
[4] http://sources.redhat.com/ml/cygwin/2000-10/threads.html#00337

--
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: Question about ash and getopts

[Peter Seebach]

In message <[EMAIL PROTECTED]>, "Robb
, Sam" writes:
>> Well, first off, I've done the obvious test, and verified 
>> that there is no "13k space saving".  There might be 1/2k.

>There is no 13k space saving *now*.  There may well have
>been with a previous set of sources and build tools.

I don't think there's any way that the getopts code in and of itself could
ever have been 13k.

>> I can indeed run tests, but right now, no one has offered 
>> even a TINY SHRED of actual evidence that the current broken
>> behavior ever saved any space or time.

>Immaterial, unless you think you somehow deserve an apology?

It's material to the question of whether or not we need any evidence to
justify complying with POSIX.

>  "It was the slowness of configure scripts that prompted the
>   streamlining of Cygwin's ash."

>Larry's been around and involved in Cygwin for a good while, so
>unless someone else can present some information that contradicts
>his statement, I'm inclined to take his word on the matter.

What's missing here is any evidence that removing getopts had any measurable
effect on performance.  A 13k space saving might.

>  (a) Show that ash without getopt no longer results in a
>  significant space savings (which you've already done)

Okay.

>  (b) Show that ash + getopt no longer results in configure
>  script slowness (yet to be done)

But no one has ever shown that it *did* result in configure script slowness.

The best available theory is that 13k represents a number of modifications,
some of which had measurable effects.

>  (c) Contingent on (a) and (b), submit a patch to the ash
>  maintainer that re-enables getopt in ash

I assume you mean the person maintaining cygwin's port of ash?

>Providing a patch and data showing that there's no regression
>to the slow-configure-script issue will probably significantly
>increase the chance of the problem being addressed.

Fair enough.  That said, the patch is probably already there.

>Maybe I'm naieve; but my thought is that at some point, people
>who knew what they were doing made the decision that removing
>getopt support from ash as a Good Thing.

It's entirely possible.  On the other hand, we have no data showing any
connection between getopts support and performance.

>While I have come to know and respect the people who apparently
>made this decision, I have no idea who you are.

I'm mostly a C programmer.

>You've gained some measure of credibility by bringing up the issue,
>and doing some simple experimentation to prove your point.  It's a
>shame that there is an increasingly shrill tone in your messages that
>is swamping out your more reasoned arguments.

Well, the second aspect of my hobbies that's figuring into this is that
I'm involved in standardization efforts, and I really, really, dislike
seeing a standard abrogated without solid reasons.

Anyway, I'll see about doing some testing.  If anyone could point me at
notes on the original streamlining work, and what changes were made, I'd be
very interested.  My experience leads me to believe that it is essentially
unreasonable to imagine that removing a single small shell builtin would have
a measurable performance impact; I'd be much more open to the idea that
removing a handful of things all at once would have such an impact.

-s

--
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: Question about ash and getopts

[Peter Seebach]

In message <[EMAIL PROTECTED]>, Brian Dessent writes:
>Peter Seebach wrote:
>> But, most importantly, it's in POSIX.  I can see no reason for /bin/sh to not
>> be at least reasonably close to a POSIX shell, when the code is already
>> written.

>I was looking at the POSIX specs, and while getopts is listed as a
>required utility[1], and it is listed in the table "regular built-in
>utilities"[2] it is not in the table "special built-in utilities."[3] 
>So, it looks like the command must be present but it does not
>necessarily have to be built into the shell.

Except that I don't think it can be implemented externally, because there's
no obvious way for it to set $OPTIND.

>> The "ash maintainer" is either me or Corinna.  FWIW, I don't plan on
>> changing this.  I want ash to be small and fast when running configure
>> scripts.  I've stripped ash down to support only the minimal set of
>> functionality found in older versions of UNIX.  I use the /bin/sh on
>> Digital UNIX 3.2 as a reference.

>> If you want more functionality, use bash.

>> FYI, getopts can also be a separate program although we don't supply it
>> with cygwin, currently.

That's the one I remember.  The problem is that configure scripts, however
common, are not the only kind of shell scripts out there, and getopts is a
very, very, important utility to have access to when writing portable scripts.

It's certainly very unfriendly to programmers, who may well want to write
portable scripts.  Having exactly one target where /bin/sh doesn't have
getopts is pretty awful.  "use bash" doesn't work portably - not everyone
ships with a /bin/bash, either.  :)

>So, it looks like cgf is the one you need to convince.  Perhaps show the
>running time differences of a long configure script with and without a
>getopts-enabled ash.  I have no idea what the differences may be, if
>any.

Intuition suggests there wouldn't be any measurable difference; there's no
mechanism for an unused feature to affect performance unless it's very
large.

-s

--
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: 'man' shows escape sequences after updating to docbook_xsl 1.64.1-1

[Thorsten Kampe]

* Larry Hall (2003-12-29 20:18 +0100)
> At 01:48 PM 12/29/2003, Thorsten Kampe you wrote:
>>* Lynn Wilson (2003-12-23 19:40 +0100)
>>> It seems that a few months ago the man pages were showing the ESC[1m etc. escape 
>>> sequences in a bash shell. The problem was quickly fixed.
>>
>>> I downloaded docbook_xsl 1.64.1-1 yesterday and the problem is back.  I also 
>>> downloaded a few X-modules.  One of these modules caused the 'man' problem to 
>>> re-appear.
>>
>> Same with me. Anyone with a solution (because every man page is 
>> unreadable). I haven't installed any "X modules".

> Does that mean that you updated to docbook_xsl 1.64.1-1 as well or did 
> you intend to imply that there were no overlaps between the packages you 
> installed/updated and Lynn's?

The latter: no doc*, no X*. All packages are on their latest releases.

Thorsten


--
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: Question about ash and getopts

[Larry Hall]

At 03:48 PM 12/29/2003, Peter Seebach you wrote:
>In message <[EMAIL PROTECTED]>, Larry Hall writes:
>>I see.  So how does this thread differ from previous ones on this subject?
>
>Well, first off, I've done the obvious test, and verified that there is no
>"13k space saving".  There might be 1/2k.


Perhaps.  By your own admission, you used different source though so the 
results of the space savings are inconclusive, or more precisely, 
incompatible given the historical base.  But I can't and won't argue you 
did not make an effort to investigate the "space saving" claim.  However, you 
need to be methodical and complete to make your efforts worthwhile.  If
you can compare ash using the current sources with and without the features
you want and prove there is no performance hit, then I'd say you have 
something very worthwhile.  If not, at least we have some good data to
point to, which it seems is part of your concern now.  This would be a 
productive effort, no matter what the outcome, which is why I suggested it.
But that doesn't mean you have to follow through obviously.
 

>>As far as I can see, you simply want to state your case but not contribute 
>>anything in return.  We've had threads like that.  If you *really* want
>>to see a change here, you have to put some effort into it.  That means 
>>looking at the issue objectively, running some tests, and if those tests
>>bear out, sharing them with the list along with the patch to enable the 
>>features you want and that your tests validate.
>
>I can indeed run tests, but right now, no one has offered even a TINY SHRED
>of actual evidence that the current broken behavior ever saved any space or
>time.
>
>The one evidential claim made in the past was that getopts was 13k of
>executable size.  It isn't.
>
>The resistence here makes no sense.  The code is already written; it is in
>ash, as it has been forever.  There is no evidence showing that removing half
>a kilobyte of executable code makes any measurable difference at all.
>
>This suggests to me that no amount of testing matters; the decision here is
>an ego one, not an engineering one.  The decision Was Made; therefore it is
>the Cygwin Way to break /bin/sh in the name of saving space, even if the space
>savings are actually 1/26th of what was claimed.
>
>Can anyone honestly tell me that, if it turns out that enabling getopts
>imposes no significant performance penalty, that this will result in fixing
>the shell?  I see no reason to believe it, simply because there's never been
>any evidence that getopts was causing problems in the first place.


I can't make any promises.  I'm not the ash maintainer and I won't speak
for her.  I can say that I've found this list to be very open to sound
results and good patches.  But the mantra is, PTC (patches thoughtfully
considered), which means any patch submitted is not automatically 
accepted.  In your case, the bar is raised rather high.  Performance of
configure scripts was abysmal when /bin/sh == /bin/bash.  That prompted 
the change to /bin/sh as ash.  A trimmed version of ash was introduced 
to save more time.  The difference was noticeable.  But, like I said,
this was a long time ago (/bin/sh as ash was introduced in B20 if I 
remember correctly).  So things may be different now.  And, they may not.
But the overwhelming consensus at the time was that this was all a change
for the better.  I don't think there will be much enthusiasm for a change
that slows down configures (thus another reason for the suggestion I made
about testing this with your getopts-enabled ash).  So, if you want to 
get this feature back into Cygwin's ash, you definitely will need to show
that it can be done without a performance penalty.

I think I've been pretty clear on this subject.  Unless you have a 
specific question that I haven't already answered, I don't plan to 
respond to further posts in this thread.  IMO, this has been discussed
more than sufficiently and further discussion is getting more and more 
off-topic.  For those interested in pushing for change in this area,
it's time to do.


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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: Question about ash and getopts

[Peter Seebach]

In message <[EMAIL PROTECTED]>, Larry Hall writes:
>Perhaps.  By your own admission, you used different source though so the 
>results of the space savings are inconclusive, or more precisely, 
>incompatible given the historical base.

I can't imagine that "the ash source" varies that widely.

>But I can't and won't argue you 
>did not make an effort to investigate the "space saving" claim.  However, you 
>need to be methodical and complete to make your efforts worthwhile.  If
>you can compare ash using the current sources with and without the features
>you want and prove there is no performance hit, then I'd say you have 
>something very worthwhile.  If not, at least we have some good data to
>point to, which it seems is part of your concern now.  This would be a 
>productive effort, no matter what the outcome, which is why I suggested it.
>But that doesn't mean you have to follow through obviously.

That's a good point.  I'm in the process of running Cygwin setup on my Windows
box to make sure I'm current.

>accepted.  In your case, the bar is raised rather high.  Performance of
>configure scripts was abysmal when /bin/sh == /bin/bash.  That prompted 
>the change to /bin/sh as ash.  A trimmed version of ash was introduced 
>to save more time.  The difference was noticeable.

Does anyone have the details of the results, and what trimming was involved?
There are a lot of tweakables in ash that would affect performance a
lot more than "removing getopts".

>for the better.  I don't think there will be much enthusiasm for a change
>that slows down configures (thus another reason for the suggestion I made
>about testing this with your getopts-enabled ash).  So, if you want to 
>get this feature back into Cygwin's ash, you definitely will need to show
>that it can be done without a performance penalty.

Understood.  My own inclination would be to accept a *small* performance
penalty to have a crucial shell programming feature in the shell, simply for
portability's sake.

>I think I've been pretty clear on this subject.  Unless you have a 
>specific question that I haven't already answered, I don't plan to 
>respond to further posts in this thread.  IMO, this has been discussed
>more than sufficiently and further discussion is getting more and more 
>off-topic.  For those interested in pushing for change in this area,
>it's time to do.

Fair enough.

I remain interested in any specific analysis of the effect of getopts on shell
performance at any time; so far as I can tell, that was one big streamlining
effort, and there was no per-part analysis.

-s

--
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: Question about ash and getopts

[Peter Seebach]

Okay, some real data.

This is done using ash as of 20031007.  The only change made is this:

*** builtins.def.orig   Mon Dec 29 17:23:28 2003
--- builtins.defMon Dec 29 17:23:33 2003
***
*** 66,72 
  falsecmd  false
  histcmd -hfc
  fgcmd -j  fg
! getoptscmd -j getopts
  hashcmd   hash
  jobidcmd -j   jobid
  jobscmd   -j  jobs
--- 66,72 
  falsecmd  false
  histcmd -hfc
  fgcmd -j  fg
! getoptscmdgetopts
  hashcmd   hash
  jobidcmd -j   jobid
  jobscmd   -j  jobs

With that source, the shells are:
-rwxr-xr-x  1 seebs  wheel  91364 Dec 29 17:25 /tmp/sh.g
-rwxr-xr-x  1 seebs  wheel  91364 Dec 29 17:25 /tmp/sh.nog

I am unable to measure any performance difference between them.  Running
a sample configure script produces times between 10.35 and 10.44 seconds,
showing no apparent preference.  If you want pages and pages of 'time' output,
I could provide them, but the marginal benefit seems to be roughly nil.  If
there is a difference between the shells, it is smaller than the random
noise.  The variance between runs of the same configure script using the
same shell is one or two seconds of wall clock time; the variance between
the two shells, if there is one at all, is probably under a hundredth of a
second.

>From carefully comparing these two shells to the NetBSD /bin/sh they appear
to be related to (judging by the _RCSID strings in several of the files),
it looks very much as though the "13k" size number corresponds to the
overall removal of job control and related features from the shell.  In
fact, the difference on my system (which has a somewhat more "bloated"
/bin/sh) is a whole 16k.  The decision to mark getopts as "a job control
feature" (that's what -j means) appears to have no effect on either the
size, or teh performance, of the shell.

The decision to strip out job control features strikes me as a fairly
well-supported one; /bin/sh is a scripting shell, and it is understandable
if it doesn't have all the interactive bells and whistles.  Removing the
history commands is likewise reasonable.

However, getopts was never an interactive feature, a job control feature, or
a history feature.  It is a scripting feature, and the goal of /bin/sh is to
provide a standardized, portable, scripting environment.

There's the patch.  It's all of one line.  This has been a recurring issue
on this list as far back as 1999, when it was first pointed out that removing
that "-j" from the builtins file would "fix" the shell.  In all that time,
the only argument for disabling getopts has been "the shell is smaller and
faster as a result of these changes", but the changes in question appear to be
the removal of all job control and history features, not just getopts.

Can we just kill this now?  Take out the "-j", leave the support for getopts
in the shell, and all the shell scripters will be happy.  The configure
scripts will run at exactly the same speed, and I will happily join in
defending the decision to trim the job control and history features from the
shell to make a minimalist shell designed for scripting, leaving people the
option of using bash or pdksh if they want an interactive shell.

-s

--
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: Question about ash and getopts

[Peter Seebach]

In message <[EMAIL PROTECTED]>, Peter Seebach writ
es:
>Can we just kill this now?  Take out the "-j", leave the support for getopts
>in the shell, and all the shell scripters will be happy.  The configure
>scripts will run at exactly the same speed, and I will happily join in
>defending the decision to trim the job control and history features from the
>shell to make a minimalist shell designed for scripting, leaving people the
>option of using bash or pdksh if they want an interactive shell.

I may be forced to retract this.

Out of idle curiousity, I did timing comparisons between the stripped-down
shell and the "bloated" /bin/sh on NetBSD.

The bloated shell wins, by about 15%.  I don't know why, but I suspect it
has to do with configure using something which is a builtin in the bigger
shell, and an external command in the smaller one.

I find this ironic.

-s

--
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: Question about ash and getopts

[Larry Hall]

At 06:46 PM 12/29/2003, Peter Seebach you wrote:
>In message <[EMAIL PROTECTED]>, Peter Seebach writ
>es:
>>Can we just kill this now?  Take out the "-j", leave the support for getopts
>>in the shell, and all the shell scripters will be happy.  The configure
>>scripts will run at exactly the same speed, and I will happily join in
>>defending the decision to trim the job control and history features from the
>>shell to make a minimalist shell designed for scripting, leaving people the
>>option of using bash or pdksh if they want an interactive shell.
>
>I may be forced to retract this.
>
>Out of idle curiousity, I did timing comparisons between the stripped-down
>shell and the "bloated" /bin/sh on NetBSD.
>
>The bloated shell wins, by about 15%.  I don't know why, but I suspect it
>has to do with configure using something which is a builtin in the bigger
>shell, and an external command in the smaller one.
>
>I find this ironic.


Indeed.  That it would be.  Of course, like I said, lot's of things have
changed so the results today don't necessarily conflict with the findings
of yesteryear. 

Would you be willing to take this a step further and provide some 
configuration timings for some of the existing Cygwin packages?  Of
particular interest would be the larger packages, like binutils, gcc, and
gdb.  If these have favorable results, I think it could spark some 
interest.


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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/

[1.5.5] sshd error on local machine. [the return of sshd nightmare]

[dominix]

I've tryed this advice from Corinna:

> - Deinstall the sshd service: cygrunsrv -R sshd
> - Edit /etc/passwd and remove the sshd account entry.
> - Remove the sshd account: net user sshd /delete
> - If you didn't change much in your /etc/ssh_config and /etc/ssdh_config
>   files, remove them.
> - Run ssh-host-config again.
> - Run ssh-user-config for your own (and each other used) account.
> - Restart the sshd service.
>
> Corinna

I don't understand what's wrong, I've read nearly *all* threads about ssh in
the ML
, I've reinstalled ssh packages many times taking care of perms... using
priv sep.

Note:this machine has special interface binding that I suspect to be
responsible of troubles cause I've installed the same software on others
machines that works *very* well.

#-#
ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : pastis
Primary Dns Suffix  . . . . . . . : adn.dyndns.info
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : Yes
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : adn.dyndns.info
dyndns.info

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : D-Link DL10050-based Ethernet
Adapter (Generic)
Physical Address. . . . . . . . . : 00-05-5D-07-7B-70
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.1.91
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 192.168.0.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : 202.3.225.10
202.3.225.20

PPP adapter Olitec USB ADSL:

Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
Physical Address. . . . . . . . . : 00-53-45-00-00-00
Dhcp Enabled. . . . . . . . . . . : No
#-#
NB: windows XP Internet firewall=on but not log at all regarding local
traffic


I'm unable to use sshd -d as I was used to on unix system
cause I got error
# sshd -d
debug1: sshd version OpenSSH_3.7.1p2
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
/var/empty must be owned by root and not group or world-writable.

root ?? who's that ??

# ls -lad /var/empty /var/log/sshd.log
drwxr-xr-x+   2 SYSTEM   Administ0 Jul  5 22:31 /var/empty
-rw-rw-r--+   1 SYSTEM   Administ0 Nov  8 17:16 /var/log/sshd.log

no feedback in sshd.log ?

now trying to login, I just get this from both localhost or another machine
on localnetwork
#-#
# ssh -v -v pastis
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to pastis [192.168.0.1] port 22.
debug1: Connection established.
debug1: identity file /cygdrive/c/DOCUME~1/dominix/.ssh/identity type -1
debug1: identity file /cygdrive/c/DOCUME~1/dominix/.ssh/id_rsa type -1
debug2: key_type_from_name: unknown key type '-BEGIN'
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug2: key_type_from_name: unknown key type '-END'
debug1: identity file /cygdrive/c/DOCUME~1/dominix/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.7.1p2
debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r
[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r
[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hm
ac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hm
ac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1

Re: Question about ash and getopts

[Peter Seebach]

In message <[EMAIL PROTECTED]>, Larry Hall writes:
>Indeed.  That it would be.  Of course, like I said, lot's of things have
>changed so the results today don't necessarily conflict with the findings
>of yesteryear. 

It's possible.  My guess is that the big improvement was nuking the history
and job control stuff, both of which probably imply some overhead.

>Would you be willing to take this a step further and provide some 
>configuration timings for some of the existing Cygwin packages?  Of
>particular interest would be the larger packages, like binutils, gcc, and
>gdb.  If these have favorable results, I think it could spark some 
>interest.

That'll take a while.  My first attempt to reinstall cygwin failed in
a dramatic way, so I won't have it installed for some time.

If I get time (and I may actually have to go back to my "real" work shortly),
I will try to run a test using the bells-and-whistles /bin/sh used on
NetBSD.  I haven't tracked it down, but my guess is that some frequently
used configure commands may be builtins in that shell, which would EASILY
swamp any marginal benefit from having the shell be a bit smaller.

-s

--
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: [1.5.5] sshd error on local machine. [the return of sshd nightmare]

[Larry Hall]

You're not starting sshd as a service.  You're not going to have allot of 
luck starting it from the command line.  If you're looking for debug output,
you need to install sshd under a different name (than "sshd") and pass it
the "-d" flag.  See the "cygrunsrv -I" command in /bin/ssh-host-config for 
information on how sshd has been installed for you as a service.  Copy it
with changes for the service name (sshd) and passing it the debug flag "-d".

FYI, SYSTEM ~= root.

HTH,

Larry

At 07:22 PM 12/29/2003, dominix you wrote:
>I've tryed this advice from Corinna:
>
>> - Deinstall the sshd service: cygrunsrv -R sshd
>> - Edit /etc/passwd and remove the sshd account entry.
>> - Remove the sshd account: net user sshd /delete
>> - If you didn't change much in your /etc/ssh_config and /etc/ssdh_config
>>   files, remove them.
>> - Run ssh-host-config again.
>> - Run ssh-user-config for your own (and each other used) account.
>> - Restart the sshd service.
>>
>> Corinna
>
>I don't understand what's wrong, I've read nearly *all* threads about ssh in
>the ML
>, I've reinstalled ssh packages many times taking care of perms... using
>priv sep.
>
>Note:this machine has special interface binding that I suspect to be
>responsible of troubles cause I've installed the same software on others
>machines that works *very* well.
>
>#-#
>ipconfig /all
>
>Windows IP Configuration
>
>Host Name . . . . . . . . . . . . : pastis
>Primary Dns Suffix  . . . . . . . : adn.dyndns.info
>Node Type . . . . . . . . . . . . : Unknown
>IP Routing Enabled. . . . . . . . : Yes
>WINS Proxy Enabled. . . . . . . . : No
>DNS Suffix Search List. . . . . . : adn.dyndns.info
>dyndns.info
>
>Ethernet adapter Local Area Connection:
>
>Connection-specific DNS Suffix  . :
>Description . . . . . . . . . . . : D-Link DL10050-based Ethernet
>Adapter (Generic)
>Physical Address. . . . . . . . . : 00-05-5D-07-7B-70
>Dhcp Enabled. . . . . . . . . . . : No
>IP Address. . . . . . . . . . . . : 192.168.1.91
>Subnet Mask . . . . . . . . . . . : 255.255.255.0
>IP Address. . . . . . . . . . . . : 192.168.0.1
>Subnet Mask . . . . . . . . . . . : 255.255.255.0
>Default Gateway . . . . . . . . . :
>DNS Servers . . . . . . . . . . . : 202.3.225.10
>202.3.225.20
>
>PPP adapter Olitec USB ADSL:
>
>Connection-specific DNS Suffix  . :
>Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
>Physical Address. . . . . . . . . : 00-53-45-00-00-00
>Dhcp Enabled. . . . . . . . . . . : No
>#-#
>NB: windows XP Internet firewall=on but not log at all regarding local
>traffic
>
>
>I'm unable to use sshd -d as I was used to on unix system
>cause I got error
># sshd -d
>debug1: sshd version OpenSSH_3.7.1p2
>debug1: read PEM private key done: type RSA
>debug1: private host key: #0 type 1 RSA
>debug1: read PEM private key done: type DSA
>debug1: private host key: #1 type 2 DSA
>/var/empty must be owned by root and not group or world-writable.
>
>root ?? who's that ??
>
># ls -lad /var/empty /var/log/sshd.log
>drwxr-xr-x+   2 SYSTEM   Administ0 Jul  5 22:31 /var/empty
>-rw-rw-r--+   1 SYSTEM   Administ0 Nov  8 17:16 /var/log/sshd.log
>
>no feedback in sshd.log ?
>
>now trying to login, I just get this from both localhost or another machine
>on localnetwork
>#-#
># ssh -v -v pastis
>OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
>debug1: Reading configuration data /etc/ssh_config
>debug2: ssh_connect: needpriv 0
>debug1: Connecting to pastis [192.168.0.1] port 22.
>debug1: Connection established.
>debug1: identity file /cygdrive/c/DOCUME~1/dominix/.ssh/identity type -1
>debug1: identity file /cygdrive/c/DOCUME~1/dominix/.ssh/id_rsa type -1
>debug2: key_type_from_name: unknown key type '-BEGIN'
>debug2: key_type_from_name: unknown key type 'Proc-Type:'
>debug2: key_type_from_name: unknown key type 'DEK-Info:'
>debug2: key_type_from_name: unknown key type '-END'
>debug1: identity file /cygdrive/c/DOCUME~1/dominix/.ssh/id_dsa type 2
>debug1: Remote protocol version 2.0, remote software version OpenSSH_3.7.1p2
>debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*
>debug1: Enabling compatibility mode for protocol 2.0
>debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2
>debug1: SSH2_MSG_KEXINIT sent
>debug1: SSH2_MSG_KEXINIT received
>debug2: kex_parse_kexinit:
>diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
>debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
>debug2: kex_parse_kexinit:
>aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r
>[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr
>debug2: kex_parse_kex

Re: Info.gz files

[Christopher Faylor]

On Sun, Dec 28, 2003 at 10:49:55AM +0100, Gerrit P. Haase wrote:
>Hallo David,
>
>Am Montag, 22. Dezember 2003 um 01:08 schriebst du:
>
>> I notice that some of the larger info files, notably gcc & related files 
>> plus the Cygwin-ug files, are in /usr/share/info as xxx.info.gz files.
>
>> Is info (supposed to be) able to handle these directly?  If so, is 
>> special action appropriate to get them listed in the dir file -- on my 
>> system they are simply not being seen.
>> Of course, I can unzip them - but why use up the space if info can do it 
>> dynamically.
>
>I thought that info is able to handle this directly, therefore I
>provide the info pages compressed.  If the info files are not seen,
>then the script /etc/postinstall/update-info-dir.sh needs to be
>updated. 

The update-info-dir.sh script should have no problems with compressed files,
assuming that install-info has no problems.

cgf

--
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: Info.gz files

[Christopher Faylor]

On Mon, Dec 29, 2003 at 11:50:52AM -0500, Christopher Faylor wrote:
>On Sun, Dec 28, 2003 at 10:49:55AM +0100, Gerrit P. Haase wrote:
>>Hallo David,
>>
>>Am Montag, 22. Dezember 2003 um 01:08 schriebst du:
>>
>>> I notice that some of the larger info files, notably gcc & related files 
>>> plus the Cygwin-ug files, are in /usr/share/info as xxx.info.gz files.
>>
>>> Is info (supposed to be) able to handle these directly?  If so, is 
>>> special action appropriate to get them listed in the dir file -- on my 
>>> system they are simply not being seen.
>>> Of course, I can unzip them - but why use up the space if info can do it 
>>> dynamically.
>>
>>I thought that info is able to handle this directly, therefore I
>>provide the info pages compressed.  If the info files are not seen,
>>then the script /etc/postinstall/update-info-dir.sh needs to be
>>updated. 
>
>The update-info-dir.sh script should have no problems with compressed files,
>assuming that install-info has no problems.

...and install-info, unsurprisingly, has no problems with .gz files.

cgf

--
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: Apache 2.0.48 installation

[Stipe Tolj]

"Gerrit P. Haase" wrote:
> 
> The Makefiles need to be modified, look for the install targets, they
> do things like: `cp httpd /target/path/httpd' which doesn't work
> without patched versions of the fileutils.  Change the Makefiles to
> include the suffixes (`cp httpd.exe /target/path/httpd.exe').

yep, Gerrit is right here. 

This is an "old burden" in the Apache distros. Actually I couldn't
convince the ASF to modify the install.sh script to detect if
executables are .exe extendable. But that's an long story.

I'll check this while I'm on the way to package the Apache2 series for
net distro.

Stipe

mailto:[EMAIL PROTECTED]
---
Wapme Systems AG

Münsterstr. 248
40470 Düsseldorf, NRW, Germany

phone: +49.211.74845.0
fax: +49.211.74845.299

mailto:[EMAIL PROTECTED]
http://www.wapme-systems.de/
---

-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.2.2 (Cygwin)

mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS
OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2
nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT
dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv
bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID
AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl
OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ
K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H
g2HyLAEKQIp30Q==
=aYCI
-END PGP PUBLIC KEY BLOCK-

--
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: Question about ash and getopts

[Peter Seebach]

In message <[EMAIL PROTECTED]>, Larry Hall writes:
>Would you be willing to take this a step further and provide some 
>configuration timings for some of the existing Cygwin packages?  Of
>particular interest would be the larger packages, like binutils, gcc, and
>gdb.  If these have favorable results, I think it could spark some 
>interest.

Okay, here's timings for gcc.  This took something over an hour of wall
clock time on the machine I'm supposed to be working on, but it's data.

The shells are:

sh-nog:  /bin/sh, compiled as is; I just recompiled it to try to make sure
I had the same compiler flags.

sh-get:  /bin/sh, with the "-j" taken from the getopts line in builtins.def.
pdksh/bash:  As shipped with cygwin.

ash was built from "ash-20031007-1".

shell: ../sh-nog
real2m48.750s  2m49.258s  2m52.290s  2m47.720s
user1m51.889s  1m51.688s  1m51.788s  1m51.959s
sys 1m40.250s  1m40.541s  1m41.481s  1m41.490s
shell: ../sh-get
real2m48.437s  2m53.778s  2m47.481s  2m47.931s
user1m51.619s  1m51.469s  1m52.299s  1m51.969s
sys 1m40.490s  1m41.641s  1m41.490s  1m40.661s
shell: pdksh
real2m54.388s  2m49.546s  2m50.409s  2m54.558s
user1m52.659s  1m53.868s  1m53.279s  1m52.499s
sys 1m41.321s  1m41.971s  1m42.161s  1m43.372s
shell: bash
real2m53.370s  2m54.166s  3m1.676s   2m53.254s
user1m53.439s  1m54.409s  1m54.169s  1m53.788s
sys 1m45.572s  1m44.973s  1m46.193s  1m45.994s

I do not see here any reason to believe that there's any difference, at all,
between the two versions of ash.

Furthermore, I noticed something:  The existing ash is getting built with the
code for the getopts function compiled in, so the only effect "enabling" it
has is to add it to the list of shell builtins.  In fact:

$ strings /bin/sh.exe | grep getopt
Usage: getopts optstring var [arg]

If we're really worried about the performance of the scan through the list
of builtins when parsing commands, the obvious thing to do would be to sort
the list lexicographically and use a binary search instead of checking all
of them.  No one's ever done this, probably because there's no reason to
suspect that it would make a measurable difference.

The evidence does seem to suggest that ash may be measurably
faster than pdksh or bash, but the difference is in the area of a couple
percent.

Anyway, so far as I can tell, getopts has been in /bin/sh, just removed from
the command list, for some time.  Further prodding suggests that #ifdefing
out all of the related functions may make a measurable difference in size, but
not a particularly significant one:

-rwxr-xr-x1 SeebsNone73728 Dec 29 20:43 sh-new.exe
   textdata bss dec hex filename
  6997223003808   76080   12930 sh-new.exe

-rwxr-xr-x1 SeebsNone74752 Dec 29 20:44 sh-get.exe
   textdata bss dec hex filename
  7094823003808   77056   12d00 sh-get.exe

In short, the 976 bytes of actual code generated are likely to require one
more 1024-block of space on disk.

The cost of a single call to an external getopt should quite thoroughly
dwarf any hypothetical cost of loading that extra block from disk, especially
given that Windows, last I heard, was smart enough to cache files which were
still being used.

It is, theoretically, possible that there exists somewhere a configure script
which is substantially impacted by this.  It would need to make thousands of
calls to a shell function named "getoptz" or something similar, to maximize
the cost of string compares.  (If it were an external executable, the cost
of the string compare would be lost in the noise.)

-s

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Sun, Dec 28, 2003 at 12:26:32PM -0500, Nicholas Wourms wrote:
>Pierre A. Humblet wrote:
>>At 12:46 PM 12/27/2003 -0500, Christopher Faylor wrote:
>>
>>>I missed the 'sh -c' clue in your previous message.  Since sh uses
>>>vfork, that indicates a vfork problem.  I've checked in some more
>>>changes to deal with this.  It seems to do the right thing both with sh
>>>-c and without.  It also should have the added benefit of doing the
>>>right thing wrt deallocating the console appropriately since open_fhs
>>>should now track the ctty usecount.  This was screwed up before,
>>>apparently even before I started mucking with the tty stuff.
>>>
>>>I sure do hate usage counting.
>>>
>>>cgf
>>
>>
>>Yes, that works fine now, as does bash -c inetd.
>>
>
>Sorry to jump in on this, but I run into a few problems with the changes 
>you made last night and one issue which has been a problem for some time 
>now.
>
>This is on my Win2k box and all problems were noticed when I logged in 
>remotely via ssh (I have not tried locally).  If it makes any 
>difference, the /usr/src dir, where all my project and cygwin source is 
>contained, is a managed mount.
>
>Issues from yesterday's checkin:
>1)When run by itself from the command line, `make` is not forking 
>properly for recursive makes, instead it aborts and returns a bogus 
>HANGUP signal to the console.  This is easily seen when attempting to 
>build the Cygwin tree.  I cannot provide any useful output since it 
>appears that calling the process from within gdb or through strace 
>actually keeps make from failing to fork, but make still screws up the 
>order of entry into subdirs.

I routinely check correct cygwin operation by building cygwin so I can't
reproduce this.

>2)`procps auxf` incorrectly identifies top-parent processes as 
>, even though ps and the nt process monitor shows them to be 
>valid.  However, for postgres's postmaster, the parent and *all* 
>children are labeled as  even though I can confirm that the 
>server is up and running.

A trivial test of this, which is to run "procps auwx" from a command prompt,
does not demonstrate this here.

>3)Running configure scripts using sh.exe (which is default when you 
>./configure) always hangs, whereas running them through bash.exe works 
>fine (although it does hang from time to time).  In either case, when it 
>hangs, doing ctrl-c will drop you to the command line.  However, the 
>process isn't terminated, like one would expect.  Also, it refuses to 
>obey any signal except SIGKILL.

I don't use bash very often.  I use zsh or just the command prompt.  I
can run 'sh /whereever/configure' just fine.

>Existing issues since 1.5.5:
>3)I find myself involuntarily "logged-out" of my sessions at random 
>intervals.  This is especially prevalent when doing massive recursive 
>`rm -rf`'s or `grep -rn`'s or any other form of intensive disk i/o. 
>However, whatever is causing it seems to be getting fixed, since this 
>happens less frequently then it used to.  A small kludge I use to get 
>around this is by running links.exe then using ctrl-Z to send it to a 
>stopped state.  Then if it tries to log me out, it will fail because I 
>have a stopped process.

Again, I don't see this, so I don't know how it could be fixed.

>4)lynx crashes on startup, dropping me back to the command line. 
>Running it through gdb, the segfault happens at line 81 of cygtls.cc, 
>"_last_thread->next = this" which is inside the function 
>_threadinfo::init_thread(void*).  Unfortunately, my system is in a state 
>where I cannot get make to run correctly, so trying to build a debug 
>version of lynx at this point is not feasible.  I should note that I do 
>not see this problem inside links.

Since cygtls.c is a recent addition, this is not a 1.5.5 issue.  lynx
also works fine here.

cgf

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Sat, Dec 27, 2003 at 06:28:09PM -0500, Pierre A. Humblet wrote:
>...when I launch inetd from an rxvt window running bash, or from a Dos
>window running cygwin.bat with tty, I still see tty handles in inetd.

I fixed some more problems with both vfork and with fork recently.  The
fixes are currently in cvs.

cgf

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Mon, Dec 29, 2003 at 10:04:01PM -0500, Christopher Faylor wrote:
>On Sun, Dec 28, 2003 at 12:26:32PM -0500, Nicholas Wourms wrote:
>>Pierre A. Humblet wrote:
>>>At 12:46 PM 12/27/2003 -0500, Christopher Faylor wrote:
>>>
I missed the 'sh -c' clue in your previous message.  Since sh uses
vfork, that indicates a vfork problem.  I've checked in some more
changes to deal with this.  It seems to do the right thing both with sh
-c and without.  It also should have the added benefit of doing the
right thing wrt deallocating the console appropriately since open_fhs
should now track the ctty usecount.  This was screwed up before,
apparently even before I started mucking with the tty stuff.

I sure do hate usage counting.

cgf
>>>
>>>
>>>Yes, that works fine now, as does bash -c inetd.
>>>
>>
>>Sorry to jump in on this, but I run into a few problems with the changes 
>>you made last night and one issue which has been a problem for some time 
>>now.
>>
>>This is on my Win2k box and all problems were noticed when I logged in 
>>remotely via ssh (I have not tried locally).  If it makes any 
>>difference, the /usr/src dir, where all my project and cygwin source is 
>>contained, is a managed mount.
>>
>>Issues from yesterday's checkin:
>>1)When run by itself from the command line, `make` is not forking 
>>properly for recursive makes, instead it aborts and returns a bogus 
>>HANGUP signal to the console.  This is easily seen when attempting to 
>>build the Cygwin tree.  I cannot provide any useful output since it 
>>appears that calling the process from within gdb or through strace 
>>actually keeps make from failing to fork, but make still screws up the 
>>order of entry into subdirs.
>
>I routinely check correct cygwin operation by building cygwin so I can't
>reproduce this.
>
>>2)`procps auxf` incorrectly identifies top-parent processes as 
>>, even though ps and the nt process monitor shows them to be 
>>valid.  However, for postgres's postmaster, the parent and *all* 
>>children are labeled as  even though I can confirm that the 
>>server is up and running.
>
>A trivial test of this, which is to run "procps auwx" from a command prompt,
>does not demonstrate this here.
>
>>3)Running configure scripts using sh.exe (which is default when you 
>>./configure) always hangs, whereas running them through bash.exe works 
>>fine (although it does hang from time to time).  In either case, when it 
>>hangs, doing ctrl-c will drop you to the command line.  However, the 
>>process isn't terminated, like one would expect.  Also, it refuses to 
>>obey any signal except SIGKILL.
>
>I don't use bash very often.  I use zsh or just the command prompt.  I
>can run 'sh /whereever/configure' just fine.
>
>>Existing issues since 1.5.5:
>>3)I find myself involuntarily "logged-out" of my sessions at random 
>>intervals.  This is especially prevalent when doing massive recursive 
>>`rm -rf`'s or `grep -rn`'s or any other form of intensive disk i/o. 
>>However, whatever is causing it seems to be getting fixed, since this 
>>happens less frequently then it used to.  A small kludge I use to get 
>>around this is by running links.exe then using ctrl-Z to send it to a 
>>stopped state.  Then if it tries to log me out, it will fail because I 
>>have a stopped process.
>
>Again, I don't see this, so I don't know how it could be fixed.
>
>>4)lynx crashes on startup, dropping me back to the command line. 
>>Running it through gdb, the segfault happens at line 81 of cygtls.cc, 
>>"_last_thread->next = this" which is inside the function 
>>_threadinfo::init_thread(void*).  Unfortunately, my system is in a state 
>>where I cannot get make to run correctly, so trying to build a debug 
>>version of lynx at this point is not feasible.  I should note that I do 
>>not see this problem inside links.
>
>Since cygtls.c is a recent addition, this is not a 1.5.5 issue.  lynx
>also works fine here.

Btw, I should point out, that I am using the most recent version of
cygwin currently in CVS.  I didn't try this with the cygwin vintage that
this message refers to but I haven't made any changes which would cause
any of the above to work any better.

cgf

--
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/

Problem searching archives of this list.

[Greg Smith]

I'm trying a very simple search: cygpcre-0.dll
It doesn't work,  I get all the hits for cygpcre
and dll, even if it's in quotes. As a result, I am
probably about to submit a duplicate report.
I know, it's probably because that's the way
it's indexed. Still, it turns what could be a very
narrow, targeted search into a fruitless one.


--
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: Problem searching archives of this list.

[Larry Hall]

At 10:03 PM 12/29/2003, Greg Smith you wrote:
>I'm trying a very simple search: cygpcre-0.dll
>It doesn't work,  I get all the hits for cygpcre
>and dll, even if it's in quotes. As a result, I am
>probably about to submit a duplicate report.
>
>I know, it's probably because that's the way
>it's indexed. Still, it turns what could be a very
>narrow, targeted search into a fruitless one.


I'm assuming you used the search engine with the email archives.  No one
really uses that for anything serious. ;-)  Try this:







--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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: 1.5.6-pre: Occasional bad memory accesses within cygwin1.dll

[Christopher Faylor]

On Sun, Dec 28, 2003 at 03:52:33PM -, Max Bowsher wrote:
>I installed a self-built cygwin HEAD version - mostly it works fine, but it
>causes odd failures during builds (speculation: race when many processes
>being created and destroyed?)
>
>The most common failure is a Windows error box:
>
>The instruction at "0x6108621a" references memory at "0x610030b0". The
>memory could not be written.
>
>(These addresses are constant.)
>
>$ addr2line -e /bin/cygwin1.dll 0x6108621a 0x610030b0
>.../src/winsup/cygwin/shm.cc:331
>.../src/winsup/cygwin/cygthread.cc:34

This isn't too useful, unfortunately.  The line numbers are an artifact
of the fact that there is no STABS information in the generated asm in
'sigfe.s'.  Can you get an assembly listing of the lines around this
instruction?

>The errors are usually in sed, grep, or dirname.
>
>This is sometimes accompanied by this error on the console:
>
>4 [proc] sh 1160 sig_send: error sending signal 20 to pid 1160, pipe handle
>0x, Win32 error 6

I fixed a problem like this a while ago.  It's difficult to see how this
case could occur unless you are using an old version of sigproc.cc, in
particular, the no_signals_available macro sounds like it isn't
up-to-date.

cgf

--
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: 1.5.6-pre: Occasional bad memory accesses within cygwin1.dll

[Christopher Faylor]

On Sun, Dec 28, 2003 at 03:52:33PM -, Max Bowsher wrote:
>Less common failures include shell scripts receiving terminating with a
>"Hangup" message, or locking up entirely.
>
>Debugging suggestions welcome.

Forgot to add that the obvious thing to try here is attaching to the
process in the "locking up entirely" situation.

--
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/

'Can't find X library'

[Janice Levenhagen]

Hey,
So when I run ./configure I get that it cannot find the X library.  I have
searched everywhere for an answer for this question and I actually found one. 
It says to change the configure script to search not only for $i/libX11.a and
$i/libX11.so, but also for $i/libX11.dll.a.  Unfortunately, my configure script
tells me it does not find this, although if I type in the exact path that it is
looking in (well, one of them...the one it's in...:) ), it's right there.  Why
is it not finding it and why can't everyone else's solution work for me
too...:) I had sent out another question before on the ns mailing list about it
not passing a test (test-all-tagged-trace) for ns2, but I don't know if they
are related or not.
Thanks,
Janice
 
 



--
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/