smokes (was Re: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis)

[Nicholas Clark]

On Thu, Jan 09, 2003 at 02:16:38AM -0500, Christopher Faylor wrote:

> I wasn't aware of that but then I haven't been reading perl5-porters for a while
> now.  I don't know what smokes is but I assume it's a periodic test run of perl
> on various platforms.

Yes, it's "smoke testing". H Merijn Brand wrote a harness script that lets
a machine burn CPU trying various combinations of configuration options,
and reporting whether any regression tests fail.

Stating the obvious, but it lets you know very quickly whether a patch you
created on one platform is actually portable to other platforms or other
compilers. Given that perl builds on many architectures, and has many
configuration options, but most developers are on Linux or FreeBSD using gcc
this is a great help. Once you have several machines on different
architectures, or with different compilers, the patterns of failures allow you
to work out what's the actual cause of a problem. (eg which of
architecture/compiler/configuration)

I guess that sort of portability conformance testing isn't that much use to
Cygwin. Then again, I know little about Cygwin or Windows, so possibly there
are portability problems between compiler versions and Windows versions.
Having lots of regression tests makes this useful, and I don't know what
form, or how numerous, Cygwin's tests are. Related to this, one of the
problems people have found with batch testing of perl on Windows systems is
that SEGVs and other failures can cause windows to pop up some sort of
dialogue box, causing the batch test system to stall.

Nicholas Clark

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [Bug] 1.3.18-1: Problem with arrow keys and rxvt/bash/mc

[Stuart Brady]

On Sat, Jan 11, 2003 at 12:40:52AM -0600, Steve O wrote:
> The change I suspect is one that writes characters one at a time to the
> slave, instead of a bulk write of the entire buffer.  Thus, it's 
> possible for the slave to read half of an escape sequence in a 
> race condition.  I was under the impression that the slave, mc in
> this case, should be able to deal with this condition, or am I mistaken?

I'm not sure. Does this situation arise elsewhere? It seems reasonable
to send as much as possible in one single write. Remember that if
somebody sends ESC, you can't keep everything in a buffer until the
sequence ends, as this would break programs like vi.

On everything I've seen, the escape key actually sends ESC. If you press
escape, followed by some other characters, are those characters part of
an escape sequence or not? I suspect that these ambiguous sequences,
depending on timeouts and bulk writes to be complete nonsense, but it
looks like we're stuck with them now.

For example, in vim, type "iHello world" and press ESC, followed by
shift-O and then shift-D. If you do this quickly enough, you will still
be in insert mode (able to type stuff in) and the cursor will have moved
one place to the left.

If you wait about a second between pressing ESC and shift-O, and/or
between shift-O and shift-D, then you will firstly go into insert mode
on a newly created line (directly above where you were just typing),
and you will then enter the character D into this line.

No doubt if you press the left arrow key, generating the sequence all
in one go, this intermediary confusion is likely to be eliminated. If
there's a long enough pause between O and D being sent, when you press
the left arrow key, vim would insert D into a new line for you!

I notice that nvi isn't nearly as tolerant as vim. Most programs seem to
accept escape sequences that are typed in manually - nvi doesn't.

Oh, you wanted to quit vim? I'm sorry - press ESC, and type ":q!". :)
-- 
Stuart Brady

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cygwin's autoconf?

[Lapo Luchini]

Robert Collins wrote:


Now, for the problem reported the root problem here is *NOT*
autotools brokenness. It's CVS being broken (unless I'm seriously
mistaken).


I did forget to thanks you all..
Finally I know much more about how to use the autotools and what is 
actually done by each tool.
Thanks to you all for the "bootstrap".

BTW: someone said at that time that "autoreconf is not so useful as it 
can't install automake files with the correct tags".. at least in my 
case "autoreconf -i" solves perfectly the problem (I prefer not to store 
any "generated" file in my CVS... anyway I'm the only workign at it so 
"all the people working on it can use the autotools"), or maybe "-i" is 
a switch that whas not available at that time 0=)

