Re: Cygwin Check Package

[Gerrit P. Haase]

Hallo Andrew,

Am Donnerstag, 14. Oktober 2004 um 02:39 schriebst du:

> I just recently began using Cygwin and was pleased to find your port
> of the Check framework. I was curious if you had noticed that a couple
> of new versions have been released since your last update:
> http://sourceforge.net/project/showfiles.php?group_id=28255&package_id=20116
> Are you still maintaining the package? 

Yes.  I use it to test my Libexpat builds.  Last upgrade to Expat
doesn't need newer Check, however, I'll look to update it when I
update Expat the next time (probably today;).

Thanks,
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: Ping: Cygwin libtool / assembler problem with -DPIC

[Charles Wilson]

Gerrit P. Haase wrote:
Noah Misch wrote:
There was a thread about this general topic awhile ago.  That GMP 
actively uses
-DPIC to select the correct assembly came up:

http://lists.gnu.org/archive/html/libtool/2003-01/msg00060.html

I saw that -DPIC was used on Cygwin to compile assembly and it couldn't be
linked.  Also I read in the GMP sources somewhere that libtool adds this
flag where it is a noop on Cygwin when not compiling assembler code where
it breaks things, so the conclusion was to remove the flag entirely when
platform is Cygwin, I was able to build GMP and thats it.
Unfortunately I have no logs, but I tracked it down and realized that
this flag is the culprit and removing it resolves my problem.  Even
more bad that the demo I suspect to show the error doesn't build at all
with the recent Cygwin release (demos/expr).
Anyway, this flag is used where it is completely useless, so please
remove it, patch was already submitted to the Cygwin libtool maintainer.
Okay, I looked at the x86-defs.m4 file in the gmp distro.  It turns out 
that they specifically say:

