Re: How to pass parameters to a windows application

[Harald Joerg]

Andy Koppe  writes:

> On 2 August 2010 07:49, Dave Hylands wrote:
>>
>> On Sun, Aug 1, 2010 at 5:43 PM, Jason Pyeron wrote:
>>> I am at my wits end trying to figure out how to execute this in bash
>>>
>>> C:\WINDOWS>cmd /c "start "" "C:\Documents and Settings\All
>>> Users\Desktop\projects\crisfield\trunk\etc""
>>
>> Based on your prompt, I'd say that you're not in bash.
>>
>> cmd /c start "c:\Documents and Settings\"
>>
>> works for me. From the cmd prompt,
>>
>> cmd /c "start "c:\Documents and Settings""
>>
>> works. I wrote a little program called open,
>> http://www.davehylands.com/Software/Open/
>>
>> which opens files the same way as double clicking on them. It also
>> translates cygwin paths into Win32 paths if you build the cygwin
>> version.
>> If passed a directory name, it does the same as choosing "Explore".
>
> You should both have a look at 'cygstart'.

Good that I'm typing so slow.

I was about to explain a procedure of mine which almost does what Jason
Pyeron wants, approximately working in almost every case, containing
lots of quote-escaping tricks (and starting with "`cygpath -u $COMSPEC`"
instead of the plain cmd, just in case)...  and making a total fool of
myself, given that cygstart does it all in one sweep.

Thanks for the nudge, Andy!
-- 
Cheers,
haj

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

Re: cygdrive prefix

[Harald Joerg]

Linda Walsh writes:

> [...] OTOH, at least the defaults are pretty sensible ...

Pretty sensible, indeed.  I love /cygdrive as just another example of a
pretty sensible default.

> ... (I can just hit ENTER), through the setup ...

...and the default buttons in the GUI are always in the same place on
the screen, so if I happen to use a mouse I can just click through, no
need to move the mouse.  Not a big deal, maybe, but if so, why are so
many other installers missing it?

> ... -- EXCEPT...at the end -- how many times do I have to tell setup
> that I *STILL* don't want the icon on my desktop??!

I eventually got around that one.

I found that I do not want *any* icons on my desktop and switched them
off completely.  There is an option in the "Sort symbols" function of
the desktop.

And since then I completely fail to be annoyed by the mess of icons
which your average installer will drop on my desktop.  Most of them
don't even ask whether they should.
-- 
Cheers,
haj

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