Thanks, again.

--
Lapo 'Raist' Luchini
[EMAIL PROTECTED] (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis

[Larry Hall (RFK Partners, Inc)]

I've found that it's always easy to look back at a previously made design
decision and question it, especially when one wasn't involved in the 
design discussion that weighed the current needs with the benefits and
detriments of possible implementations.  Rethinking a design decision 
isn't bad of course but it's always easier to see more alternatives in 
hindsight than it is at the time.  Some of the reason more options are 
generally 'obvious' in hindsight is because there is more infrastructure
in place that would support these options.  That's not always the case at
the time a feature is implemented.  Suffice it to say there was 
precedent for the '///' syntax
of UNC paths a problem to prompt making a change to something that allowed 
both benefits (the current '/cygdrive/' convention).  You may 
be able to find some threads of this whole discussion and development in the 
email archives if you're interested in doing a little digging.  You might
find that it answers allot of questions you have about Cygwin path handling.
I'd start with 1997 though if you're looking to pick up any threads that were 
at least close to the opening discussions.

Larry


At 06:25 PM 1/10/2003, LA Walsh wrote:
>Interesting...wonder why they wouldn't just create pseudo devices
>in /dev and do the normal unix mount thing?  Seems odd to complicate the simple
>namespace model needlessly by adding a special syntax.
>
>Even still, just because one wants to have more traditional unix names doesn't
>preclude the possible design goal of backward compatibility with
>existing Win32 pathnames to aid in portable tool usage and design.
>
>Even a hard coded /smb/ or /smb:/ prefix on smb  shares would be
>a better choice that "//".  Why perpetuate the MS view of 
>SMB being 'special' vs. using an eventual mounting syntax that would
>allow it to coexist with /nfs/ type files?  If the mount system evolved
>enough in cygwin, then I could see mount allowing specification of
>'nfs' in a mount command -- either as a link to an MS-nfs method
>(assuming they were supply one) or cygwin-based NFS methods like the
>universal NFS server... 
>
>-linda
>
>
> > Cygwin predates RedHat. See http://cygwin.com/history.html  (the 
> > earliest date in the file is Dec 1995). RedHat bought Cygnus 
> > Solutions 
> > (which was a shop for commercial support for GNU software, especially 
> > GCC ports to obscure and new platforms), which did the 
> > original Cygwin work.
> > 
> > Anyone at RedHat from the original Cygwin team (the last 
> > warriors of the 
> > (in)famous "Beta 20" :-)?) wanna answer this?
> > 
> > There's an interesting line in the early changelogs:
> > 
> > Release Beta 8
> > [...]
> > Much nicer way of describing paths, eg //c/foo is c:\foo.
> > 
> > Suggests that the early goal *was* to provide a POSIX-y view, and the 
> > exposing of Windows paths was added as a convenience..
> > 
> > 
>
>
>--
>Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting: http://cygwin.com/bugs.html
>Documentation: http://cygwin.com/docs.html
>FAQ:   http://cygwin.com/faq/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

bison-1.75 src/bin problem

[Attila Csosz]

Hi,

I'd like to add some features to bison and thus I must rebuild bison but 
there is a bug maybe. The bin package works nice but when I'm using the 
exe compiled from
the source the following error occured: the error line reported by the 
bison is higher (almost by 500) then reported the original bison (good). 
Of course I tried this with the original source
package (not adding my things) but this error remains.

I copy here some log (the first 3 line in the log):