Libtool gives -DPIC -DDLL_EXPORT to indicate a cygwin or mingw DLL.  We
undefine PIC since we don't need to be position independent in this
case and definitely don't want the ELF style _GLOBAL_OFFSET_TABLE_ etc.
ifdef(`DLL_EXPORT',`undefine(`PIC')')
Now, on *mingw*, we do indeed (up to now) define both DLL_EXPORT and PIC 
which compiling .lo's.  However, for cygwin, we no longer define 
DLL_EXPORT, but continue to define PIC.  So the little rule above is 
ineffective, and gmp ends up compiling the wrong assembler code.

Now, I'd call this a case -- maybe -- of gmp assuming too much about the 
internals of libtool.  OTOH, libtool emitting -Dcodes means that those 
codes are supposed to be USED, right?

I'm not convinced that it is a BAD thing to emit a -Dcode indicating 
when a source file is being compiled for a shared object, even when just 
considering cygwin alone.  I can see cases where one might want to 
implement something differently within a shared lib vs. a static lib. 
If we unilaterally remove -DPIC on cygwin, we can never do anything like 
that.

What gmp is doing is using the fact that "-DDLL_EXPORT" is defined to 
indicate that the target platform is cygwin or mingw.  It does this 
because gmp "knows" that it DOESN'T want to use the special PIC-guarded 
code on cygwin|mingw, *even* when building .lo's on those platforms. 
(The fun part is gpm-h.in specifically says libtool's DLL_EXPORT is NOT 
used.  Errr...bzzt.  Yes it is!)

However, DLL_EXPORT is an unreliable platform indicator, as we've 
obviously seen here; it's only true when building .lo's on mingw now. 
But I don't think just turning -DDLL_EXPORT back on for cygwin is the 
answer, either.  (I don't really remember when this stopped being on for 
cygwin, but whatever).

I think gmp's x86-defs.m4 needs to use $host (or whatever analogue it 
can conjure up) to determine when the platform is cygwin or mingw, and 
use THAT to decide when to undefine PIC.

Gerrit, if you change the line in x86-defs.m4 to ALWAYS undefine PIC, 
does that fix your build problem even when libtool still -DPIC's?  If 
so, then certainly we can come up with a better way for gmp's config.m4 
machinery to determine its target platform, right?

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

Re: [SOLVED] Re: other services ok, ftp not (was 1.5.11 - tcp problems)

[Brian Dessent]

Carlo Florendo wrote:

> On a curious note, why do the inetutils  apps like ftp, telnet, etc.
> still use getservbyname() and the other getserv  functions when, as you
> said,
> these apps could just have the port and protocol hardcoded or specified
> in a config file?

As far as I know that traces back to the original TCP/IP networking code
in unix, 4.2BSD circa 1983 from what a quick google shows.  Back then
things were a lot simpler and I suppose it was more straightforward to
have one config file that defined all the services the box was running
and what ports they were to listen on, and to have each daemon query
that file through getservbyname().  As far as I know the tools in
inetutils are the direct descendents of the original BSD commands from
way back, so the code still uses those methods.

Brian

--
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: non-interactive cygwin setup

[Robert Pendell]

Well there are ways to make a console/gui hybrid application (or at
least I read that it could be done) but there are a few tricks that
you have to pull.  It would be invisible to the end-user in the end
though.


On Thu, 14 Oct 2004 01:12:20 -0500, Gary R. Van Sickle
<[EMAIL PROTECTED]> wrote:
> [snip]
> > >I thought if a GUI app called printf it generally caused a
> > console to
> > >be opened for it.  Maybe that's only with msvcrt.  In any case, the
> > >fact is that it is being run from a cmdline and so it certainly can
> > >communicate with the console.  The presence of command-line
> > options in
> > >argc/argv could be taken as a fairly strong hint that it was
> > being run
> > >from a shell rather than an icon.  And there's always
> > "isatty (1)" if
> > >you really really want to be sure.
> >
> > This is a windows limitation.  GUI apps (apps created with
> > -mwindows) can't send output to or receive input from the
> > console.  Of course, a GUI can interpret command line
> > information.  It just cannot send output to the console that
> > started it.
> >
> > You could use AllocConsole to create a separate console which
> > the GUI could then use, however.
> 
> Here's a maybe-less-icky way to do it.  Have two exes, one "setup.exe" which
> is a 100% command-line program that normally just spawns "winsetup.exe", the
> current GUI setup, and goes away.  Give it "--help", and it prints help in
> the regular command-line way and exits.  Yeah, two exes, but worse tragedies
> have happened.
> 
> --
> Gary R. Van Sickle
> 
> 
> 
> 
> --
> 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/
> 
> 


-- 
Robert Pendell
[EMAIL PROTECTED]

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

Re: [SOLVED] Re: other services ok, ftp not (was 1.5.11 - tcp problems)

[Carlo Florendo]

Brian Dessent wrote:
Carlo Florendo wrote:
 

On a curious note, why do the inetutils  apps like ftp, telnet, etc.
still use getservbyname() and the other getserv  functions when, as you
said,
these apps could just have the port and protocol hardcoded or specified
in a config file?
   

As far as I know that traces back to the original TCP/IP networking code
in unix, 4.2BSD circa 1983 from what a quick google shows.  Back then
things were a lot simpler and I suppose it was more straightforward to
have one config file that defined all the services the box was running
and what ports they were to listen on, and to have each daemon query
that file through getservbyname().  As far as I know the tools in
inetutils are the direct descendents of the original BSD commands from
way back, so the code still uses those methods.
 

Great info. 

Thank you very much.
Best Regards,
Carlo
--
Carlo Florendo
Astra Philippipnes Inc,
www.astra.ph
--
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: Backup script not working properly

[Fredrik Persson]

Thanks, I changed to /bin/bash and now it's working fine.

Fredrik


--
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: Setup failure: mount error

[luke]

luke wrote:
[...]
I'll let people know how I get on.  Plan: first the FS check, then 
I'll try installing a stable known to work Cygwin, then I'll scrub and 
reinstall W2K, then I'll give up and try another PC.

Well, since I know the MD5 checksums are correct on both our local
stable Cygwin mirror, known to work, and on the nightly mirrored
"latest" mirror, and since these mirrors work on other PCs, it starts to
look like the problem is specific to this PC.
In other words, it appears to have nothing to do with having run "mount"
from a network install of Cygwin.  (Since all files created by Cygwin
and all registry entries were deleted, Cygwin stores no other
information on the system, and yet the problem persisted.)
I have scrubbed Windows, reformatted the drives, and am re-installing 
W2K now.  I fully expect this to fail as well.

In which case I'll just pick a different PC that Cygwin can be installed
on, and go back to testing what I was originally trying to test!
Basically, that worked.  It appears that Cygwin made some change that
persisted even after deleting all the Cygwin files and registry entries.
Our stable mirror is from some months ago - I got the error in the
postinstall about some missing cygwin gtk dll, but installation
completed okay, and re-running setup seemed to complete quickly (apart
from re-installing gcc, as it always does i've noticed).
The *only* thing I did different was save downloaded files to
c:\temp\cygwin instead of to d:\temp; and I didn't try running "mount"
from a network Cygwin either.  (Though I really don't think that was the
cause: too many Cygwin deletes, registry Cygwin deletes, and reboots in
between - how could the effect possibly have persisted?)
luke
--
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/

tzset et al

[Gerrit P. Haase]

Hello,

it is a mess...

Whatever happend after this thread,
http://www.cygwin.com/ml/cygwin-patches/2001-q1/msg00248.html
it was not the result that it is working now, the simple testcase Robert
provided still (or again) doesn't work.  Even if I use _tzname instead
of tzname it prints out nothing.

What can I do?  It is annoying to get an error everytime a package uses
timezone or tzname or related.

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: tzset et al

[Corinna Vinschen]

On Oct 14 11:50, Gerrit P. Haase wrote:
> Hello,
> 
> it is a mess...
> 
> Whatever happend after this thread,
> http://www.cygwin.com/ml/cygwin-patches/2001-q1/msg00248.html
> it was not the result that it is working now, the simple testcase Robert
> provided still (or again) doesn't work.  Even if I use _tzname instead
> of tzname it prints out nothing.
> 
> What can I do?  It is annoying to get an error everytime a package uses
> timezone or tzname or related.

Hmm, I just tried Robert's test program on a DLL from current CVS:

$ ./tzset.exe 
std:WEST
dst:WEDT

and it works regardless if $TZ is set or not.  Could you debug this further?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: tcsh and chere-0.3-1 (fwd)

[Dave]

>> From: Andrew Grimm
>> 
>> On Wed, Oct 13, 2004 at 07:02:13PM -0400, Christopher Faylor wrote:
>> >Actually, All shells which support -l seem to cd to the home directory.
>> >I'm not sure what the -l adds to the above since the above code just
>> >calls the shell again after cd'ing to the directory.
>> 
>> I think the purpose of that is to ensure that ~/.login (or whatever) gets
>> called to completely set up the shell's environment.  Normal shells don't
>> read in that file because they are assumed to inherit their environment
>> from the base login shell.

> cgf said:
> Aha.  I didn't know that this was something we were doing.

Yup. The -l makes sure the shell started from explorer reads the startup scripts
and sets its environment correctly.

> If that is the case then maybe we could get some coordination going and
> set a CYGWIN_CD_HERE environment variable or something and just have the
> login shell cd to the right directory automatically with the help of
> the /etc/* scripts.

This would work. Except where the user specific rc scripts expect to be in the
users home directory (which I think is buggy, but possible).

>> >It almost seems like you could just use ash to invoke the real shell in
>> >all cases.  That would be faster.
>> 
>> True, you could use any shell as the base login shell which exec's the
>> desired shell.  That has the benefit of always working.  However, that
>> approach will bypass the login-shell-specific config files for other shell
>> types.  For instance, "ash -" will load env vars from ~/.profile rather
>> than ~/.login which a tcsh user is unlikely to have set up to produce
>> identical results (for instance I like to put MANPATH in ~/.login but I
>> don't have a ~/.profile at all).  This would result in a "chere" shell
>> which will not behave quite like the user's regular shells, which are
>> spawned from a login shell of the same flavor.
>> 
>> Actually that appears to be another bug in the script:  chere should
>> invoke ash as "ash -" to start an ash login shell (I haven't tested this
>> though).

I suspected both these shells might have problems. Was just hoping they had some
undocumented behaviour (since the other shells are consistent). I also wasn't
sure if the login behaviour did anything extra, so didn't just ruin the startup
scripts.

>> I think with most login shells the "cd $HOME" behavior is due to the way
>> the scripts are written in /etc (for example Cygwin's /etc/csh.login).
>> That is probably a good thing to have in the script, but it presents a
>> difficulty for this unusual application.

Thanks for the feedback.

I'm not sure that having a non-login shell run the startup scripts is the
correct thing to do. Mainly because you end up with a nasty command line
checking whether files are available. And this won't work with the passwd
runtime evaluation (is anyone using this? Or wanting to?) without even more
nasty quoting.

Having an env variable set for a startup script to cd to seems a nicer way to
handle things. Just not sure if this will break user specific and non-login
scripts. Should probably also enclose any cd behaviour in an "if [ `uname` ==
CYGWIN* ]" for people who like to share scripts between systems.

Do the tcsh/ash maintainers have any suggestions/preferences?

Does anyone know of a way to get a `-` at the start of $0? I believe this will
force all the shells to start as login shells and is the most generic solution.


Dave.

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

RE: chere problem with network-share handling ?

[Dave]

Haro said:
> I seem to have problem with network-share path handling with chere.
> When I start 'Zsh Here' from Explorer on network-share like
> "//Server/share/dir/path", I get following error message on the first
> line of zsh window:
>  cd: no such file or directory: /opt/Server/share/dir/path
>
> Does chere not support network-share yet?

I've never tried it, but I would expect it to work.

> d: 7518416   6715592802824  90% /opt

Slightly concerned why zsh is trying to get to your d: instead of the share.
Windows should be passing "//Server/share/dir/path" as %L (i.e. without the
/opt). Is this a typo or what you are actually seeing?

I'll have a go and see if I can reproduce the problem. In the meantime, if you
really need this, try and mount the network share as a drive. That can be found
in Tools/Map Network drive... in Explorer; don't know what that is in Japanese
though :).

Thanks for the report.

Dave.



__
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now. 
http://messenger.yahoo.com

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

Re: libtool / assembler problem with -DPIC

[Gerrit P. Haase]

Reini wrote:

> Charles Wilson schrieb:
>> Gerrit P. Haase wrote:
>>> With GNU as PIC is not an noop, when -DPIC is used to invoke gas the
>>> generated assembly is broken.  I saw this problem with a
>>> reautoconfiscated version of GMP.  This may be unusual, but there was
>>> libtool used to invoke gas.
>>>
>>> While -DPIC is a noop for usual compilation, it is harmful when used
>>> as gas flag to compile assembly, I suggest to remove it entirely when
>>> target is cygwin. Change would be in libtool.m4 line 4971 ff in
>>> libtool-1.5.10.
>>>
>>> Alternative: don't pass flag through when gas is called.
>> 
>> I don't see anywhere that "-DPIC" is ever invoked on cygwin.  Please 
>> send a patch to libtool.m4 that fixes the problem for you.

> The problem is when a user (or makefile) adds this -DPIC, which does no
> harm usually. Gerrit thought that it might be clever to strip it on 
> cygwin when gas is involved, since this does harm.
> Or maybe emit a warning to fix the makefile for cygwin.
> (Gerrit: Really -DPIC, not -fPIC?)

No.  Libtool adds this flag regardless what in your Makefile.am is.



Gerrit
-- 
=^..^= http://nyckelpiga.de/donate.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: Ping: Cygwin libtool / assembler problem with -DPIC

[Gerrit P. Haase]

Hi Charles,


> Libtool gives -DPIC -DDLL_EXPORT to indicate a cygwin or mingw DLL. We
> undefine PIC since we don't need to be position independent in this
> case and definitely don't want the ELF style _GLOBAL_OFFSET_TABLE_ etc.

> ifdef(`DLL_EXPORT',`undefine(`PIC')')

> Now, on *mingw*, we do indeed (up to now) define both DLL_EXPORT and PIC
> which compiling .lo's.  However, for cygwin, we no longer define 
> DLL_EXPORT, but continue to define PIC.  So the little rule above is 
> ineffective, and gmp ends up compiling the wrong assembler code.

Now I see, thanks.


> Now, I'd call this a case -- maybe -- of gmp assuming too much about the
> internals of libtool.  OTOH, libtool emitting -Dcodes means that those
> codes are supposed to be USED, right?

> I'm not convinced that it is a BAD thing to emit a -Dcode indicating 
> when a source file is being compiled for a shared object, even when just
> considering cygwin alone.  I can see cases where one might want to 
> implement something differently within a shared lib vs. a static lib. 
> If we unilaterally remove -DPIC on cygwin, we can never do anything like
> that.

I think it is a bad thing to add -D flags unconditionally and for sure
it is a bad thing if it is a noop.


> What gmp is doing is using the fact that "-DDLL_EXPORT" is defined to 
> indicate that the target platform is cygwin or mingw.  It does this 
> because gmp "knows" that it DOESN'T want to use the special PIC-guarded
> code on cygwin|mingw, *even* when building .lo's on those platforms. 
> (The fun part is gpm-h.in specifically says libtool's DLL_EXPORT is NOT
> used.  Errr...bzzt.  Yes it is!)

> However, DLL_EXPORT is an unreliable platform indicator, as we've 
> obviously seen here; it's only true when building .lo's on mingw now. 
> But I don't think just turning -DDLL_EXPORT back on for cygwin is the 
> answer, either.  (I don't really remember when this stopped being on for
> cygwin, but whatever).

The answer should be to not define -D flags which do nothing, let the
user decide which -D flags she wants, these are CFLAGS after all.


> I think gmp's x86-defs.m4 needs to use $host (or whatever analogue it 
> can conjure up) to determine when the platform is cygwin or mingw, and
> use THAT to decide when to undefine PIC.

> Gerrit, if you change the line in x86-defs.m4 to ALWAYS undefine PIC, 
> does that fix your build problem even when libtool still -DPIC's?  If 
> so, then certainly we can come up with a better way for gmp's config.m4
> machinery to determine its target platform, right?

Should do it, yes, however, why not undefine it in libtool, I still
don't see the reason why it is used at all.

