easy enough. But what's the best way to use "the shell"? Do a unquoted
replacement (<
Yes.
Somewhere, buried in the configury stuff is an environment
variable named something like, "CONFIG_SHELL". That's what
you want. If it is not available, then imitating the techniques
used to obtain it
Charles Wilson wrote:
>
> Bruce Korb wrote:
> > Earnie Boyd wrote:
> >
> >>This patch passes my test. What do we need to do to get this accepted
> >>into libtool cvs HEAD?
> >
> >
> >>>+ newargz[0] = xstrdup("/bin/sh");
> >>
> >
> > This may not be the shell and there is no point allocating it.
Bruce Korb wrote:
Earnie Boyd wrote:
This patch passes my test. What do we need to do to get this accepted
into libtool cvs HEAD?
+ newargz[0] = xstrdup("/bin/sh");
This may not be the shell and there is no point allocating it.
It is fine to use it from static memory.
Okay, the secon
Earnie Boyd wrote:
>
> This patch passes my test. What do we need to do to get this accepted
> into libtool cvs HEAD?
> > + newargz[0] = xstrdup("/bin/sh");
This may not be the shell and there is no point allocating it.
It is fine to use it from static memory.
--
Unsubscribe info: http:/
This patch passes my test. What do we need to do to get this accepted
into libtool cvs HEAD?
Earnie.
Charles Wilson wrote:
Okay, this version
1) puts lt-foo.c into .libs
2) "libtool --mode=clean" does the right thing --- cleans up foo,
foo.exe, .libs/foo.exe, .libs/lt-foo.c, plus whatever el
Earnie Boyd wrote:
Charles Wilson wrote:
There are two places in ltmain.sh where the shell wrapper is directly
sourced. This doesn't work very well, because when both "foo" and
"foo.exe" exist, ". ./foo" ends up sourcing "foo.exe" -- which is bad.
This can be resolved by ``. ./foo.'' inste
Charles Wilson wrote:
There are two places in ltmain.sh where the shell wrapper is directly
sourced. This doesn't work very well, because when both "foo" and
"foo.exe" exist, ". ./foo" ends up sourcing "foo.exe" -- which is bad.
This can be resolved by ``. ./foo.'' instead for the cygwin/min
Charles Wilson wrote:
Hmmm...now there's a thought. Perhaps, perhaps...
Said "stub" executable would have to do ALL of the things the script
does, and then pass that environment to its exec'ed target in .libs/ --
does native windows provide an exec() command? Environment inheritance?
You'd
8 matches
Mail list logo