-- original (this is good) --
parser.yy:376.11-377.13: type clash (`yy_void' `yy_t_token') on default 
action
parser.yy:378.5-17: type clash (`yy_void' `yy_t_token') on default action
parser.yy:397.18: empty rule for typed nonterminal, and no action

-- compiled from source (wrong, not adding my things) --
parser.yy:751.11-753.13: type clash (`yy_void' `yy_t_token') on default 
action
parser.yy:755.5-17: type clash (`yy_void' `yy_t_token') on default action
parser.yy:793.18: empty rule for typed nonterminal, and no action

I'm executed the following commands to compile the source package: 
"configure;make"


Thanks for your help
Attila


--
ICQ - [ # 173551800 ]




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Are you paying too much?

[Sommano]

Dear Smart Consumer:

At last, Unlimited Long-Distance & Local Calls.  No Cost to try it out!

Click to see eCommercial:
http://64.7.200.12/ads/HTMlMailForAdvAccount.cfm?SentBannerID=&BannerID=23225&EmailAddress=som%40nexxrep%2Ecom&EmailID=1105646


Sommano Sivongsay - CEO/Founder
SOM Marketing, Inc.
http://www.SOMMarketing.com
Awaken the Wealth Warrior from Within!



This is Unsolicited Commercial E-mail (UCE)and is in compliance with
H.R. 95 & H.R. 718 and is not SPAM.
Please accept my apologize if you are not interested in our program.
SORRY!!! Use the link below to be immediately REMOVED. Thank you.
mailto:[EMAIL PROTECTED]?subject=REMOVE



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Hindsite, moving forward, concepts...?

[linda w \(cyg\)]

> From: Larry Hall (RFK Partners, Inc) [mailto:[EMAIL PROTECTED]] 

> I've found that it's always easy to look back at a previously 
> made design decision and question it, especially when one 
> wasn't involved in the 
> design discussion that weighed the current needs with the 
> benefits and detriments of possible implementations. 
---
At the time one makes decisions one cannot know what one will know in 5,2,1 
years or 4 months time. At my last company,
large group made decision to go w 1 vendor out of 2 for a feature we
needed.  Logically, choice #2 was better, though for some intangible reason (that I 
couldn't justify) I felt safer with choice #1
even
though the facts didn't stack up in their favor.  The group decided
to go with choice 2.  Five months later, choice2 announced a law
suit with one of their suppliers that had been ongoing for about 6-8 months (i.e. they 
knew they were in trouble when negotiating
with
us but were hoping to get our money to tide them through the financial rough waters 
until they could legally force their supplier to
live up to expectations...).  It killed the project for our company -- the other 
company got wind of our deal and now had almost
doubled the price and the critical product timing window would be
about 80% closed by the time we'd be able to get a release from 
company #1.

In retrospect, I can see more logically, why I felt the way
I did -- we had more experience and work history with #1 even though they had some 
known and recurrent issues.  I felt more
comfortable with the known 'evil' that I felt we could safeguard against vs. the 
unknown "snake-oil" sales people from company #2.
Also #2 had a
*very* polished marketing pitch, while company #1 had virtually no marketing -- almost 
all engineers.  That also figured into my
"feeling": if you have two small companies, both have limited 
resources to produce the same product and prices are in the same
range.  Then if one has really snazzy presentations vs. the
others have more raw presentations looking like engineer written
documentation (vs. tech pubs), which company do you think is 
more likely to have resources to complete an engineering project?


> Rethinking a design decision 
> isn't bad of course but it's always easier to see more 
> alternatives in 
> hindsight than it is at the time.  Some of the reason more 
> options are 
> generally 'obvious' in hindsight is because there is more 
> infrastructure in place that would support these options.  
> That's not always the case at the time a feature is 
> implemented.
---
Absolutely...just the idea of mentioning 'mount' or even
the idea of NFS or an 'automounter' -- they aren't the first things one would be 
thinking about in an environment where you don't
even have a self-hosted, compiler yet.

That's one reason I think long term project planning is
a waste to devote *too* much detail towards.  You don't know
what the state of the art will be in 2 years -- or what new tools will be available, 
or whatever.  You just do the best you can
at the time -- designing things as modularly and bullet proof
as you can so you can more easily re-use code with minimal
changes in new features in un-anticipated ways.  Using the reasoning "well it wasn't 
designed for that" doesn't help you alot when
all you wanted to do was write an email *now* to your stock broker
to 'sell'.  You get to have your sale or you don't.  The market doesn't care.  There 
is no 'good guy/bad guy', blame is irrelevant.
The only thing that is relevant is if you sold your stock or not.

  Suffice it to say there was 
> precedent for the '// or was it O/S 2?) and pseudo device support was very much in 
> it's infancy.  But these are not the only reasons this syntax 
> came into being.  The main reason was because somebody wanted 
> it and then implemented it.  It addressed the need of being 
> able to easily access all available drives without the user needing 
> to explicitly set up mount entries.  Obviously, while folks 
> using Cygwin in general liked the notion of not having to 
> mount drives explicitly, there were enough who found the 
> conflict with the '///' syntax of UNC 
> paths a problem to prompt making a change to something that allowed 
> both benefits (the current '/cygdrive/' 
> convention).  You may 
> be able to find some threads of this whole discussion and 
> development in the 
> email archives if you're interested in doing a little 
> digging.  You might find that it answers allot of questions 
> you have about Cygwin path handling. I'd start with 1997 
> though if you're looking to pick up any threads that were 
> at least close to the opening discussions.
---
I can see how the decision was made.  I believe I _might_
have tried for a special prefix like /net/ -- a different 
flavor of hack, but not without wide precedent: /debug, /proc,
/host (not really hardcoded, but defaulted)" etc.

But you're right in that you can nev

Re: Updated: OpenSSH-3.5p1-3

[John David Galt]

When attempting to install this update I get an error message saying that
"cygwin1.DLL" is not installed.  Where do I get it and how do I install it,
since the automated install process can't?

Please reply directly, I'm not on this list.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: mean & grumpy (cygwin path analysis)

[Elfyn McBratney]

> My configuration problem? Try *your* broken list manager that allows
posting
> from list outsiders!   Pblblblblblt!I mean, many users, realizing
their mistake
> of using the wrong account, would just resend it under the correctly
subscribed
> address -- perfectly normal list behavior, but nooOOO  You've just
got
> to be different and set things up to violate normal expectations!  Another
fine
> example of _your_ mean-spiritedness to pick on 'younger' (in cygwin age)
list
> members and just strive to make them %w-R_o=N~g*_!

What so it's the list managers fault? The reason you don't have to subscribe
to this list, I'm guessing, is to make it easier for new user's post here
instead of *forcing* them to sign-up first. If thats being "different" and
violates "normal expectations" then I obviously cannot argue with you on
this matter. If you send a mail to a mailing list, come to realise that you
used the wrong address, do you then go back and send it again even though
it's already got there?

I can see you keep changing your mind... So which is it the broken list
manager or Chris's mean spiritedness?

> > One would have to wonder...
> ---
>
> And what is *that* supposed to mean?  Another veiled attempt to be mean?
>
> You know, I'm onto your game now!  Scientists have found proof of a
grumpiness / meanness gene, ya know!

I think that was referring to why you we're sending duplicates to the list
YA. A lot of things are mean in your opinion aren't they?

> Banning simple HTML formatting in email is like banning magazine layout in
favor of 8.5x11 Courier-typed 'articles'.

When you (and others on the list) sends mails they eventually get processed
by Mhonarc, the archiving software, and the body of the message is placed in
 tags so even if HTML formatting was allowed it wouldn't get the
desired effect. You will also find that this is not the only list on the net
that doesn't allow mime-encoded mails.

Elfyn
[EMAIL PROTECTED]



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Updated: OpenSSH-3.5p1-3

[Elfyn McBratney]

> When attempting to install this update I get an error message saying that
> "cygwin1.DLL" is not installed.  Where do I get it and how do I install
it,
> since the automated install process can't?

Do you have the path to your cygwin bin directory in your path? eg.
c:\cygwin\bin? If not if you add that to your path environment variable this
should go away.

If it's not reply with the output of `cygcheck -svr' attatched (attatch as a
plain-text and non-compressed file).

Elfyn
[EMAIL PROTECTED]



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Solving the "relink exe's" libtool problem [take 2]

[Charles Wilson]

Alexandre Duret-Lutz wrote:

 Chuck> Said "stub" executable would have to do ALL of the
 Chuck> things the script does, and then pass that environment
 Chuck> to its exec'ed target in .libs/ --

Maybe it could just exec() something like `/bin/sh .libs/foo.sh',
where `.libs/foo.sh' is the script wrapper.


Good idea.  Try this version...

It no longer requires any coordination with automake; it's all 
implemented in ltmain.sh and doesn't mess with EXEEXT or LT_EXEEXT.

Now, this isn't perfect -- it solves the problem, has no regressions on 
cygwin, and is probably okay for inclusion in libtool CVS.  But there 
are stylistic warts that could be sanded off, if someone else were to 
take the effort (hint, hint)

The following behavior is only "active" when $host is cygwin or mingw:

I left the shell wrapper where it was, in the build directory.  When 
creating the shell wrapper, libtool will also create lt-${prog}.c and 
compile it using
   $run $LTCC -s -o ${prog}.exe lt-${prog}.c

So, you end up with:

/foo   (shell wrapper)
/foo.exe   (binary wrapper)
/lt-foo.c
/.libs/foo.exe (the real executable)

Since builddir contains foo.exe, make is happy.  ./foo.exe execs 
"/bin/sh foo", which sets up the environment and calls .libs/foo.exe.

Eventually, the functionality of the shell wrapper could be moved into 
the source code for the binary wrapper, and we could drop the shell 
wrapper completely for cygwin/mingw $host.

So the fact that the shell wrapper is still there is a wart (but 
removing the shell wrapper creates its own difficulties -- see next point).

There are two places in ltmain.sh where the shell wrapper is directly 
sourced.  This doesn't work very well, because when both "foo" and 
"foo.exe" exist, ". ./foo" ends up sourcing "foo.exe" -- which is bad.

[Note, if the shell wrapper is eliminated, then somehow libtool needs to 
be able to get the info embedded into the binary wrapper.  Maybe the 
binary wrapper needs a "--shell" option, that emits what is effectively 
the current shell script?  But then, that's just another wart (`binwrap 
--shell > shellwrap`; . shellwrap ; rm shellwrap), unless there is a way 
to "source" rather than execute the contents of a variable.]

But, if both the binary wrapper and the shell wrapper exist, there are a 
few ways to solve the conflict that occurs when libtool tries to source 
the shell wrapper (and sources the binary wrapper instead):
  (1) prior to directly sourcing the shell wrapper into libtool's 
memory space, make a temporary copy with a name that doesn't conflict 
with "foo.exe" in the same way that "foo" does.  E.g.
  cp foo lt-foo.sh
  . ./lt-foo.sh
  rm -f lt-foo.sh
Yes, it's a race condition, but it should be temporary pending further 
work...

  (2) on the cygwin/mingw platforms, change the name of the shell 
wrapper itself.  So don't create "foo" at all; instead, create lt-foo.sh 
(or .libs/foo.sh).  But this requires catching ALL of the places were 
$output or $outputname are set, and fixing them with case $host ; 
*cgywin* | *mingw* ) ... ;; esac blocks.  Blech.

I did #1, as it appeared to require fewer modifications.  ($output and 
$outputname are set in SO many different places...)  Plus, I anticipate 
that, at least on cygwin/mingw, we might eventually completely do away 
with the shell wrapper by incorporating its functionality within the 
binary wrapper(given the caveats re: --shell above)...an added incentive 
to avoid disrupting the rest of ltmain.sh beyond the absolute minimum.

Also, there may be some complaints about using $LTCC to build the binary 
wrapper, especially in the context of a cross compiler.  Here's a block 
of comments from the patch:

# we should really use a build-platform specific compiler
# here, but OTOH, the wrappers (shell script and this C one)
# are only useful if you want to execute the "real" binary.
# Since the "real" binary is built for $host, then this
# wrapper might as well be built for $host, too.
$run $LTCC -s -o $cwrapper $cwrappersource

--

cgywin: if you've already installed my test versions of automake and 
libtool (automake-devel-1.7.2-2 and libtool-devel-20030103-2), you must 
revert to the "REAL" cygwin automake-devel-1.7.2-1.  Then, update to 
libtool-devel-20030103-3 which is now available by pointing setup.exe at
  http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/

mingw: test reports?

automake: please ignore the previously posted patch

libtool: Hopefully this gives a starting point for further refinement. 
But IMO it is okay (e.g. functional) for inclusion into CVS as-is, 
provided that it causes no problems on non-windows, and fixes the 
relink-exe problem on mingw.  It DOES fix the relink-exe problem on cygwin.

---

--Chuck
2003-01-11  Charles Wilson  <[EMAIL PROTECTED]>

* ltmain.in: add code for a binary wrapper
to use with uninstalled executables on cygwin/mingw.
 

Re: Updated: OpenSSH-3.5p1-3

[John David Galt]

Elfyn McBratney wrote:
> 
> > When attempting to install this update I get an error message saying that
> > "cygwin1.DLL" is not installed.  Where do I get it and how do I install
> it,
> > since the automated install process can't?
> 
> Do you have the path to your cygwin bin directory in your path? eg.
> c:\cygwin\bin? If not if you add that to your path environment variable this
> should go away.

What path?  I'm running Windows 98.  There doesn't seem to be any path for
me to set.  C:\autoexec.bat (where PATH was set in earlier versions of
Windows) consists of one SET BLASTER=string command followed by gibberish.

Should I be running SETUP.EXE via a Windows shortcut in order to set a PATH
private to that DOS window?  If so, what settings are needed?

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Updated: OpenSSH-3.5p1-3

[Michael A Chase]

On Sat, 11 Jan 2003 18:54:08 -0800 John David Galt <[EMAIL PROTECTED]> 
wrote:

> > > When attempting to install this update I get an error message saying that
> > > "cygwin1.DLL" is not installed.  Where do I get it and how do I install it,
> > > since the automated install process can't?

Setup.exe doesn't depend on cygwin1.dll.  Any postinstall scripts
probably do, but they should be able to find the dll if the rest of
the installation isn't corrupted.

Try re-installing the cygwin package from the local directory using
setup.exe, then exit setup.exe and run it again to re-install your
other packages.  Not using setup.exe makes it much harder for anyone
here to help and most of us won't try.

http://cygwin.com/bugs.html may help you track this down further.  The
output from cygcheck.exe may be particularly interesting.

> > Do you have the path to your cygwin bin directory in your path? eg.
> > c:\cygwin\bin? If not if you add that to your path environment variable this
> > should go away.
> 
> What path?  I'm running Windows 98.  There doesn't seem to be any path for
> me to set.  C:\autoexec.bat (where PATH was set in earlier versions of
> Windows) consists of one SET BLASTER=string command followed by
> gibberish.

Your c:\autoexec.bat may be corrupted.  I think Win98 and WinME still
use autoexec.bat for setting global environment variables.  It should
be a text file in any case.

Adding c:\cygwin\bin to your global %PATH% is useful for normal
operations, but it should not affect setup.exe or any postinstall
scripts.

> Should I be running SETUP.EXE via a Windows shortcut in order to set a PATH
> private to that DOS window?  If so, what settings are needed?

It shouldn't matter.  I have a copy of setup.exe in the base directory
of my local package archive cache tree (i.e., local directory) with a
shortcut pointing to it, but you should be able to run it from
anywhere by any means you like.

-- 
Mac :})
** I normally forward private questions to the appropriate mail list. **
Ask Smarter: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Give a hobbit a fish and he eats fish for a day.
Give a hobbit a ring and he eats fish for an age.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Updated: OpenSSH-3.5p1-3

[Christopher Faylor]

On Sat, Jan 11, 2003 at 07:27:40PM -0800, Michael A Chase wrote:
>On Sat, 11 Jan 2003 18:54:08 -0800 John David Galt <[EMAIL PROTECTED]> 
>wrote:
When attempting to install this update I get an error message saying
that "cygwin1.DLL" is not installed.  Where do I get it and how do I
install it, since the automated install process can't?
>
>Setup.exe doesn't depend on cygwin1.dll.  Any postinstall scripts
>probably do, but they should be able to find the dll if the rest of the
>installation isn't corrupted.

I noticed recently that if you are updating the DLL and there is a
preremove script in another package, then it is possible that
cygwin1.dll will be removed and then the preremove script will run.  The
premove script won't be able to run because cygwin1.dll is missing.  I
assume that similar problems may result if ash is being installed, too.
The problem that I saw is probably pretty harmless most of the time,
though.  I don't know if that is what is happening here.  Probably not,
but I thought I'd mention it.

cgf
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to [EMAIL PROTECTED]
and be permanently blocked from mailing lists at sources.redhat.com

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: javac on cygwin

[Randall R Schulz]

Kevin,

Someone asked on  about makefiles for 
Java. Another person replied with a pointer to this site: 
, which appears to have a good makefile 
for Java. It should be usable as-is or easily be modified to work under Cygwin.

I haven't tried it, but I remembered your query and thought you might like 
to check it out.

Randall Schulz


At 03:52 2003-01-04, Kevin Cheng wrote:
Ok, I've searched for articles on getting a java
compiler working on cygwin. I got very vague info.

Can someone please give me the newbie quick setup on
setting up a java compiler to work on cygwin.

I've got the java JDK 1.4.1 from java.sun.com. Now
what do I do?



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

1.18 mysql+perl+dbi+dbd::mysql

[Nikolayev Dmitry]

I have installed cygwin 1.18, perl 5.6, DBI 1.30, mysql for windows 3.23.54
But when I tryied to install DBD::mysql, I got some errors with compiling:

dbdimp.c:632: `MYSQL_OPT_COMPRESS' undeclared (first use in this function)
dbdimp.c:632: (Each undeclared identifier is reported only once
dbdimp.c:632: for each function it appears in.)
dbdimp.c:641: `MYSQL_OPT_CONNECT_TIMEOUT' undeclared (first use in this
function
)
dbdimp.c:652: `MYSQL_READ_DEFAULT_FILE' undeclared (first use in this
function)
dbdimp.c:662: `MYSQL_READ_DEFAULT_GROUP' undeclared (first use in this
function)

dbdimp.c:729: warning: passing arg 5 of `mysql_real_connect' makes integer
from
pointer without a cast
dbdimp.c:729: warning: passing arg 6 of `mysql_real_connect' makes pointer
from
integer without a cast
dbdimp.c:729: warning: passing arg 7 of `mysql_real_connect' makes integer
from
pointer without a cast
dbdimp.c:729: too many arguments to function `mysql_real_connect'
dbdimp.c: At top level:
dbdimp.c:1117: parse error before "val"
dbdimp.c: In function `my_ulonglong2str':
dbdimp.c:1118: `val' undeclared (first use in this function)
dbdimp.c: In function `mysql_st_fetch':
dbdimp.c:1523: warning: assignment from incompatible pointer type
make: *** [dbdimp.o] Error 1

Did anybody installed DBD::mysql? Or where can I read any information about
installing cygwin + mysql?

Nikolayev Dmitry


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: mean & grumpy (cygwin path analysis)

[LA Walsh]

> What so it's the list managers fault? The reason you don't 
> have to subscribe to this list, I'm guessing, is to make it 
> easier for new user's post here instead of *forcing* them to 
> sign-up first. If thats being "different" and violates 
> "normal expectations" then I obviously cannot argue with you 
> on this matter. If you send a mail to a mailing list, come to 
> realise that you used the wrong address, do you then go back 
> and send it again even though it's already got there?
===
Well, not no more...now that I know this list doesn't bounce.


> I think that was referring to why you we're sending 
> duplicates to the list YA. A lot of things are mean in your 
> opinion aren't they?
---
Yep.  Just a mean mean world.  Very very sad...:-(((!
(:-))

In fact, I think it is soooooo mean -- that...
well it just is!  Pblblblblt.

> 
> > Banning simple HTML formatting in email is like banning magazine 
> > layout in
> favor of 8.5x11 Courier-typed 'articles'.
> 
> When you (and others on the list) sends mails they eventually 
> get processed by Mhonarc, the archiving software, and the 
> body of the message is placed in  tags so even if HTML 
> formatting was allowed it wouldn't get the desired effect. 
> You will also find that this is not the only list on the net 
> that doesn't allow mime-encoded mails.

I know -- a lot of lists don't -- its just that 
it's seems a giant step backwards in terms of communication --
even handwriting is more expressive -- even a real typewriter
could do underlining, and bold.  How about RTF?  Is that
portable enough?  Just feels like I'm stuck in the 70's.
The TTY's have gotten fancier, but its still mostly ascii text in terminal 
windows...sorta sad (not mean though..thats different), though it could be mean if it 
was a conspiracy...) :-)

-l



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Installing the Win32:: modules for Cygwin Perl

[Rafael Kitover]

I have a patch for libwin32-0.191 to build under Cygwin Perl, both 5.6
and 5.8. This is based on the work of Clive Nicolson a while back.
 
This will give you the core Win32 methods, as well libraries like
Win32::APIFile, Win32::Sound, Win32::Clipboard etc.
 
There is still quite a bit of work to be done to cleanly integrate these
into Cygwin Perl so that no patching is necessary
 
That aside, from a user perspective these _should_ work fine (no
guarantees.) Just remember that while ActivePerl will not require you to
“use Win32” for core methods like Win32::GetOsVersion(), this version
does. Also Win32 Perl code may use Win32 commands and paths, in which
case you may have to do some porting.
 
You are better off using the newer Cygwin packages, especially gcc and
w32api, but I’m curious to see if older configurations will also work.
 
Instructions, from the Cygwin shell:
 
wget http://search.cpan.org/CPAN/authors/id/G/GS/GSAR/libwin32-0.191.zip
unzip libwin32-0.191.zip
wget http://www.io.com/~rkitover/libwin32-0.191-port.diff
patch –p0 < libwin32-0.191-port.diff
cd libwin32-0.191
perl Makefile.PL && make && make test && make install
 
Do NOT download the patch using a browser such as IE, the line ends will
get converted and the patch will fail.
 
Everything should work. If something fails, please send me an error
report using this method:
 
make test &> makelog
gzip -9 makelog
 
and mail makelog.gz to [EMAIL PROTECTED] so I can figure out what went
wrong.
 
Enjoy.
 
-- 
Rafael Kitover

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Installing the Win32:: modules for Cygwin Perl

[Michael A Chase]

On Sat, 11 Jan 2003 23:20:13 -0800 Rafael Kitover <[EMAIL PROTECTED]> wrote:

> I have a patch for libwin32-0.191 to build under Cygwin Perl, both 5.6
> and 5.8. This is based on the work of Clive Nicolson a while back.
>  
> This will give you the core Win32 methods, as well libraries like
> Win32::APIFile, Win32::Sound, Win32::Clipboard etc.
>  
> There is still quite a bit of work to be done to cleanly integrate these
> into Cygwin Perl so that no patching is necessary

Have you sent this patch to Gurusamy Sarathy <[EMAIL PROTECTED]>?
It would be nice to have as much as possible of it included in the
base package.  He made the first port of Perl to Cygwin, so he'd
probably be glad to fix any problems someone finds.

-- 
Mac :})
** I normally forward private questions to the appropriate mail list. **
Ask Smarter: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Give a hobbit a fish and he eats fish for a day.
Give a hobbit a ring and he eats fish for an age.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/