And yes, GMP should not care that much about its own machinery, if there
is a flag in libtool that prevents generating working code then
obviously the used tool is broken and should be fixed, defining these
workarounds because buildtools are broken is not the way to go.  Because
Haible's packages nearly always include hacked versions of libtool or m4
macros it is always a pita to apply newer libtool versions, i.e. simply
doing autoreconf fails in most of the cases (CLN, gettext, libiconv,
GMP, ...choose your favourite Haible package...).

I don't whine if all works as expected, but in case of GMP it is even
impossible to build the vanilla source with the C++ lib included.


Gerrit
-- 
=^..^= http://nyckelpiga.de/donate.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: tzset et al

[Gerrit P. Haase]

Corinna wrote:

> On Oct 14 11:50, Gerrit P. Haase wrote:
>> Hello,
>> 
>> it is a mess...
>> 
>> Whatever happend after this thread,
>> http://www.cygwin.com/ml/cygwin-patches/2001-q1/msg00248.html
>> it was not the result that it is working now, the simple testcase Robert
>> provided still (or again) doesn't work.  Even if I use _tzname instead
>> of tzname it prints out nothing.
>> 
>> What can I do?  It is annoying to get an error everytime a package uses
>> timezone or tzname or related.

> Hmm, I just tried Robert's test program on a DLL from current CVS:

> $ ./tzset.exe 
> std:WEST
> dst:WEDT

> and it works regardless if $TZ is set or not.  Could you debug this further?

No, I have no idea, it just don't work for me.

cygwin version: 1.5.10(0.116/4/2)


(gdb) break main
Breakpoint 1 at 0x40107e: file tztest.c, line 6.
(gdb) s
The program is not being run.
(gdb) run
Starting program: /tzset/tzset.exe 

Breakpoint 1, main () at tztest.c:6
6 tzset();
(gdb) s
7 printf("std:%s\ndst:%s\n",tzname[0],tzname[1]);
(gdb) 
8 return 0;
(gdb) 
9   }
(gdb) 
0x61005f54 in getprogname () from /usr/bin/cygwin1.dll
(gdb) 
Single stepping until exit from function getprogname, 
which has no line number information.
0x610d6cd0 in wmemset () from /usr/bin/cygwin1.dll
(gdb) 
Single stepping until exit from function wmemset, 
which has no line number information.
0x61004670 in getprogname () from /usr/bin/cygwin1.dll
(gdb) 
Single stepping until exit from function getprogname, 
which has no line number information.
0x610d6d5a in wmemset () from /usr/bin/cygwin1.dll
(gdb) 
Single stepping until exit from function wmemset, 
which has no line number information.
0x6101c530 in dlerror () from /usr/bin/cygwin1.dll
(gdb) 
Single stepping until exit from function dlerror, 
which has no line number information.
0x610d6d5a in wmemset () from /usr/bin/cygwin1.dll
(gdb) 
Single stepping until exit from function wmemset, 
which has no line number information.
0x610a3cd0 in cygwin1!__getreent () from /usr/bin/cygwin1.dll
(gdb) 
Single stepping until exit from function cygwin1!__getreent, 
which has no line number information.
0x610f08f0 in cygwin1!_alloca () from /usr/bin/cygwin1.dll
(gdb) 
Single stepping until exit from function cygwin1!_alloca, 
which has no line number information.
std:   
dst:   

Program exited normally.
(gdb) 

-- 
=^..^= http://nyckelpiga.de/donate.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: tzset et al

[Corinna Vinschen]

On Oct 14 13:17, Gerrit P. Haase wrote:
> Corinna wrote:
> > Hmm, I just tried Robert's test program on a DLL from current CVS:
> 
> > $ ./tzset.exe 
> > std:WEST
> > dst:WEDT
> 
> > and it works regardless if $TZ is set or not.  Could you debug this further?
> 
> No, I have no idea, it just don't work for me.
> 
> cygwin version: 1.5.10(0.116/4/2)

Did you try with a recent DLL?

> (gdb) break main
> Breakpoint 1 at 0x40107e: file tztest.c, line 6.
> (gdb) s
> The program is not being run.
> (gdb) run
> Starting program: /tzset/tzset.exe 
> 
> Breakpoint 1, main () at tztest.c:6
> 6 tzset();
> (gdb) s
> 7 printf("std:%s\ndst:%s\n",tzname[0],tzname[1]);
> (gdb) 
> 8 return 0;
> (gdb) 
> 9   }
> (gdb) 
> 0x61005f54 in getprogname () from /usr/bin/cygwin1.dll
> (gdb) 
> Single stepping until exit from function getprogname, 
> which has no line number information.
> 0x610d6cd0 in wmemset () from /usr/bin/cygwin1.dll

That's not helpful.  Don't you have a DLL which is not stripped?
Where you can set a breakpoint to tzset before stepping?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: chere problem with network-share handling ?

[haro]

From: Dave 
Date: Thu, 14 Oct 2004 03:58:21 -0700 (PDT)
::> I seem to have problem with network-share path handling with chere.
::> When I start 'Zsh Here' from Explorer on network-share like
::> "//Server/share/dir/path", I get following error message on the first
::> line of zsh window:
::>  cd: no such file or directory: /opt/Server/share/dir/path
::>
::> Does chere not support network-share yet?
::
::I've never tried it, but I would expect it to work.
::
::> d: 7518416   6715592802824  90% /opt
::
::Slightly concerned why zsh is trying to get to your d: instead of the share.
::Windows should be passing "//Server/share/dir/path" as %L (i.e. without the
::/opt). Is this a typo or what you are actually seeing?

Hi Dave,

I'm actually seeing the "/opt" with zsh. 
May be that, cygwin is install on the d: drive and something is
parsing it incorrectly.

I just tried the same path with bash and got the following error on the
first line:
/usr/bin/bash: line 1: cd: \Server\share\dire\path: No such file or directory

::I'll have a go and see if I can reproduce the problem. In the meantime, if you
::really need this, try and mount the network share as a drive. That can be found
::in Tools/Map Network drive... in Explorer; don't know what that is in Japanese
::though :).

I can write the name in Japanese for you, but I'm sure that you cannot
read them. ;)
Yap, assigning as drive does seem to work. :)

::Thanks for the report.

Thank you for responce,
 Haro 
=---
   _ _Munehiro (haro) Matsuda
 -|- /_\  |_|_|   Kubota Graphics Technology Inc.
 /|\ |_|  |_|_|   2-8-8 Shinjuku, Shinjuku-ku Tokyo 160-0022, Japan
  Tel: +81-3-3225-0767  Fax: +81-3-3225-0740
  Email: [EMAIL PROTECTED]

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

Re: chere problem with network-share handling ?

[Dave]

OK, this appears to be an issue with quote processing. Here is a session,
starting in a command prompt.

-
C:\>c:\cygwin\bin\bash -l -c "cd '\\minime\music'; exec /bin/bash"
/bin/bash: line 1: cd: \minime\music: No such file or directory

[EMAIL PROTECTED] ~
$ cd '\\minime\music'

[EMAIL PROTECTED] //minime/music
$ /bin/bash -l -c "cd '\\minime\music'; exec /bin/bash"
/bin/bash: line 1: cd: \minime\music: No such file or directory

[EMAIL PROTECTED] ~
$ cd "'\\minime\music'"
bash: cd: '\minime\music': No such file or directory

 end 
First command shows behaviour of the full command as I would expect it to be
evaluated from the shell menu. Response as reported.

Second command shows that the bash shell can process the cd command correctly.

Third command retries the full command from the bash shell, eliminating
cmd/windows evaluations.

Fourth command duplicates the double quoting used by the main command.

To me this indicates that double '\' within ''' and '"' quotes are not
preserved.


Enclosing  characters  in  single quotes preserves the literal value of
each character within the quotes.  A single quote may not occur between
single quotes, even when preceded by a backslash.