Thanks (was: Re: Where is LEIM for cygwin's emacs 21.2?)

[Harald Joerg]

Ken Brown  writes:

> On 8/5/2009 4:16 AM, Harald Joerg wrote:
>> Very rarely I need to type one or two japanese characters in my
>> emacs, and I recall that I did it with LEIM and set-input-method quite
>> easily.   However, in my current installation, emacs says that LEIM
>> isn't installed.
> [...]
>> As a workaround, I fetched emacs-leim from the web, extracted the
>> tar.bz2 and symlinked the contents to /usr/share/21.2/leim.  Now
>> set-input-method works as expected.  But I doubt that this is how it
>> ought to be.
>> 
>>  * Is there something wrong with my installation (old installation,
>>carried over from another machine)?
>
> No.  There was confusion a couple of years ago when it looked like emacs 
> was going to be updated to version 22.1 (which did include leim).  At 
> that point emacs-leim was declared obsolete.  Unfortunately, the 
> emacs-22.1 build turned out to be unstable, but emacs-leim was never 
> reinstated.
>
>>  * Would a switch to emacs and emacs-el 23.0.92 be the recommended
>>solution (emacs-el 23.0.92 apparently contains LEIM)?
>
> Yes.  BTW, emacs-el is irrelevant; it just contains the library source 
> files (*.el).  The byte-compiled libraries (*.elc), including leim, are 
> in the emacs package.

Excellent!  Many thanks for your clarfications, on both emacs-leim and
cygwin's emacs-el package.

I have just installed emacs 23.0.92 from setup.exe's "experimental"
branch and Japanese characters work like charm.

As an additional bonus I found that Emacs is able to save Japanese
characters as Unicode which makes interoperation with other programs
much easier.  Excellent!

All I had to do after the upgrade was to *remove* my private
installation of gnus 5.10.6.  It was outdated, didn't work with Emacs23,
and is not necessary since a perfectly working Gnus v5.13 comes bundled
with cygwin's emacs 23.0.92.  Wonderful!
-- 
Cheers,
haj

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

Where is LEIM for cygwin's emacs 21.2?

[Harald Joerg]

Very rarely I need to type one or two japanese characters in my
emacs, and I recall that I did it with LEIM and set-input-method quite
easily.   However, in my current installation, emacs says that LEIM
isn't installed.

The cygwin installer says:
   LEIM is part of emacs package now.

The directory where LEIM used to be, /usr/share/21.2/leim/, exists but
is empty, both on my machine and on
.

There's no LEIM at all in

but the title says "(including LEIM)".

As a workaround, I fetched emacs-leim from the web, extracted the
tar.bz2 and symlinked the contents to /usr/share/21.2/leim.  Now
set-input-method works as expected.  But I doubt that this is how it
ought to be.

 * Is there something wrong with my installation (old installation,
   carried over from another machine)?

 * Did I miss to install / re-install an emacs package?

 * Is it a packaging error with cygwin's emacs-el 21.2 package?

 * Would a switch to emacs and emacs-el 23.0.92 be the recommended
   solution (emacs-el 23.0.92 apparently contains LEIM)?
-- 
Cheers,
haj


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

Re: Apache with mod_perl up and running

[Harald Joerg]

Gerrit P. Haase writes:

> Harald Joerg wrote:
>
>>We already know that - for archeological reasons - mod_perl's DSO
>>library happens to have the same file name as perl's, eh?  Here's
>>a place where this *really* bit me.
>
> Oh yeah, I cannot believe that they don't change the name.  If someone
> has a nice workaround to add to perlld to handle this issue with
> mod_perl, feel free to contact me.

How about being a bit more "positive" when checking for perl?  The
following patch tests whether the dll being built contains an object
called 'perl.o' (would we have to check $(OBJ_EXT)?  I hope not -
perlld is cygwin and cygwin has '.o'):

--- /usr/bin/perlld.orig2005-08-05 11:06:27.041388400 +0200
+++ /usr/bin/perlld 2005-08-05 11:07:23.288868400 +0200
@@ -49,5 +49,5 @@
   my $v_e_r_s = substr("5.8.7",0,-2);
   $v_e_r_s =~ tr/./_/;
-  if ( $dllname =~ /libperl.*/) { 
+  if ( $dllname =~ /libperl.*/  &&  $args =~ /\bperl\.o\b/) { 
 $dllname ="cygperl$v_e_r_s.dll";
   } else {

I admit that I have not yet rebuilt perl with this perlld -
but mod_perl now takes the perlld step without being renamed.

P.S.: In the meantime I managed to compile mod_auth_kerb as well,
linking against /usr/bin/libhttpd as you recommended.  So my mod_perl
deviation had its merits :-)

P.P.S.: In my "success story" about mod_perl I forgot to mention that
I had to run rebaseall to get the server running.

P.P.P.S.: Ah, yes, and I had to re-install emacs because it got stuck
in an endless loop immediately after starting (consuming 100% CPU)
after the rebaseall.
-- 
Cheers,
haj

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

Apache with mod_perl up and running (was: Re: error compiling apache-1.3.33 with mod_perl and perl-5.8.7-1)

[Harald Joerg]

I wrote:

> Gerrit P. Haase writes:
>>> [...]  Would mod_perl work with a mod_so setup as well?
>>
>> Yes it should work.  Have you tried to link directly against the DLL?
>
> You mean against /usr/bin/libhttpd.dll?
>
> I've tried, but failed miserably so far.  I've been starting with the
> build procedure delivered with mod_perl (DO_HTTPD=1), which creates a
> different Apache than what I get from cygwin's setup.  I have yet to
> find out how cygwin's Apache has been built...

OK, I've got it up and running now.

There are a couple of gotchas, though, mainly with the mod_perl
installation procedures.  Be warned.

1) In the mod_perl directory, start as documented for creating a DSO
   mod_perl:

   $ perl Makefile.PL USE_APXS=1 EVERYTHING=1 WITH_APXS=/usr/sbin/apxs

2) Run make.

3)  Curse when trying to understand
3a) why it fails to resolve against the apache core and
3b) why the heck make is trying to create cygperl5_8.dll.

ad 3a): I haven't found a solution.  I guess one can set some
environment variable or to add some parameter to perl Makefile.PL, but
I haven't discovered *how*.  My workaround was to manually enter the
offending gcc command (wrapped for readability):

