Re[2]: Understanding program startup

[DG Ellis <DG_Ellis at ccm dot jf dot intel dot com>]

Text item: 

Hello,
 I went and looked at libccrt0.cc and was able to figure out exactly what you 
where saying. However I still did not know how bash could pass the command line 
to an app when it was in the form of a string (and not an argv vector). I then 
decided to look at spawn.cc and found the code that I was hoping for. In that 
code, an argv is passed and is then processed into a "cooked" command line. This
cooking includes space detecting and quoting. It also doubles up on d-quotes 
(which are undone in dcrt0 build_argv). So I see where the process is done and 
complete. Now that I see the role of the code in dcrt0 for normal command lines,
I can now figure the "correct" path to take to help in the s-quote being ignored
etc behavior when the program is invoked outside a cygwin process.  Here is my 
proposal:

Move the "globify" call to before the compute_argc/build_argv sequence and 
operate on the original command line. Also within the confines of this "run only
if not under cygwin32" condition, pre-process the command line similar to the 
work done in spawn.cc that will respect d-quotes and s-quotes and wrap 
parameters with quoted spaces in d-quotes as spawn.cc does. This would not be a 
perfect process because this code would be working on the command string instead
of the original argv vector as in spawn. This code could also determine if the 
globbing characters are within quotes or not and not glob those. This "cooked" 
command line then could be passed on to compute_argc/build_argv as normal.  This
should bring the behavior in line (at least closer) with the operation under the
shell.

 Now the hard part, I probably won't be able to do this in the short term. I 
have worked around my original problem by just using d-quotes where I was using 
s-quotes.

   Thanks for the encouragement to look further into the process taken by a 
command in bash.

    Dave


______________________________ Reply Separator _________________________________
Subject: Re: Understanding program startup
Author:  jqb@netcom.com at SMTPGATE
Date:    3/19/97 8:14 PM


DG Ellis wrote:
>
>   I am not new to C programming, however, I am new to writing programs
> that run under a unix shell like bash.  For history, I found that single
> quotes are not respected by applications that use cygwin.dll when the
> program is invoked from outside bash.

That bug has been discussed here.

> I chased down the code to the
> winsup/dcrt0.cc source file and was busy modifying it when I decided to
> check on the behavior of "normal" command lines under bash and under NT.
> Well, I see where the code should behave certain ways and does when run
> under NT command processor, but does not behave at all the same when
> under bash.

bash does its own command line processing, so doing it in dcrt0
for programs run under bash would just mess things up.

> Now here is my question:
> My suspicion is that the routine dll_crt0_1 is not called if the
> program is run under the shell. Is this correct?

No, not at all.  Note the code in dll_crt0_1:

  if (! u->self->cygwin_parent_p)
    globify (&argc, &argv);

That does wildcard expansion if cygwin_parent_p isn't set.
cygwin_parent_p is set in pinfo_init (which is called a bit earlier
in dll_crt0_1) if the PID environment variable is set and matches
the corresponding process table (pinfo) entry.  That will be the
case if this process was execed by a cygwin process, such as bash.
There are of course other messy and confusing details.

> I will try to check on
> libc's crt0 to see if this is true (if I can find the source).

cygwin_crt0 in winsup/libccrt0.c, which is linked into the application
code, calls the dll_crt0 in dcrt0.cc in cygwin.dll.

> It looks
> like there are a lot of important things in the dll_crt0_1 routine that
> should be done in each case. If they don't get done, what happens?

Nothing useful, since dll_crt0_1 calls main, among its other important
functions.

> Could this be the ctrl-C crash problem???

Nope, sorry.

--
<J Q B>

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
References: <Wed, 19 Mar 97 18:00:22 PST_2@ccm.hf.intel.com>
Subject: Re: Understanding program startup
CC: gnu-win32@cygnus.com
To: DG Ellis <DG_Ellis@ccm.jf.intel.com>
MIME-Version: 1.0
X-Mailer: Mozilla 3.01Gold (WinNT; I)
Organization: JQB Enterprises
From: Jim Balter <jqb@netcom.com>
Date: Wed, 19 Mar 1997 20:14:32 -0800
Message-ID: <3330B9A8.2546@netcom.com>
Received: from sba-ca1-20.ix.netcom.com(204.32.201.52) by dfw-ix6.ix.netcom.com
via smap (V1.3)
     id sma000876; Wed Mar 19 22:16:59 1997
Received: (from smap@localhost)
          by dfw-ix6.ix.netcom.com (8.8.4/8.8.4)
       id WAA00922; Wed, 19 Mar 1997 22:17:24 -0600 (CST)
Received: from dfw-ix6.ix.netcom.com (dfw-ix6.ix.netcom.com [206.214.98.6]) by m
ailbag.jf.intel.com (8.8.5/8.7.3) with ESMTP id UAA24266 for <DG_Ellis@ccm.jf.in
tel.com>; Wed, 19 Mar 1997 20:26:27 -0800 (PST)
Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by re
lay.jf.intel.com (8.7.6/8.7.3) with ESMTP id UAA21160 for <DG_Ellis@ccm.jf.intel
.com>; Wed, 19 Mar 1997 20:24:08 -0800 (PST)
Return-Path: jqb@netcom.com
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".