Enclosing  characters  in  double quotes preserves the literal value of
all characters within the quotes, with the exception of $,  `,  and  \.
The  characters  $  and  `  retain  their special meaning within double
quotes.  The backslash retains its special meaning only  when  followed
by one of the following characters: $, `, ", \, or .  A double
quote may be quoted within double quotes by preceding it with  a  back-
slash.


>From this I would expect the double '\' to be preserved since it is within
single quotes, whose special meaning is retained when within double quotes.

It seems the double quote rules are overriding the single quote rules within the
single quotes.

Am I reading this right?


Dave.



__
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

--
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: tzset et al

[Gerrit P. Haase]

Corinna wrote:

> On Oct 14 13:17, Gerrit P. Haase wrote:
>> Corinna wrote:
>> > Hmm, I just tried Robert's test program on a DLL from current CVS:
>> 
>> > $ ./tzset.exe 
>> > std:WEST
>> > dst:WEDT
>> 
>> > and it works regardless if $TZ is set or not.  Could you debug this further?
>> 
>> No, I have no idea, it just don't work for me.
>> 
>> cygwin version: 1.5.10(0.116/4/2)

> Did you try with a recent DLL?

1.5.11.

> That's not helpful.  Don't you have a DLL which is not stripped?

No, isn't available for download... And I have no time to build cygwin now.

It works ok at my NT4 server, it doesn't work at my W2K workstation and
it doesn't work at my XP notebook.

The difference is that I have defined TZ in the environment at this NT4
box and here not.  It also works here when I export TZ=... It seems that
I need TZ to be defined. 


SableVM specific:

The actual problem is that I get errors when compiling sablevm classpath
because of an undeclard identifier, time.h and sys/time.h are included
and tzname and timezone should be defined, however I'm getting an error.

Now I see that there is -ansi at the commandline and that is the
problem, tzname et al is guarded with !__STRICT_ANSI__ in time.h and
therefore it is not defined. 

Is tzname and timezone not ANSI?  Why is it used in sablevm then?  Or is
the Cygwin time.h wrong about this?


> Where you can set a breakpoint to tzset before stepping?

I need a debug version of cygwin1.dll.



Gerrit
-- 
=^..^= http://nyckelpiga.de/donate.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: gcc exception handling

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Peter Xiaochuan Huang
> Sent: 13 October 2004 18:51

> >   Are you using the correct command line options to
> > compile with exceptions?
> 
> I tried -mthreads that didn't fix it. What is the
> right compile flag?

  I believe -fexceptions is vital if you're using exceptions.  That should
be automatically the case for any C++ files you're compiling but if there
are plain old C files in your application as well they also need
-fexceptions when compiled.

> >   Do all functions have the correct throw specifiers
> > on their prototypes?
> 
> None of my functions has any throw specifier,
> which means throw possibly anything. Is that good
> enough ?

  I believe it should be.  C++ exceptions are not my strong point, however.

> > 1)  Keep trying to come up with a simple testcase?
> > 2)  Switch gdb into assembly code view and debug the
> > problem by seeing what
> > actual values are in registers, stack and memory and
> > what actual machine
> > code instructions are getting executed to cause the
> > problem?
> 
> I may have to try this if the compile flag you
> give to me doesn't fix the problem

  I fear you may have to.  Looking again at your original description of the
problem:

> > > It core dumps on the return statement in gdb. But
> > when
> > > I make a simplified test including only above
> > code,
> > > the core dump doesn't happen any more. My program
> > that
> > > gets core dumped links pthread and uses mutex.
> > > Actually the return statement should invoke stack
> > > unwinding that will do mutex locking and
> > unlocking.
> > > Though I don't know if that is related or not.

it seems likely to me that if you can't reduce it to a fairly simple
testcase, it could well indicate that there is some bug (perhaps a
threading-related race condition, or something else that might cause memory
corruption) in your code that is corrupting state and causing an error as
the stack is unwound.

cheers, 
  DaveK
-- 
Can't think of a witty .sigline today


--
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: vim problem with my install, y?

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Lane, Frank L
> Sent: 13 October 2004 22:47

> Thanks Chris: you nailed it.  TERM was nutc, whatever that's 
> supposed to be, 

  It's something done by those Rational Rose perverts[*]:

http://www.google.com/search?hl=en&q=TERM%3Dnutc

cheers, 
  DaveK
[*] http://cygwin.com/acronyms#3PP 
-- 
Can't think of a witty .sigline today
 



--
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: Setup failure: mount error

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of luke
> Sent: 14 October 2004 09:59

> > In other words, it appears to have nothing to do with 
> having run "mount"
> > from a network install of Cygwin.  (Since all files created 
> by Cygwin
> > and all registry entries were deleted, Cygwin stores no other
> > information on the system, and yet the problem persisted.)

> > I have scrubbed Windows, reformatted the drives, and am 
> re-installing 
> > W2K now.  I fully expect this to fail as well.

> Basically, that worked.  It appears that Cygwin made some change that
> persisted even after deleting all the Cygwin files and registry entries.

  ?!?!?!?  This seems highly improbable.  What else _could_ there be?  Maybe
something different in the environment vars between the two machines was
causing it?  Maybe some different software that was installed on the failing
machine was causing dll hell or something?

  Ever heard of InCtrl5?  Dead useful app, see if you can find a download of
it on the web somewhere.  Could be very useful if a situation like this ever
arises again: it takes a snapshot of your entire system (files and
registry), then you run an installer, then you run InCtrl5 again and it
takes another snapshot and compares the two, so you can see exactly all the
changes that an installer has made to your system.

cheers, 
  DaveK
-- 
Can't think of a witty .sigline today


--
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: tzset et al

[Corinna Vinschen]

On Oct 14 14:27, Gerrit P. Haase wrote:
> Now I see that there is -ansi at the commandline and that is the
> problem, tzname et al is guarded with !__STRICT_ANSI__ in time.h and
> therefore it is not defined. 
> 
> Is tzname and timezone not ANSI?  Why is it used in sablevm then?  Or is
> the Cygwin time.h wrong about this?

SUSv3 marks tzname with a [CX], "Extension to the ISO C standard"
so, if I understand that right, it's not *strict* ANSI functionality.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: tzset et al

[Corinna Vinschen]

On Oct 14 14:27, Gerrit P. Haase wrote:
> Is tzname and timezone not ANSI?  Why is it used in sablevm then?  Or is
> the Cygwin time.h wrong about this?


Btw., time.h is newlib, not Cygwin.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: vim problem with my install, y?

[Danilo Turina]

Notice that the TERM variable is set (and also a "strange" version of sh 
installed) by Rational Rose only you choose a specific sub-package of 
Rose (maybe the Model Integrator), if don't install that package, TERM 
var is not set by Rose setup and the "strange" sh is not installed.

Ciao,
Danilo
Dave Korn wrote:
-Original Message-
From: cygwin-owner On Behalf Of Lane, Frank L
Sent: 13 October 2004 22:47

Thanks Chris: you nailed it.  TERM was nutc, whatever that's 
supposed to be, 

  It's something done by those Rational Rose perverts[*]:
http://www.google.com/search?hl=en&q=TERM%3Dnutc
cheers, 
  DaveK
[*] http://cygwin.com/acronyms#3PP 

--
--
Danilo Turina
Alcatel Optics OND Network Management
Rieti (Italy) - Phone: +39 0746 600332
--
3 anni 6 mesi 5 giorni 6 ore 8 minuti 43 secondi
--
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: Virtual (meta-) packages

[Christopher Faylor]

On Thu, Oct 14, 2004 at 09:08:04AM +0300, Jani Tiainen wrote:
>Could setup be extended (or even used in current form) to have virtual 
>packages that could install some basic tools as a whole working 
>combination, like X11 server? More or less like it is done in Debian (my 
>favourite Linux distribution)
>
>I recently wondered where my X11 start scripts went and found out that 
>I've missing startup-scripts. It would be more convenient to have 
>virtual package that installs "all" for that first time so you don't 
>have to know what you're installing... It would be helpful.

If you want all of the X packages then click on the "Default" next to
the X11 category in "Select Packages" dialog until it says "Install".

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

line-drawing

[towo]

According to a recent mailing on [EMAIL PROTECTED], 
the alternate character set terminal controls (fixed wrt. the 
currently buggy terminfo entry) are supposed to work and to 
provide line drawing (like with VT100 graphics characters).
Is that true?
What do you see if you send "\[[11mn" to the terminal 
(where the \[ is of course an escape, properly escaped :) - 
I see only an "n" here, not a graphics symbol.

Thomas Wolff

--
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: chere problem with network-share handling ?

[Christopher Faylor]

On Thu, Oct 14, 2004 at 05:08:07AM -0700, Dave wrote:
>OK, this appears to be an issue with quote processing. Here is a session,
>starting in a command prompt.
>
>-
>C:\>c:\cygwin\bin\bash -l -c "cd '\\minime\music'; exec /bin/bash"
>/bin/bash: line 1: cd: \minime\music: No such file or directory
>
>[EMAIL PROTECTED] ~
>$ cd '\\minime\music'
>
>[EMAIL PROTECTED] //minime/music
>$ /bin/bash -l -c "cd '\\minime\music'; exec /bin/bash"
>/bin/bash: line 1: cd: \minime\music: No such file or directory
>
>[EMAIL PROTECTED] ~
>$ cd "'\\minime\music'"
>bash: cd: '\minime\music': No such file or directory
>
> end 
>First command shows behaviour of the full command as I would expect it to be
>evaluated from the shell menu. Response as reported.
>
>Second command shows that the bash shell can process the cd command correctly.
>
>Third command retries the full command from the bash shell, eliminating
>cmd/windows evaluations.
>
>Fourth command duplicates the double quoting used by the main command.
>
>To me this indicates that double '\' within ''' and '"' quotes are not
>preserved.
>
>
>Enclosing  characters  in  single quotes preserves the literal value of
>each character within the quotes.  A single quote may not occur between
>single quotes, even when preceded by a backslash.
>
>Enclosing  characters  in  double quotes preserves the literal value of
>all characters within the quotes, with the exception of $,  `,  and  \.
>The  characters  $  and  `  retain  their special meaning within double
>quotes.  The backslash retains its special meaning only  when  followed
>by one of the following characters: $, `, ", \, or .  A double
>quote may be quoted within double quotes by preceding it with  a  back-
>slash.
>
>
>From this I would expect the double '\' to be preserved since it is within
>single quotes, whose special meaning is retained when within double quotes.
>
>It seems the double quote rules are overriding the single quote rules within the
>single quotes.
>
>Am I reading this right?