gcc -shared -o  cygperl5_8.dll -Wl,--out-implib=libperl.dll.a \
-Wl,--export-all-symbols -Wl,--enable-auto-import \
-Wl,--stack,8388608 -Wl,--enable-auto-image-base -s -L/usr/local/lib \
mod_perl.lo perlxsi.lo perl_config.lo perl_util.lo perlio.lo \
mod_perl_opmask.lo Apache.lo Constants.lo ModuleConfig.lo \
Log.lo URI.lo Util.lo Connection.lo Server.lo File.lo Table.lo \
-s -s -L/usr/local/lib \
/usr/lib/perl5/5.8/cygwin/auto/DynaLoader/DynaLoader.a \
/usr/lib/perl5/5.8/cygwin/auto/Win32CORE/Win32CORE.a \
-L/usr/lib/perl5/5.8/cygwin/CORE -lperl -lcrypt -lgdbm_compat

with two more parameters added:

-L/usr/bin -lhttpd

ad 3b):  I had to find out that I couldn't simply resume make because
it would again try to compile all the .lo files into cygperl5_8.dll.
The simple reason:

   the target in the mod_perl makefile is 'libperl.so'.  However, ld2
   as invoked by the makefile calls perlld, which insists on having
   libperl.* renamed to cygperl5_8.dll in the -o parameter for the gcc
   command.

   We already know that - for archeological reasons - mod_perl's DSO
   library happens to have the same file name as perl's, eh?  Here's
   a place where this *really* bit me.

I copied cygperl5_8.dll to libperl.so to get make into believing that
the linking has been successful.  Nevertheless the apxs step failed,
telling me that libperl.so isn't a DSO library.  How would apxs know?

   On cygwin (and only on cygwin), apxs insists on having a suffix of
   .dll for DSOs.

So what I finally did was to manually copy cygperl5_8.dll to
/usr/lib/apache/mod_perl.dll and changed /etc/apache/httpd.conf
myself.

I apologize for not going deeper into the subject and for not trying
to create the necessary patches to the procedures and the
documentation right now.  As I already mentioned, compiling mod_perl
was just a step aside during my attempts to add mod_auth_kerb to my
cygwin apache.
-- 
Cheers,
haj

--
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: error compiling apache-1.3.33 with mod_perl and perl-5.8.7-1

[Harald Joerg]

Gerrit P. Haase writes:

> [...]
>>>Bruno Postle wrote:
>> [...]
undefined reference to `_boot_'
>>> [...]
>>>Something broken with generating the code for perlxsi?
> [...]
>> If $static_ext was empty, it is now " Win32CORE", with a leading
>> space.
>> When building perlxsi.c, ExtUtils::Embed splits $static_ext, which
>> according to Perl's rules, creates two elements: '' and 'Win32CORE'.
>> The empty element creates a line in perlxsi.c which calls for 'boot_'.
>> Ouch.
>
> IMO a bug in ExtUtils::Embed.

I'd have said so - but this version of ExtUtils::Embed has been around
for a while.  That's why I have been looking for a solution - or a
workaround - within the cygwin build.

Nevertheless I'll try to file a bug report to perlbug.  Having
Extutils::Embed kill undefined static_ext elements doesn't harm and
makes the procedure more robust.

>> I don't know enough about building perl - especially I've no idea
>> whether the sequence of static_ext is of any importance.  Maybe the
>> following is a simple solution:
>> ===
>> --- perl-5.8.6/hints/cygwin.sh.orig  2004-02-22 14:07:58.0 -0800
>> +++ perl-5.8.6/hints/cygwin.sh.haj   2004-12-08 20:52:01.891572800 -0800
>> @@ -57,3 +57,4 @@
>>  ldflags="$ldflags -s"
>>  ccdlflags="$ccdlflags -s"
>>  lddlflags="$lddlflags -s"
>> +static_ext="Win32CORE $static_ext"
>> --- perl-5.8.7/cygwin/cygwin.c.orig  2005-04-22 12:54:18.0
>> +0200
>> ===
>
>
> Should do it.  I'll change it for future releases.

Great!  I prefer to run vanilla cygwin installations instead of my own
compilations - they tend to be more stable :-)

> [...]  Would mod_perl work with a mod_so setup as well?
>
> Yes it should work.  Have you tried to link directly against the DLL?

You mean against /usr/bin/libhttpd.dll?

I've tried, but failed miserably so far.  I've been starting with the
build procedure delivered with mod_perl (DO_HTTPD=1), which creates a
different Apache than what I get from cygwin's setup.  I have yet to
find out how cygwin's Apache has been built...
-- 
Cheers,
haj

--
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: error compiling apache-1.3.33 with mod_perl and perl-5.8.7-1

[Harald Joerg]

(Sorry, maybe I can't get the references right since I'm replying to
the article found at
)

> Bruno Postle wrote:

>> I can't build apache-1.3.33 and mod_perl-1.29 with perl-5.8.7-1

>> (it builds ok if I downgrade cygwin to perl-5.8.6-4)

>> Steps to reproduce:

>>   tar -zxf apache_1.3.33.tar.gz
>>   tar -zxf mod_perl-1.0-current.tar.gz
>>   cd mod_perl-1.29/
>>   perl Makefile.PL DO_HTTPD=1 USE_APACI=1
>>   make

>> [...]
>> undefined reference to `_boot_'
> Info: resolving _optarg by linking to __imp__optarg (auto-import)
> collect2: ld returned 1 exit status 

> _boot_?  Boot what?  Win32CORE?  However, this was already included with
>  the 5.8.6 release.

> $ nm /usr/lib/perl5/5.8/cygwin/auto/DynaLoader/DynaLoader.a | grep boot
> 0810 T _boot_DynaLoader

> $ nm /usr/lib/perl5/5.8/cygwin/auto/Win32CORE/Win32CORE.a  | grep boot
> 4c70 T _boot_Win32CORE

> Something broken with generating the code for perlxsi?

That's what it seems to be - though it actually is a consequence of
something strange in the build process of Perl itself.

Looks like a patch in cygwin.sh is causing the troubles
(from p587w32core.patch):

===
--- perl-5.8.6/hints/cygwin.sh.orig 2004-02-22 14:07:58.0 -0800
+++ perl-5.8.6/hints/cygwin.sh  2004-12-08 20:52:01.891572800 -0800
@@ -57,3 +57,4 @@
 ldflags="$ldflags -s"
 ccdlflags="$ccdlflags -s"
 lddlflags="$lddlflags -s"
+static_ext="$static_ext Win32CORE"

--- perl-5.8.7/cygwin/cygwin.c.orig 2005-04-22 12:54:18.0 +0200
===

If $static_ext was empty, it is now " Win32CORE", with a leading space.
When building perlxsi.c, ExtUtils::Embed splits $static_ext, which
according to Perl's rules, creates two elements: '' and 'Win32CORE'.
The empty element creates a line in perlxsi.c which calls for 'boot_'.

Ouch.

I don't know enough about building perl - especially I've no idea
whether the sequence of static_ext is of any importance.  Maybe the
following is a simple solution:

===
--- perl-5.8.6/hints/cygwin.sh.orig 2004-02-22 14:07:58.0 -0800
+++ perl-5.8.6/hints/cygwin.sh.haj  2004-12-08 20:52:01.891572800 -0800
@@ -57,3 +57,4 @@
 ldflags="$ldflags -s"
 ccdlflags="$ccdlflags -s"
 lddlflags="$lddlflags -s"
+static_ext="Win32CORE $static_ext"

--- perl-5.8.7/cygwin/cygwin.c.orig 2005-04-22 12:54:18.0 +0200
===

I have just built perl this way with build.sh from the source package
with the following test results:

Failed 5 test scripts out of 916, 99.45% okay.
Failed 4/946 test scripts, 99.58% okay. 254/101134 subtests failed, 99.75% okay.

Maybe the failures are caused by my system's setup, or maybe they are
cygwin-intrinsic... I don't know.

mod_perl can be built with my perl 5.8.7, though I have not yet tested
any applications yet.

PS: Actually I haven't been intending to compile mod_perl when I found
the article quoted here.  I simply have been trying to compile another
extension (mod_auth_kerb), found that cygwin's vanilla Apache doesn't
have symbols to link against, and decided to start from scratch with
Google's help.  I have been looking for the configuration options
which have been used to build cygwin's Apache but failed - following
Bruno's recipe above creates a statically linked httpd.exe and no
libhttpd.dll.  Would mod_perl work with a mod_so setup as well?
-- 
Cheers,
haj

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