Yes.  Once you quote the outer thing with the "", the backslash interpolation
is done according to "" rules.

I guess I haven't been paying close attention.  Why are the slashes
getting changed to backslashes?  That's not right.  It should be using cygwin
paths.

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: Virtual (meta-) packages

[Jani Tiainen]

Christopher Faylor wrote:
On Thu, Oct 14, 2004 at 09:08:04AM +0300, Jani Tiainen wrote:
Could setup be extended (or even used in current form) to have virtual 
packages that could install some basic tools as a whole working 
combination, like X11 server? More or less like it is done in Debian (my 
favourite Linux distribution)

I recently wondered where my X11 start scripts went and found out that 
I've missing startup-scripts. It would be more convenient to have 
virtual package that installs "all" for that first time so you don't 
have to know what you're installing... It would be helpful.

If you want all of the X packages then click on the "Default" next to
the X11 category in "Select Packages" dialog until it says "Install".
Not all, but working set. With Debian there is lot's of virtual packages 
that works for great startpoint for different jobs. They in most cases 
install set that will work or help to make bigger task to work. Like 
X11, basic C-developement tools, gnome, kde etc. environment

Basically this works now, only thing is to ensure that setup.exe can 
accept packages that don't install themselves but instead they just 
pickup other packages for installation.

Would be more convenient for me, and I quess that for someone else too...
--
Jani Tiainen
--
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: cygwin/x symantec antivirus conflict (fixed in snapshot?)

[Owen Rees]

--On 11 October 2004 00:06 -0400 Christopher Faylor 
<[EMAIL PROTECTED]> wrote:

So, I'd appreciate reports on the latest snapshot.  Does it fix any
problems?  Cause any problems?  No change?
I have XP Pro and Symantec AV - the 20041010 snapshot fixes the slowness I 
was having with emacs/X locally and X forwarded over SSH, and with no 
problems observed so far. The severe performance problems appeared some 
time in August IIRC, and my first impression is that the performance is now 
better than before the problems.

Regards,
Owen Rees <[EMAIL PROTECTED]>
Hewlett Packard Laboratories, Bristol, UK
tel: +44 117 312 9439 fax: +44 117 312 9153
--
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: proftpd in cygwin on win2k3

[Jason Tishler]

Rob,

Please post instead of sending private email.

On Thu, Oct 14, 2004 at 09:16:42AM -0400, Robert St.Denis wrote:
> I seem to be getting that classic privs_relinquish error.  I tried the
> User cygwin_server thing but then it wouldnt start up at all ... any
> ideas ?

I would follow the Windows 2003 suggestion in the Cygwin OpenSSH README
file:

/usr/share/doc/cygwin/openssh.README

Note I don't have access to a Windows 2003 machine, so I can't try to
debug this up myself.

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/

Problems installing PRC-TOOLS

[hewardt]

Hi All,

I've recently been trying to get started with Palm development but got stuck fairly 
early on :) The problem I am encountering is that of donwloading and installing the 
prc-tools package as described in the install document on cygwin.com. I keep getting: 
Download Incomplete error message for the prc-tools packages. More specifically:

1. I choose prc-tools.sourceforge.net/install as a download site
2. Choose the prc-tools packages and 'install'
3. The error (Download Incomplete) shows up. Note that it appears to be reading a few 
packages before this error is displayed.

I've tried de-selecting one or more of the prc-tools packages but still get the same 
error. Note that it does not happen with the other packages. Initially, I downloaded 
and installed only the default cygwin package and it worked without problems. 

Any help greatly appreciated.

--
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: non-interactive cygwin setup

[Igor Pechtchanski]

On Thu, 14 Oct 2004, Gary R. Van Sickle wrote:

> [snip]
> > >I thought if a GUI app called printf it generally caused a console to
> > >be opened for it.  Maybe that's only with msvcrt.  In any case, the
> > >fact is that it is being run from a cmdline and so it certainly can
> > >communicate with the console.  The presence of command-line options
> > >in argc/argv could be taken as a fairly strong hint that it was being
> > >run from a shell rather than an icon.  And there's always "isatty
> > >(1)" if you really really want to be sure.
> >
> > This is a windows limitation.  GUI apps (apps created with
> > -mwindows) can't send output to or receive input from the
> > console.  Of course, a GUI can interpret command line
> > information.  It just cannot send output to the console that
> > started it.
> >
> > You could use AllocConsole to create a separate console which
> > the GUI could then use, however.
>
> Here's a maybe-less-icky way to do it.  Have two exes, one "setup.exe" which
> is a 100% command-line program that normally just spawns "winsetup.exe", the
> current GUI setup, and goes away.  Give it "--help", and it prints help in
> the regular command-line way and exits.  Yeah, two exes, but worse tragedies
> have happened.

Well, running the command-line program will pop up a console window if
it's not running from a console already.  How's that different from just
using AllocConsole in the GUI version?  In fact, isn't this what MSVCRT
does under the covers anyway?
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!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

--
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: non-interactive cygwin setup

[Igor Pechtchanski]

On Thu, 14 Oct 2004, Robert Pendell wrote:

> Well there are ways to make a console/gui hybrid application (or at
> least I read that it could be done) but there are a few tricks that
> you have to pull.  It would be invisible to the end-user in the end
> though.

];->  ];->

> On Thu, 14 Oct 2004 01:12:20 -0500, Gary R. Van Sickle <[EMAIL PROTECTED]> wrote:

Oh, and .  Thanks.
Igor

> > [snip]
> > > >I thought if a GUI app called printf it generally caused a console
> > > >to be opened for it.  Maybe that's only with msvcrt.  In any case,
> > > >the fact is that it is being run from a cmdline and so it certainly
> > > >can communicate with the console.  The presence of command-line
> > > >options in argc/argv could be taken as a fairly strong hint that it
> > > >was being run from a shell rather than an icon.  And there's always
> > > >"isatty (1)" if you really really want to be sure.
> > >
> > > This is a windows limitation.  GUI apps (apps created with
> > > -mwindows) can't send output to or receive input from the
> > > console.  Of course, a GUI can interpret command line
> > > information.  It just cannot send output to the console that
> > > started it.
> > >
> > > You could use AllocConsole to create a separate console which
> > > the GUI could then use, however.
> >
> > Here's a maybe-less-icky way to do it.  Have two exes, one "setup.exe"
> > which is a 100% command-line program that normally just spawns
> > "winsetup.exe", the current GUI setup, and goes away.  Give it
> > "--help", and it prints help in the regular command-line way and
> > exits.  Yeah, two exes, but worse tragedies have happened.
> > --
> > Gary R. Van Sickle

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

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

--
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: Virtual (meta-) packages

[Igor Pechtchanski]

On Thu, 14 Oct 2004, Jani Tiainen wrote:

> Christopher Faylor wrote:
> > On Thu, Oct 14, 2004 at 09:08:04AM +0300, Jani Tiainen wrote:
> >
> > > Could setup be extended (or even used in current form) to have virtual
> > > packages that could install some basic tools as a whole working
> > > combination, like X11 server? More or less like it is done in Debian (my
> > > favourite Linux distribution)
> > >
> > > I recently wondered where my X11 start scripts went and found out that
> > > I've missing startup-scripts. It would be more convenient to have virtual
> > > package that installs "all" for that first time so you don't have to know
> > > what you're installing... It would be helpful.

I believe I've suggested this before -- search the list archives for
"installation profiles" or smth.

> > If you want all of the X packages then click on the "Default" next to
> > the X11 category in "Select Packages" dialog until it says "Install".
>
> Not all, but working set. With Debian there is lot's of virtual packages that
> works for great startpoint for different jobs. They in most cases install set
> that will work or help to make bigger task to work. Like X11, basic
> C-developement tools, gnome, kde etc. environment
>
> Basically this works now, only thing is to ensure that setup.exe can accept
> packages that don't install themselves but instead they just pickup other
> packages for installation.
>
> Would be more convenient for me, and I quess that for someone else too...

Well, you can always use dummy (empty) packages with the appropriate
"requires:" lines in setup.hints.
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!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

--
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: tcsh and chere-0.3-1 (fwd)

[Igor Pechtchanski]

On Thu, 14 Oct 2004, Dave wrote:

> [snip]
> > If that is the case then maybe we could get some coordination going and
> > set a CYGWIN_CD_HERE environment variable or something and just have the
> > login shell cd to the right directory automatically with the help of
> > the /etc/* scripts.
>
> This would work. Except where the user specific rc scripts expect to be
> in the users home directory (which I think is buggy, but possible).

Huh?  Why is this buggy?  Most shells will look in $HOME for the rc
scripts.  FWIW, you don't have to actually *cd* to $HOME for this.

> >> >It almost seems like you could just use ash to invoke the real shell
> >> >in all cases.  That would be faster.
> >>
> >> True, you could use any shell as the base login shell which exec's
> >> the desired shell.  That has the benefit of always working.
> >> However, that approach will bypass the login-shell-specific config
> >> files for other shell types.  For instance, "ash -" will load env
> >> vars from ~/.profile rather than ~/.login which a tcsh user is
> >> unlikely to have set up to produce identical results (for instance I
> >> like to put MANPATH in ~/.login but I don't have a ~/.profile at
> >> all).  This would result in a "chere" shell which will not behave
> >> quite like the user's regular shells, which are spawned from a login
> >> shell of the same flavor.
> >>
> >> Actually that appears to be another bug in the script:  chere should
> >> invoke ash as "ash -" to start an ash login shell (I haven't tested
> >> this though).
>
> I suspected both these shells might have problems. Was just hoping they
> had some undocumented behaviour (since the other shells are consistent).
> I also wasn't sure if the login behaviour did anything extra, so didn't
> just ruin the startup scripts.

Well, I think the base-files maintainer would be happy to coordinate on
adding an extra variable check to /etc/profile so that it doesn't cd to
$HOME...

> >> I think with most login shells the "cd $HOME" behavior is due to the way
> >> the scripts are written in /etc (for example Cygwin's /etc/csh.login).
> >> That is probably a good thing to have in the script, but it presents a
> >> difficulty for this unusual application.
>
> Thanks for the feedback.
>
> I'm not sure that having a non-login shell run the startup scripts is
> the correct thing to do. Mainly because you end up with a nasty command
> line checking whether files are available. And this won't work with the
> passwd runtime evaluation (is anyone using this? Or wanting to?) without
> even more nasty quoting.

It would certainly *look* nasty.

> Having an env variable set for a startup script to cd to seems a nicer
> way to handle things.

I agree.

> Just not sure if this will break user specific and non-login scripts.
> Should probably also enclose any cd behaviour in an "if [ `uname` ==
> CYGWIN* ]" for people who like to share scripts between systems.

Heh?  Just make the variable name strange enough to avoid accidental
clashes...

> Do the tcsh/ash maintainers have any suggestions/preferences?
>
> Does anyone know of a way to get a `-` at the start of $0? I believe
> this will force all the shells to start as login shells and is the most
> generic solution.

Sure.  'bash -c "exec -l $PROG $ARGS"'. :-)
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!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

--
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: Problems installing PRC-TOOLS

[Christopher Faylor]

On Thu, Oct 14, 2004 at 04:27:37PM +, [EMAIL PROTECTED] wrote:
>I've recently been trying to get started with Palm development but got
>stuck fairly early on :) The problem I am encountering is that of
>donwloading and installing the prc-tools package as described in the
>install document on cygwin.com.  I keep getting: Download Incomplete
>error message for the prc-tools packages.  More specifically:
>
>1. I choose prc-tools.sourceforge.net/install as a download site
>2. Choose the prc-tools packages and 'install'
>3. The error (Download Incomplete) shows up. Note that it appears to
>   be reading a few packages before this error is displayed.
>
>I've tried de-selecting one or more of the prc-tools packages but still
>get the same error.  Note that it does not happen with the other
>packages.  Initially, I downloaded and installed only the default
>cygwin package and it worked without problems.
>
>Any help greatly appreciated.

prc-tools is not a cygwin package.  You are getting your instructions
about installing from another site entirely.  Surely there is a mailing
list devoted to prc-tools which would be able to field questions about
their package.

--
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: tcsh and chere-0.3-1

[Andrew Grimm]

Igor Pechtchanski said:
> > Does anyone know of a way to get a `-` at the start of $0? I believe
> > this will force all the shells to start as login shells and is the
> > most generic solution.
>
> Sure.  'bash -c "exec -l $PROG $ARGS"'. :-)

Ya beat me to it :)  Although, in the current design, this would make a
bash shell call a login shell call a normal shell (for the cd) which is a
bit of a quoting nightmare.

You could make a support script (/bin/shere) that did somehting like this:

#!/bin/bash
# shere: run login shell arg1 in directory arg2
[ -x "$1" -a -d "$2" ] || exit 1;
dir=$(/bin/cygpath -u "$2")
exec -l $1 -c "cd \"$dir\"; exec $1"

Then the command you send would turn into something as simple as:

C:\cygwin\bin\rxvt.exe -e /bin/shere /bin/tcsh.exe '%L'

If you hate the idea of making another script (I do too) you could turn
chere into a bash script, and add an arg like "chere -e  "
which runs the above.  Then chere would do its work by registering a call
to chere.

-Andy


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

Distributing Cygwin-based software

[Soeren Nils Kuklau]

Hi,
we're working on a cross-platform server daemon, and on the Windows 
side, we have chosen to use Cygwin for POSIX compatibility reasons. We 
have run into several issues on the way:

1) We've looked at `cygrunsrv', and it appears to be a convenient tool 
for setting our daemon up as an NT service.  For people that do not have 
Cygwin installed, can we just distribute `cygrunsrv' as stand-alone tool 
to go inside our daemon's working directory?

2) Similarly, what about distributing `cygwin1.dll' - I am aware of the 
"dllpath hell" problem this causes; what is the preferred option here?

3) Cross-posting from the other mail: I also found rather little 
documentation on `cygrunsrv'. The bundled README file comprehensively 
lists possible arguments, but appears to assume that the daemon to be 
run is inside the Cygwin root directory (such as C:\Cygwin), whereas we 
believe it would make more sense to distribute our package for 
installation inside Windows' Program Files folder. Does `cygrunsrv' 
understand Windows-like paths, or can we rely on a `/cygdrive/c/Program\ 
Files/'-like path structure?

4) Finally, a coding issue: We use SHA1 hashing for passwords. During 
linking, we get:

obj/alstring.o(.text+0x316):alstring.c: undefined reference to `_SHA1'
LDFLAGS are: -lpthread -lcrypto
Are we missing a specific Cygwin package?
Any help would be greatly appreciated.
TIA,
--
Soeren 'Chucker' Kuklau
--
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: Distributing cygwin-based software

[Christopher Faylor]

On Thu, Oct 14, 2004 at 09:32:16PM +0200, Soeren Nils Kuklau wrote:
>Hi,
>
>we're working on a cross-platform server daemon, and on the Windows 
>side, we have chosen to use Cygwin for POSIX compatibility reasons. We 
>have run into several issues on the way:
>
>1) We've looked at `cygrunsrv', and it appears to be a convenient tool 
>for setting our daemon up as an NT service.  For people that do not have 
>Cygwin installed, can we just distribute `cygrunsrv' as stand-alone tool 
>to go inside our daemon's working directory?

Again, as was answered in the cygwin-licensing mailing list, the tool is
distributed under the GPL.  I don't understand why you are asking this
question again.  Comply with the GPL and you can do whatever you want
with the code.

>2) Similarly, what about distributing `cygwin1.dll' - I am aware of the 
>"dllpath hell" problem this causes; what is the preferred option here?

The preferred option is not to distribute the DLL but to point to the
cygwin web site and tell people to install it from there.  This mailing
list is primarily for discussing the cygwin distribution, not for
talking about ways not to do things with the cygwin distribution.

However, to answer your question, if you are really intent on going down
this path, you should do rigorous checking to make sure that there is no
conflicting version of cygwin on the system.  Look for a cygwin DLL in
the path and in the system directories.  You can search for strings
beginning with '%% ' in the cygwin DLL to get version information or you
can grab the version information from the DLL headers (you'll undoubtedly
have to do research to figure out how to do the latter).

And, make sure that the user knows that your users know that they
shouldn't be coming to the cygwin mailing list if they have problems
since you're distribution is != the cygwin distribution.

>3) Cross-posting from the other mail: I also found rather little 
>documentation on `cygrunsrv'. The bundled README file comprehensively 
>lists possible arguments, but appears to assume that the daemon to be 
>run is inside the Cygwin root directory (such as C:\Cygwin), whereas we 
>believe it would make more sense to distribute our package for 
>installation inside Windows' Program Files folder. Does `cygrunsrv' 
>understand Windows-like paths, or can we rely on a `/cygdrive/c/Program\ 
>Files/'-like path structure?

Isn't this question simply answered by just trying cygrunsrv with
windows paths and seeing if it works?  If not, then maybe the source
code would be instructive.

FWIW, you shouldn't expect to find much documentation in any cygwin
package for doing things in a way that is counter to common practice in
the cygwin distribution.  That is very much not something that we are
interested in supporting.

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: Problems installing PRC-TOOLS

[hewardt]

The specific problem seemed more related to the cygwin install app rather than the 
individual packages, hence my question on this mailing list. I will go ahead and try 
to find out more information elsewhere.

Thanks for the response.


> On Thu, Oct 14, 2004 at 04:27:37PM +, [EMAIL PROTECTED] wrote:
> >I've recently been trying to get started with Palm development but got
> >stuck fairly early on :) The problem I am encountering is that of
> >donwloading and installing the prc-tools package as described in the
> >install document on cygwin.com.  I keep getting: Download Incomplete
> >error message for the prc-tools packages.  More specifically:
> >
> >1. I choose prc-tools.sourceforge.net/install as a download site
> >2. Choose the prc-tools packages and 'install'
> >3. The error (Download Incomplete) shows up. Note that it appears to
> >   be reading a few packages before this error is displayed.
> >
> >I've tried de-selecting one or more of the prc-tools packages but still
> >get the same error.  Note that it does not happen with the other
> >packages.  Initially, I downloaded and installed only the default
> >cygwin package and it worked without problems.
> >
> >Any help greatly appreciated.
> 
> prc-tools is not a cygwin package.  You are getting your instructions
> about installing from another site entirely.  Surely there is a mailing
> list devoted to prc-tools which would be able to field questions about
> their package.
> 
> --
> 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/
> 

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

[bug] fileutils: ln --target-directory with just one target fails - cygcheck-svr.out [1/1]

[Andrew Schulman]

$ ls -l dir1
$ ln -fs --target-directory=dir1 ../test.txt
ln: `dir1/.': cannot overwrite directory
$ ls -l dir1
total 0
lrwxrwxrwx1 ASchulma None   11 Oct 14 16:42 test.txt -> 
../test.txt

What seems to happen here is that when ln --target-directory is given 
only one target file (here test.txt), it works on the first one, then 
'sees' . as a second target.

Who is the Cygwin maintainer of fileutils?  I can't find any Cygwin doc 
files for it.  Should I submit this bug upstream?

Andrew.


cygcheck-svr.out
Description: Binary data
--
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: [bug] fileutils: ln --target-directory with just one target fails - cygcheck-svr.out [1/1]

[Christopher Faylor]

On Thu, Oct 14, 2004 at 04:43:56PM -0400, Andrew Schulman wrote:
>$ ls -l dir1
>$ ln -fs --target-directory=dir1 ../test.txt
>ln: `dir1/.': cannot overwrite directory
>$ ls -l dir1
>total 0
>lrwxrwxrwx1 ASchulma None   11 Oct 14 16:42 test.txt -> 
>../test.txt
>
>What seems to happen here is that when ln --target-directory is given 
>only one target file (here test.txt), it works on the first one, then 
>'sees' . as a second target.
>
>Who is the Cygwin maintainer of fileutils?  I can't find any Cygwin doc 
>files for it.  Should I submit this bug upstream?

http://sources.redhat.com/ml/cygwin/2004-10/msg00513.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: tcsh and chere-0.3-1

[Dave]

--- Andrew Grimm <[EMAIL PROTECTED]> wrote:
> Igor Pechtchanski said:
> > > Does anyone know of a way to get a `-` at the start of $0? I believe
> > > this will force all the shells to start as login shells and is the
> > > most generic solution.
> >
> > Sure.  'bash -c "exec -l $PROG $ARGS"'. :-)
> 
> Ya beat me to it :)  Although, in the current design, this would make a
> bash shell call a login shell call a normal shell (for the cd) which is a
> bit of a quoting nightmare.
> 
> You could make a support script (/bin/shere) that did somehting like this:

Thanks guys. My brains been turned to slush reading all the different shell man
pages (as you may have figured from my last few emails).

It turns out that on windows 2k, if you remove the cd $HOME from the appropriate
login script, you can just `/bin/tcsh -l`. Since 2k puts you in the appropriate
path anyway.

Nice. It even works with network paths.

Can anyone confirm this works on 9x, NT and XP?

If it does work on all platforms, it's my preferred route. It'll still need:
an env var for the startup scripts to check
a shell script (which may be chere) to set the variable

And will mean you have a spare sh for every term opened in this manner.


Dave.

i.e. comment out the cd $HOME line, run something like:
regtool set /HKLM/Directory/shell/cygwin_tcsh/command/ "c:\cygwin\bin\rxvt -e
/bin/tcsh -l"

Or just edit your registry
and give the menu a spin.



__
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

--
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: Setup failure: mount error

[luke]

Dave Korn replied to:
Basically, that worked.  It appears that Cygwin made some change that
persisted even after deleting all the Cygwin files and registry entries.

  ?!?!?!?  This seems highly improbable.  What else _could_ there be?  Maybe
something different in the environment vars between the two machines was
causing it?  Maybe some different software that was installed on the failing
machine was causing dll hell or something?
  Ever heard of InCtrl5?  Dead useful app, see if you can find a download of
it on the web somewhere.  Could be very useful if a situation like this ever
arises again: it takes a snapshot of your entire system (files and
registry), then you run an installer, then you run InCtrl5 again and it
takes another snapshot and compares the two, so you can see exactly all the
changes that an installer has made to your system.
cheers, 
  DaveK
All this happened on a PC with no OS installed until I installed W2K.
The purpose was to test Cygwin.
So the very next thing (the only thing) I did was (try to) install
Cygwin.
But thinking about it last night, there was one other difference: I
created a file c:\cyg.bat that simply set PATH to include the directory
where I keep various helper Cygwin scripts (like the .bat to drive the
install via setup).
Perhaps that somehow got run by setup or by one of the post-install
scripts instead of some (internal) Cygwin command called "cyg"?
I can test both theories by trying to reproduce the problem.
luke
--
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: cygwin & openssh(d) & login without password

[Joshua Daniel Franklin]

On Wed, 13 Oct 2004 10:15:52 -0400, Christopher Faylor wrote:
> >
> 
> Did you see my suggestion that we should mention the existence of the
> man and info commands in the FAQ entry?

I can do that.

--
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: non-interactive cygwin setup

[Gary R. Van Sickle]

> On Thu, 14 Oct 2004, Gary R. Van Sickle wrote:
> 
> > [snip]
> > > >I thought if a GUI app called printf it generally caused 
> a console 
> > > >to be opened for it.  Maybe that's only with msvcrt.  In 
> any case, 
> > > >the fact is that it is being run from a cmdline and so 
> it certainly 
> > > >can communicate with the console.  The presence of command-line 
> > > >options in argc/argv could be taken as a fairly strong 
> hint that it 
> > > >was being run from a shell rather than an icon.  And 
> there's always 
> > > >"isatty (1)" if you really really want to be sure.
> > >
> > > This is a windows limitation.  GUI apps (apps created with
> > > -mwindows) can't send output to or receive input from the 
> console.  
> > > Of course, a GUI can interpret command line information.  It just 
> > > cannot send output to the console that started it.
> > >
> > > You could use AllocConsole to create a separate console which the 
> > > GUI could then use, however.
> >
> > Here's a maybe-less-icky way to do it.  Have two exes, one 
> "setup.exe" 
> > which is a 100% command-line program that normally just spawns 
> > "winsetup.exe", the current GUI setup, and goes away.  Give it 
> > "--help", and it prints help in the regular command-line way and 
> > exits.  Yeah, two exes, but worse tragedies have happened.
> 
> Well, running the command-line program will pop up a console 
> window if it's not running from a console already.  How's 
> that different from just using AllocConsole in the GUI 
> version?  In fact, isn't this what MSVCRT does under the 
> covers anyway?
>   Igor

AllocConsole can only pop up a *new* console (right?), which doesn't buy
anybody anything (it's worse than a dialog IYAM).  With the way I suggested
you'd have:

$ setup --help
Cygwin Setup Version blah blah blah
Usage:
   -a  Blah blah bl-blah blah blah.
.


$ setup --option-one=Hello -XyZ
Doing command-line setup stuff, please watch the dots.done.

$ setup
<< GUI version winsetup.exe is spawned >>

Double-click on winsetup.exe ==> runs GUI version.

Double-click on setup.exe ==> runs setup.exe which flashes a console (which
actually I think can be prevented), spawns winsetup.exe, and goes away.


So in almost all (maybe even all) cases, you have no unused or new consoles
floating around and you get intuitive behavior.  Yet another of "GRVS's Olde
Tyme Solutions Which Make Everybody Happy(TM)"!

-- 
Gary R. Van Sickle


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

Selectively zipping files together

[Siegfried Heintze]

I did not see this bounce back to me so I am sending it again. I wonder if
the problem was with HTML/plain formatting?


I'm trying to use sun's jar utility (from Sun's java development kit) along
with the Cygwin find command to selectively zip together a directory tree
and send it to someone that can explode the tree using WinZIP or PKZIP.

I suppose it off topic to discuss the jar utility here. I'm looking for an
appropriate mailing list to solicit help with jar (suggestions are welcome).

The following does not work because it just grabs all the files in my
directory. I tried using the -print on find that did not help. I tried
removing the "@" pipe find into xargs and that did not work.


/usr/bin/find "." \( ! -name \*.pch -a ! -path \*CVS\* \) | jar cvf@
..\\archive.zip

Since we are not allowed to discuss jar here, is there a Cygwin utility that
produces Windows ZIP files that will work with find?

I even tried tar (even though it is not the format I want). Why does this
not work?

/usr/bin/find "." \( ! -name \*.pch -a ! -path \*CVS\* \) | xargs tar cvf
../archive.zip

 
The problem is the same: all the files are included. I also, for all of the
above, tried using the -print on the find command but that did not help.

 
Oh - and one last question: is there any document that compares bzip with
bzip2 and gnuzip and winzip?

 

  Thanks,

  Siegfried


--
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: Selectively zipping files together

[Christopher Faylor]

On Thu, Oct 14, 2004 at 09:48:13PM -0600, Siegfried Heintze wrote:
>I did not see this bounce back to me so I am sending it again. I wonder if
>the problem was with HTML/plain formatting?
>
>
>I'm trying to use sun's jar utility (from Sun's java development kit) along
>with the Cygwin find command to selectively zip together a directory tree
>and send it to someone that can explode the tree using WinZIP or PKZIP.
>
>I suppose it off topic to discuss the jar utility here. I'm looking for an
>appropriate mailing list to solicit help with jar (suggestions are welcome).

Yes, it is off-topic.  Why are you not just using the zip utility that comes
with cygwin?

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

LibFFI or LibVM? [was: Re: SableVM & Cygwin (was: Re: sablevm + windows)]

[Grzegorz B. Prokopski]

On Wed, 2004-10-13 at 15:25, Peter Lovell wrote:
> Speaking only for myself, I believe that option (2) would be the 
> appropriate one. It might be nice to include it also back to gcc but I 
> suspect that sablevm developers might prefer to not have that 
> dependency.

As for including libffi in SableVM sources...  You know, this "stripped
down" version is half the size of SableVM itself.  I do not think we
really want to introduce that amount of "bloat code", especially that
libffi *should be* available from other sources.

But thinking realistically - I have seen many, many times people who
wanted to try SableVM and they were able to easily get thru all the
dependencies, but libffi has always been the biggest pain, and often
the reason why some of them haven't tried SableVM yet.  Yes, I *am*
speaking from experience here.


I, and I am not alone in saying that, do not like the fact that libffi
is bound to GCC sources, that is, you pretty much need to fetch whole
GCC to get it compiled (even if in latest versions you apparently can
compile only the libffi itself).  Additionaly upstream started requiring
copyright assignment which is completly strange given that the license
of libffi is kind of "weaker-than-BSD".  They're also considering change
of the license to a more restrictive one.

This resulted in many patches NOT being accepted and people unable to
contribute their improvements.  What's important, these improvements
were mainly related to support for Windows, which is exactly what
I believe Peter is interested in.  There is also a few active developers
of various software that would also be interested in contributing.

For discussion that once too place, please see:

http://sources.redhat.com/ml/libffi-discuss/2004/

Therefore the idea of having LibFFI (or its derivative) packaged
independently seems really promising, especially when having support
for Windows in perspective.


I think a reasonable proposal here would be to take GCC's libffi, make
it fully standalone and give this standalone version a new, own
identity and allow for merging improvements w/o ridiculous copyright
assignment (see the license of libffi!).  This would be similar to how
sablevm-classpath and GNU Classpath work, with the difference, that this
new library, let's call it "LibVM", would be useful for everyone and
would not be at all SableVM specific.

It seems that maitaining such a "Standalone branch of libffi" should be
a rather low-burden task.  Until the upstream changes the license, it 
would mainly consist of merging the upstream changes, mergin and/or
preparing whatever changes are needed to make it work on platforms
we and others are interested in and making releases from time to time.

We are able and willing to provide hosting for such a small project,
including Subversion repository access for all interested developers,
own non-sablevm domain, web server space, mailing lists, BTS, etc.

Please let me know what you think about this idea,

Grzegorz B. Prokopski

-- 
Grzegorz B. Prokopski   <[EMAIL PROTECTED]>
SableVM - Free, LGPL'ed Java VM  http://sablevm.org
Why SableVM ?!?  http://sablevm.org/wiki/Features
Debian GNU/Linux - the Free OS   http://www.debian.org



--
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: Selectively zipping files together

[Siegfried Heintze]

>
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Christopher Faylor
>Sent: Thursday, October 14, 2004 9:55 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Selectively zipping files together
>
>>I'm trying to use sun's jar utility (from Sun's java development kit)
along
>>with the Cygwin find command to selectively zip together a directory tree
>>and send it to someone that can explode the tree using WinZIP or PKZIP.
>>
>>I suppose it off topic to discuss the jar utility here. I'm looking for an
>>appropriate mailing list to solicit help with jar (suggestions are
welcome).
>
>Yes, it is off-topic.  Why are you not just using the zip utility that 
> comes with cygwin?

Well that was one of my questions. What is the zip utility that comes with
Cygwin? Is it compatible with Windows zip?  

And what about using tar with find? I hope that is not off topic. Why does
tar insist on zipping up the entire directory instead of just the files I
select with find?

 Thanks,
 Sieg


--
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: Selectively zipping files together

[Christopher Faylor]

On Thu, Oct 14, 2004 at 10:34:11PM -0600, Siegfried Heintze wrote:
>>
>>-Original Message-
>>From: Christopher Faylor
>>Sent: Thursday, October 14, 2004 9:55 PM
>>To: [EMAIL PROTECTED]
>>Subject: Re: Selectively zipping files together
>>
>>>I'm trying to use sun's jar utility (from Sun's java development kit)
>along
>>>with the Cygwin find command to selectively zip together a directory tree
>>>and send it to someone that can explode the tree using WinZIP or PKZIP.
>>>
>>>I suppose it off topic to discuss the jar utility here. I'm looking for an
>>>appropriate mailing list to solicit help with jar (suggestions are
>welcome).
>>
>>Yes, it is off-topic.  Why are you not just using the zip utility that 
>> comes with cygwin?
>
>Well that was one of my questions. What is the zip utility that comes with
>Cygwin? Is it compatible with Windows zip?  

How about this for an idea?  Either install the zip utility and read the man
page or look at the description at http://cygwin.com/packages/ .

>And what about using tar with find? I hope that is not off topic. Why does
>tar insist on zipping up the entire directory instead of just the files I
>select with find?

I don't know.  If you give tar a directory it will save the whole directory.
Obviously you are providing tar with a directory.  "info tar" may be a useful
reading exercise.

As a hint, your use of xargs would not work.  If there are a lot of
arguments, xargs would invoke tar repeatedly, telling it to produce the
same file over and over again, wiping out the last archive.

You probably would want to use the '-T' option instead.

But, then, you really want to use 'zip'.  Really.

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: Ping: Cygwin libtool / assembler problem with -DPIC

[Charles Wilson]

Gerrit P. Haase wrote:
I think it is a bad thing to add -D flags unconditionally and for sure
it is a bad thing if it is a noop.
You're missing the point.  *libtool* doesn't know that -DPIC means 
nothing for your code.  On some platforms, you really have to compile 
DIFFERENT CODE, not just compile the same code in a different way 
(-fpic), when you want to make a pic object.

So Libtool is merely supplying a compile define as a hint, that you can 
then use in your code:

#if PIC
  this stuff is pic-safe
#else
  do it some other way
#endif
It's no different than in the bad old days, when libtool gave us DLL_EXPORT:
#if DLL_EXPORT
  #define decoration declspec(__dllexport__)
#else
  #define decoration declspec(__dllimport__)
#endif
It was up to the client code to cooperate with the -DDLL_EXPORT symbol; 
to use it in the right way; to not use it in ways that didn't work with 
libtool, etc.

Same with -DPIC.  gmp attempts to do that, but is going about it wrong IMO.
The answer should be to not define -D flags which do nothing, let the
user decide which -D flags she wants, these are CFLAGS after all.
See above.  Libtool is providing a symbol that COULD, even on cygwin, be 
of some use.  You cannot specify it as an AM_CFLAGS because it should be 
"on" when building .lo's and "off" when building .o's -- and AM_CFLAGS 
don't allow that fine-grain control.  So libtool does it.

Should do it, yes, however, why not undefine it in libtool, I still
don't see the reason why it is used at all.
It is not used by gmp.  It might be used by ncurses.  Or Orbit.  Or any 
one of the thousands of other libtoolized packages.  You're asking me to 
unilaterally remove a feature from libtool that other packages may 
already be using, because gmp doesn't use it and gets confused by it?

That's a gmp bug, not a libtool bug.
And yes, GMP should not care that much about its own machinery, if there
is a flag in libtool that prevents generating working code then
obviously the used tool is broken and should be fixed, defining these
workarounds because buildtools are broken is not the way to go.
The buildtool is not broken.  It's providing a hint to the package(gmp 
in this case).  It's not libtool's fault that gmp doesn't properly 
interpret that hint on cygwin; gmp DOES interpret the hint properly on 
other platforms ["properly" == compiles the correct code].  And gmp 
already has a workaround to adapt its own funkiness to work with libtool 
on cygwin.  Gmp's workaround is

ifdef(`DLL_EXPORT',`undefine(`PIC')')
(translation: on most platforms, obey -DPIC.  if PIC undef, compile 
non-pic asm instructions; if PIC def, compile the other instructions.
BUT, if DLL_EXPORT (e.g. if cygwin|mingw)) then gmp should always 
compile the non-pic asm instructions.  This is a gmp-specific exception; 
other packages may, even on cygwin, unlike gmp, want to behave 
differently when -DPIC/-UPIC.

But, because DLL_EXPORT does not mean "platform == cygwin|mingw", we 
need to change this gmp-specific workaround to one that is actually correct:

if (eq(`PLATFORM',`cygwin'),`undefine(`PIC')')
(I'm sure my syntax is wrong, but you get the idea)
  Because
Haible's packages nearly always include hacked versions of libtool or m4
macros it is always a pita to apply newer libtool versions, i.e. simply
doing autoreconf fails in most of the cases (CLN, gettext, libiconv,
GMP, ...choose your favourite Haible package...).
Yes, I know.  That aspect of Bruno's code annoys me to no end.
Of course, you're defeating your own argument here.  Why should I change 
the "official cygwin" libtool, or push changes upstream to the "real" 
libtool, to fix gmp -- when Bruno won't use the stock version anyway?

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