RE: Perl Win32::Shortcut screws up fork

RE: Perl Win32::Shortcut screws up fork

[Adye, TJ (Tim)]

Hi Larry,

Sorry, I assumed that the rebasing problem was ancient history, since I
hadn't encountered it for so long (and remembered a long-ago comment
about rebaseall being a stop-gap measure). Thanks for putting me right.

Unfortunately I can't get rebaseall to work... running from a bash
prompt in a DOS box (as the docs tell me to), I get

% ps -a
      PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
     1668       1    1668       1668    0 22534 19:36:55 /usr/bin/bash
     1268    1668    1268       1800    0 22534 19:45:04 /usr/bin/ps
% rebaseall
ReBaseImage (/usr/bin/cygiconv-2.dll) failed with last error = 6

cygiconv-2.dll is used by bash, but rebaseall is a bash script. What can
I do?

Thanks,
Tim.

> -----Original Message-----
> From: Larry Hall
> Sent: 07 July 2005 19:09
> To: Adye, TJ (Tim); cygwin@cygwin.com
> Subject: Re: Perl Win32::Shortcut screws up fork
> 
> At 01:10 PM 7/7/2005, you wrote:
> >In an attempt to work round the problem with readshortcut I reported
> >earlier, I thought I'd use a Perl script. Unfortunately the
> >Win32::Shortcut package seems to cause problems with process forking
> >(unlike the readshortcut error, this one isn't specific to the latest
> >cygwin DLL). I get an error
> >
> >C:\cygwin\bin\perl.exe (3088): *** unable to remap
> >C:\cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Shortcu
> t\Shortcut.
> >dll to same address as parent(0xBF0000) != 0x1110000
> >     13 [main] perl 3716 fork_parent: child 3088 died waiting for dll
> >loading 
> 
> 
> Sounds like a classic rebasing issue to me.  Have you tried running 
> 'rebaseall'?
> 
> 
> 
> 
> --
> Larry Hall                              http://www.rfk.com
> RFK Partners, Inc.                      (508) 893-9779 - RFK Office
> 838 Washington Street                   (508) 893-9889 - FAX
> Holliston, MA 01746                     
> 
> 

--
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: Perl Win32::Shortcut screws up fork

[Larry Hall]

At 02:54 PM 7/7/2005, you wrote:
>Hi Larry,
>
>Sorry, I assumed that the rebasing problem was ancient history, since I
>hadn't encountered it for so long (and remembered a long-ago comment
>about rebaseall being a stop-gap measure). Thanks for putting me right.


Well, it's not entirely a stop-gap measure.  The original idea is that
its functionality would become integrated into 'setup.exe' so that it 
would hopefully become (more) transparent.  But it will still be there.


>Unfortunately I can't get rebaseall to work... running from a bash
>prompt in a DOS box (as the docs tell me to), I get
>
>% ps -a
>      PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
>     1668       1    1668       1668    0 22534 19:36:55 /usr/bin/bash
>     1268    1668    1268       1800    0 22534 19:45:04 /usr/bin/ps
>% rebaseall
>ReBaseImage (/usr/bin/cygiconv-2.dll) failed with last error = 6
>
>cygiconv-2.dll is used by bash, but rebaseall is a bash script. What can
>I do?


 From your later message, I can see you figured this out for yourself.
You may have found that not being able to rebase cygiconv-2.dll wasn't
a problem for you anyway.  Or maybe you would have.  In any case, the 
message does draw some attention, correctly or not.

Glad you got your solution. :-)


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


--
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: Perl Win32::Shortcut screws up fork

[Brian Dessent]

"Adye, TJ (Tim)" wrote:

> % rebaseall
> ReBaseImage (/usr/bin/cygiconv-2.dll) failed with last error = 6
> 
> cygiconv-2.dll is used by bash, but rebaseall is a bash script. What can
> I do?

This is a problem with the new bash version 3.0, which is dynamically
linked to the readline, libiconv, and ncurses DLLs:

  C:\cygwin\bin\cygwin1.dll
    C:\WINXP\System32\ADVAPI32.DLL
      C:\WINXP\System32\ntdll.dll
      C:\WINXP\System32\KERNEL32.dll
      C:\WINXP\System32\RPCRT4.dll
  C:\cygwin\bin\cygintl-3.dll
    C:\cygwin\bin\cygiconv-2.dll
  C:\cygwin\bin\cygreadline6.dll
    C:\cygwin\bin\cygncurses-8.dll
    C:\WINXP\System32\USER32.dll
      C:\WINXP\System32\GDI32.dll

The prior version of bash, 2.05b-17, is statically linked:

  C:\cygwin\bin\cygwin1.dll
    C:\WINXP\System32\ADVAPI32.DLL
      C:\WINXP\System32\ntdll.dll
      C:\WINXP\System32\KERNEL32.dll
      C:\WINXP\System32\RPCRT4.dll
  C:\WINXP\System32\USER32.dll
    C:\WINXP\System32\GDI32.dll

This presents a somewhat serious problem for the rebaseall script.  It
can be modified to exclude cyg{intl-3,iconv-2,readline6,ncurses-8}.dll
but that is not a very good solution, because it means they will not be
rebased.  These DLLs unfortunately are used by lots of programs and I
fear not rebasing them is a poor solution.

I think we will require a statically linked bash, or some kind of
trickery in the rebaseall script.  One potential way around this might
be for it to output a .cmd file (or .bat under 9x, grrr) and then exec()
$COMSPEC to run the commands.  This would have the advantage of not
requiring any Cygwin DLLs in use during the rebase, but it sounds more
error prone and complicated.

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: Perl Win32::Shortcut screws up fork

[Christopher Faylor]

On Thu, Jul 07, 2005 at 06:15:36PM -0700, Brian Dessent wrote:
>I think we will require a statically linked bash, or some kind of
>trickery in the rebaseall script.  One potential way around this might
>be for it to output a .cmd file (or .bat under 9x, grrr) and then exec()
>$COMSPEC to run the commands.  This would have the advantage of not
>requiring any Cygwin DLLs in use during the rebase, but it sounds more
>error prone and complicated.

But, the alternative of creating a version of bash just so that people
can run rebaseall sounds even more error prone.

I don't see any other foolproof way of doing this.

Btw, don't '.bat' files work on NT, too?

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: Perl Win32::Shortcut screws up fork

[Brian Dessent]

Christopher Faylor wrote:

> >I think we will require a statically linked bash, or some kind of
> >trickery in the rebaseall script.  One potential way around this might
> >be for it to output a .cmd file (or .bat under 9x, grrr) and then exec()
> >$COMSPEC to run the commands.  This would have the advantage of not
> >requiring any Cygwin DLLs in use during the rebase, but it sounds more
> >error prone and complicated.
> 
> But, the alternative of creating a version of bash just so that people
> can run rebaseall sounds even more error prone.
> 
> I don't see any other foolproof way of doing this.
> 
> Btw, don't '.bat' files work on NT, too?

By 'error prone' I meant that the current rebaseall script knows to stop
the process when the first error happens.  A .bat file would just try to
plow through without checking, though you could certainly write more
logic to check the errorlevel.  But you would have to limit yourself to
the command.com level of functionality, which is pretty prehistoric
IIRC.

Option B would be to write a C or C++ program to do the job of what
rebaseall currently does.  That's even more work.

When I mentioned a static bash I was thinking of just making the base
package statically compiled, not having an alternative.  Somehow I
imagined that this would make it a little faster too, but that's
probably going to be insignificant.

I'm also wondering if the issue would ever come up in postinstall
scripts.  Where before with ash or bash 2.x, we only required a working
Cygwin DLL, now any postinstall script has to also have these 4 core
DLLs in addition to the Cygwin DLL in place for any postinstall to
function.  I haven't really though this through though, as to whether
this scenario matters.

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: Perl Win32::Shortcut screws up fork

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Brian Dessent on 7/7/2005 7:41 PM:
> 
> Option B would be to write a C or C++ program to do the job of what
> rebaseall currently does.  That's even more work.

True - there are many actions where scripts are just more convenient than
full-blown programs, even though it introduces a dependency on the shell
running the script.

> 
> When I mentioned a static bash I was thinking of just making the base
> package statically compiled, not having an alternative.  Somehow I
> imagined that this would make it a little faster too, but that's
> probably going to be insignificant.
> 
> I'm also wondering if the issue would ever come up in postinstall
> scripts.  Where before with ash or bash 2.x, we only required a working
> Cygwin DLL, now any postinstall script has to also have these 4 core
> DLLs in addition to the Cygwin DLL in place for any postinstall to
> function.  I haven't really though this through though, as to whether
> this scenario matters.

coreutils already requires libintl and libiconv since 5.2.1 days, so most
useful actions in a postinstall script have already depended on having
libraries available as part of Base.  Based on several months of no
complaints, I think we can discount the theoretical problems of this scenario.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCzd7c84KuGfSFAYARArF0AJ4vwRWQaQ81V3CJXULqyhEknMd5hQCg2OiV
DLMDtNFn4FGM6Qe19fmb1XQ=
=YTpA
-----END PGP SIGNATURE-----

--
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: Perl Win32::Shortcut screws up fork

[Brian Dessent]

Eric Blake wrote:

> coreutils already requires libintl and libiconv since 5.2.1 days, so most
> useful actions in a postinstall script have already depended on having
> libraries available as part of Base.  Based on several months of no
> complaints, I think we can discount the theoretical problems of this scenario.

Postinstall scripts almost universally have /bin/sh in the shebang, and
so were using ash regardless of which bash was installed.  The recent
replacement of /bin/sh with bash means that prior to now we had no
experience in this area.

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: Perl Win32::Shortcut screws up fork

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Brian Dessent on 7/7/2005 8:21 PM:
>>coreutils already requires libintl and libiconv since 5.2.1 days, so most
>>useful actions in a postinstall script have already depended on having
>>libraries available as part of Base.  Based on several months of no
>>complaints, I think we can discount the theoretical problems of this scenario.
> 
> Postinstall scripts almost universally have /bin/sh in the shebang, and
> so were using ash regardless of which bash was installed.  The recent
> replacement of /bin/sh with bash means that prior to now we had no
> experience in this area.

Except that even the /bin/sh postinstalls often did mv, cp, or some other
action involving one of the coreutils.  It's hard to do much of anything
without using the coreutils, which have depended on iconv and intl since
their 5.2.1 days.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCzecl84KuGfSFAYARAkVEAJwJohzcIOEcEVJ1cPuKwSG1pHXD7wCeJl5C
0K/KUiYy6gOyqsjlNPg78GI=
=RSRh
-----END PGP SIGNATURE-----

--
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: Perl Win32::Shortcut screws up fork

[Brian Dessent]

Eric Blake wrote:

> Except that even the /bin/sh postinstalls often did mv, cp, or some other
> action involving one of the coreutils.  It's hard to do much of anything
> without using the coreutils, which have depended on iconv and intl since
> their 5.2.1 days.

You're right.  As I said, I hadn't actually thought through this
scenario very well.  :-)

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: Perl Win32::Shortcut screws up fork

[Christopher Faylor]

On Thu, Jul 07, 2005 at 06:41:31PM -0700, Brian Dessent wrote:
>Christopher Faylor wrote:
>>>I think we will require a statically linked bash, or some kind of
>>>trickery in the rebaseall script.  One potential way around this might
>>>be for it to output a .cmd file (or .bat under 9x, grrr) and then exec()
>>>$COMSPEC to run the commands.  This would have the advantage of not
>>>requiring any Cygwin DLLs in use during the rebase, but it sounds more
>>>error prone and complicated.
>>
>>But, the alternative of creating a version of bash just so that people
>>can run rebaseall sounds even more error prone.
>>
>>I don't see any other foolproof way of doing this.
>>
>>Btw, don't '.bat' files work on NT, too?
>
>By 'error prone' I meant that the current rebaseall script knows to stop
>the process when the first error happens.  A .bat file would just try to
>plow through without checking, though you could certainly write more
>logic to check the errorlevel.  But you would have to limit yourself to
>the command.com level of functionality, which is pretty prehistoric
>IIRC.

I was thinking that rebaseall would just create a simple .bat file which
would be run when no other cygwin process was running.  The only thing I
see in rebaseall that wouldn't be doable in a .bat file is the
cleanup-on-error part.  The only thing you couldn't do then is
cleanup-on-error.

If rebaseall wanted to be really clever, it could detect dlls that are
currently loaded into memory, copy them to another temporary name,
rebase those dlls, and then set things up so that the correct dlls are
copied on reboot.  Or a program or .bat file could be run at the user's
discretion to rename the dlls to the correct name.  This would be run
when all cygwin processes had exited.

Or, perhaps we should make sure that the dlls used by bash are already
nicely based and tell rebase to 1) make sure that no other dlls are
rebased into their load address and 2) ignore the dlls.  That's probably
the ultimate solution.

>Option B would be to write a C or C++ program to do the job of what
>rebaseall currently does.  That's even more work.

I was going to suggest that but it requires that the user had loaded
the C compiler which seems like overkill for this.

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: Perl Win32::Shortcut screws up fork

[Igor Pechtchanski]

On Thu, 7 Jul 2005, Christopher Faylor wrote:

> On Thu, Jul 07, 2005 at 06:41:31PM -0700, Brian Dessent wrote:
>
> >Option B would be to write a C or C++ program to do the job of what
> >rebaseall currently does.  That's even more work.
>
> I was going to suggest that but it requires that the user had loaded
> the C compiler which seems like overkill for this.

I think (hope) Brian meant a C/C++ program to replace the rebaseall bash
script, not that rebaseall produced a C program that would need to be
compiled and run... :-)
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
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: Perl Win32::Shortcut screws up fork

[Christopher Faylor]

On Thu, Jul 07, 2005 at 10:21:29PM -0400, Igor Pechtchanski wrote:
>On Thu, 7 Jul 2005, Christopher Faylor wrote:
>
>> On Thu, Jul 07, 2005 at 06:41:31PM -0700, Brian Dessent wrote:
>>
>> >Option B would be to write a C or C++ program to do the job of what
>> >rebaseall currently does.  That's even more work.
>>
>> I was going to suggest that but it requires that the user had loaded
>> the C compiler which seems like overkill for this.
>
>I think (hope) Brian meant a C/C++ program to replace the rebaseall bash
>script, not that rebaseall produced a C program that would need to be
>compiled and run... :-)

Right.  Duh.

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: Perl Win32::Shortcut screws up fork

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Christopher Faylor on 7/7/2005 8:05 PM:
>>Option B would be to write a C or C++ program to do the job of what
>>rebaseall currently does.  That's even more work.
> 
> I was going to suggest that but it requires that the user had loaded
> the C compiler which seems like overkill for this.

I think the intent of this suggestion was to replace rebaseall (the shell
script) with rebaseall.exe (the static executable), not to have rebaseall
output C source code, compile it, then run it.

But what was wrong with my idea of making rebaseall a #!/bin/ash script?

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCzePU84KuGfSFAYARAtBVAKDHj6dMOmdifA3uILtO/XhOMVJ6YACfXP6V
nSEuITr77f5r2+Buu2MMGxI=
=3t+9
-----END PGP SIGNATURE-----

--
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: Perl Win32::Shortcut screws up fork

[Christopher Faylor]

On Thu, Jul 07, 2005 at 08:24:20PM -0600, Eric Blake wrote:
>According to Christopher Faylor on 7/7/2005 8:05 PM:
>>>Option B would be to write a C or C++ program to do the job of what
>>>rebaseall currently does.  That's even more work.
>> 
>> I was going to suggest that but it requires that the user had loaded
>> the C compiler which seems like overkill for this.
>
>I think the intent of this suggestion was to replace rebaseall (the shell
>script) with rebaseall.exe (the static executable), not to have rebaseall
>output C source code, compile it, then run it.
>
>But what was wrong with my idea of making rebaseall a #!/bin/ash script?

You still couldn't run the script from bash since the dlls would still
be loaded.  That would mean that you'd have to do something like:

c:\>ash rebaseall

(Currently rebaseall won't work as an ash script but the fix is trivial)

I guess that's better than nothing but I still think that just not
rebasing the bash dlls is going to result in fewer mailing list
complaints.

OTOH, if we had some coordination between the maintainers of DLLs in
the distribution we could reduce the need for rebase a lot.  I don't
know if using --enable-auto-image-base would fix every problem but
I suspect that it might help.

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: Perl Win32::Shortcut screws up fork

[Gerrit P. Haase]

Christopher Faylor wrote:

>>But what was wrong with my idea of making rebaseall a #!/bin/ash script?
> 
> 
> You still couldn't run the script from bash since the dlls would still
> be loaded.  That would mean that you'd have to do something like:
> 
> c:\>ash rebaseall
> 
> (Currently rebaseall won't work as an ash script but the fix is trivial)
> 
> I guess that's better than nothing but I still think that just not
> rebasing the bash dlls is going to result in fewer mailing list
> complaints.
> 
> OTOH, if we had some coordination between the maintainers of DLLs in
> the distribution we could reduce the need for rebase a lot.  I don't
> know if using --enable-auto-image-base would fix every problem but
> I suspect that it might help.


I suggest another simple solution.  Teach rebase to read an INI file if
called without options, this INI includes all options needed for
rebaseall and then after closing all Cygwin processes a simple double
click on rebase from explorer (or calling from a .bat file) would be
sufficient to start it.


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: Perl Win32::Shortcut screws up fork

[Jason Tishler]

On Thu, Jul 07, 2005 at 11:50:38PM -0400, Christopher Faylor wrote:
> On Thu, Jul 07, 2005 at 08:24:20PM -0600, Eric Blake wrote:
> >But what was wrong with my idea of making rebaseall a #!/bin/ash
> >script?
> 
> You still couldn't run the script from bash since the dlls would still
> be loaded.  That would mean that you'd have to do something like:
> 
> c:\>ash rebaseall
> 
> (Currently rebaseall won't work as an ash script but the fix is
> trivial)
> 
> I guess that's better than nothing but I still think that just not
> rebasing the bash dlls is going to result in fewer mailing list
> complaints.

My inclination is to convert rebaseall to an ash script.

> OTOH, if we had some coordination between the maintainers of DLLs in
> the distribution we could reduce the need for rebase a lot.  I don't
> know if using --enable-auto-image-base would fix every problem but I
> suspect that it might help.

It will, but I have empirical evidence that DLLs need to be rebased with
some padding between them to guarantee that fork() does not fail.

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/

Re: Perl Win32::Shortcut screws up fork

[Christopher Faylor]

On Mon, Jul 11, 2005 at 08:43:07AM -0400, Jason Tishler wrote:
>On Thu, Jul 07, 2005 at 11:50:38PM -0400, Christopher Faylor wrote:
>> On Thu, Jul 07, 2005 at 08:24:20PM -0600, Eric Blake wrote:
>> >But what was wrong with my idea of making rebaseall a #!/bin/ash
>> >script?
>> 
>> You still couldn't run the script from bash since the dlls would still
>> be loaded.  That would mean that you'd have to do something like:
>> 
>> c:\>ash rebaseall
>> 
>> (Currently rebaseall won't work as an ash script but the fix is
>> trivial)
>> 
>> I guess that's better than nothing but I still think that just not
>> rebasing the bash dlls is going to result in fewer mailing list
>> complaints.
>
>My inclination is to convert rebaseall to an ash script.

Once again, let me point out -- that will not solve the problem.  You won't
be able to run the script from bash, for obvious reasons.

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/

rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Jason Tishler]

On Mon, Jul 11, 2005 at 10:08:33PM -0400, Christopher Faylor wrote:
> On Mon, Jul 11, 2005 at 08:43:07AM -0400, Jason Tishler wrote:
> >My inclination is to convert rebaseall to an ash script.
> 
> Once again, let me point out -- that will not solve the problem.  You
> won't be able to run the script from bash, for obvious reasons.

Understood.

On Mon, Jul 11, 2005 at 11:50:08PM -0400, Christopher Faylor wrote:
> OTOH, writing a mingw C program to do what rebaseall does wouldn't be
> *that* hard.

Agreed.

I would like to go with this approach except rewrite rebaseall as a
Cygwin C program with the Cygwin DLL as its only dynamic dependency.
However, given my limited free time, it may be a while before I can
develop a C-based rebaseall.  So, what is the best short-term solution?
Should I just release a new package with the following patch:

    http://cygwin.com/ml/cygwin/2005-07/msg00319.html

applied?

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

RE: rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Dave Korn]

----Original Message----
>From: Jason Tishler
>Sent: 14 July 2005 12:56

> On Mon, Jul 11, 2005 at 10:08:33PM -0400, Christopher Faylor wrote:
>> On Mon, Jul 11, 2005 at 08:43:07AM -0400, Jason Tishler wrote:
>>> My inclination is to convert rebaseall to an ash script.
>> 
>> Once again, let me point out -- that will not solve the problem.  You
>> won't be able to run the script from bash, for obvious reasons.
> 
> Understood.


  Out of curiosity, why isn't "exec /bin/sh.exe rebaseall" the solution to
this problem?


    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: rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Brian Dessent]

Dave Korn wrote:

>   Out of curiosity, why isn't "exec /bin/sh.exe rebaseall" the solution to
> this problem?

It would, presuming you meant /bin/ash.exe and the user hadn't removed
the ash package.  It would help if the rebaseall shebang was #!/bin/ash,
then you could type "exec rebaseall".

I suppose it's a good idea for a temporary work around, but it's
essentially the same thing as telling the user to open a regular windows
command prompt and run "ash rebaseall".  I guess we already require them
to shut down all cygwin processes and start a non-rxvt/xterm prompt, so
having them type more than a simple 'rebaseall' doesn't really add too
much burden.

I still think that getting --enable-auto-image-base working is the best
long-term solution.

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: rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Christopher Faylor]

On Thu, Jul 14, 2005 at 02:12:19PM +0100, Dave Korn wrote:
>----Original Message----
>>From: Jason Tishler
>>Sent: 14 July 2005 12:56
>
>> On Mon, Jul 11, 2005 at 10:08:33PM -0400, Christopher Faylor wrote:
>>> On Mon, Jul 11, 2005 at 08:43:07AM -0400, Jason Tishler wrote:
>>>> My inclination is to convert rebaseall to an ash script.
>>> 
>>> Once again, let me point out -- that will not solve the problem.  You
>>> won't be able to run the script from bash, for obvious reasons.
>> 
>> Understood.
>
>  Out of curiosity, why isn't "exec /bin/sh.exe rebaseall" the solution to
>this problem?

Because of the way exec works for top-level cygwin processes.

--
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: rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Dave Korn]

----Original Message----
>From: Jason Tishler
>Sent: 14 July 2005 12:56

> On Mon, Jul 11, 2005 at 10:08:33PM -0400, Christopher Faylor wrote:
>> On Mon, Jul 11, 2005 at 08:43:07AM -0400, Jason Tishler wrote:
>>> My inclination is to convert rebaseall to an ash script.
>> 
>> Once again, let me point out -- that will not solve the problem.  You
>> won't be able to run the script from bash, for obvious reasons.
> 
> Understood.
> 
> On Mon, Jul 11, 2005 at 11:50:08PM -0400, Christopher Faylor wrote:
>> OTOH, writing a mingw C program to do what rebaseall does wouldn't be
>> *that* hard.
> 
> Agreed.


  Once again, let me point out -- that will not solve the problem.  You
won't be able to run the mingw executable from bash, for obvious
reasons.......

   ;)

    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: rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Gerrit P. Haase]

Dave Korn wrote:
>>On Mon, Jul 11, 2005 at 11:50:08PM -0400, Christopher Faylor wrote:
>>
>>>OTOH, writing a mingw C program to do what rebaseall does wouldn't be
>>>*that* hard.
>>
>>Agreed.

>   Once again, let me point out -- that will not solve the problem.  You
> won't be able to run the mingw executable from bash, for obvious
> reasons.......

Isn't it possible to identify all cygwin processes, terminate them and
do stuff after that is finished, even if the process was started at the
bash prompt?


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: rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Dave Korn]

----Original Message----
>From: Gerrit P. Haase
>Sent: 14 July 2005 16:00

> Dave Korn wrote:
>>> On Mon, Jul 11, 2005 at 11:50:08PM -0400, Christopher Faylor wrote:
>>> 
>>>> OTOH, writing a mingw C program to do what rebaseall does wouldn't be
>>>> *that* hard.
>>> 
>>> Agreed.
> 
>>   Once again, let me point out -- that will not solve the problem.  You
>> won't be able to run the mingw executable from bash, for obvious
>> reasons.......
> 
> Isn't it possible to identify all cygwin processes, terminate them and
> do stuff after that is finished, even if the process was started at the
> bash prompt?

  Absolutely.  It should look for cygwin services as well.  I was thinking
of having a go at it in the next week or two.  I was also wondering whether
really it shouldn't be part of setup.exe (which I think came up in
discussion on -apps recently, but I wasn't following closely - have to go
check the archives).

    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: rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Dave Korn]

----Original Message----
>From: Dave Korn
>Sent: 14 July 2005 16:29

>   I was also wondering
> whether really it shouldn't be part of setup.exe 

[thinking out loud]

  D'oh, no, that's silly.  It should be part of rebase.exe; might as well
just patch the rebaseall script functionality right into it and have it look
at what name it's invoked under and/or a command-line switch.


    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: rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Gerrit P. Haase]

Dave Korn wrote:


>>>>On Mon, Jul 11, 2005 at 11:50:08PM -0400, Christopher Faylor wrote:
>>>>>OTOH, writing a mingw C program to do what rebaseall does wouldn't be
>>>>>*that* hard.

>>>>Agreed.

>>>  Once again, let me point out -- that will not solve the problem.  You
>>>won't be able to run the mingw executable from bash, for obvious
>>>reasons.......

>>Isn't it possible to identify all cygwin processes, terminate them and
>>do stuff after that is finished, even if the process was started at the
>>bash prompt?

>   Absolutely.  It should look for cygwin services as well.  I was thinking
> of having a go at it in the next week or two.  I was also wondering whether
> really it shouldn't be part of setup.exe (which I think came up in
> discussion on -apps recently, but I wasn't following closely - have to go
> check the archives).

I'm all against including it into the setup step.  I used rebase
exactly one time and then to test a not-yet-official version of MySQL
server which was linked against openssl.  I'll try this with openssl
and its fixed non default base and the latest perl which uses
auto-image-base to see if this resolves my MySQL problem.  Other than
this I never needed to use rebase so I don't think it should be a
default step when setting up Cygwin.  Finally we'll reach a point
where we run out of addresses anyway.



--
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: rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Dave Korn]

----Original Message----
>From: Gerrit P. Haase
>Sent: 14 July 2005 16:58

> Dave Korn wrote:
> 
> I was also wondering whether really it shouldn't be part of setup.exe

> I'm all against including it into the setup step.  [ ...] so I 
> don't think it should be a default step when setting up Cygwin.

  I didn't imply that; I was thinking it should be an optional extra step
that you specially have to request, but I was thinking that it would be
appropriate in setup because it is an install-time sort of thing to want to
do, and because setup.exe is independent of all cygwin dlls/packages.


    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: rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Christopher Faylor]

On Thu, Jul 14, 2005 at 07:55:52AM -0400, Jason Tishler wrote:
>On Mon, Jul 11, 2005 at 10:08:33PM -0400, Christopher Faylor wrote:
>> On Mon, Jul 11, 2005 at 08:43:07AM -0400, Jason Tishler wrote:
>> >My inclination is to convert rebaseall to an ash script.
>> 
>> Once again, let me point out -- that will not solve the problem.  You
>> won't be able to run the script from bash, for obvious reasons.
>
>Understood.

Yeah, I saw that you understood in a later thread.  I should have kept
reading.

>On Mon, Jul 11, 2005 at 11:50:08PM -0400, Christopher Faylor wrote:
>> OTOH, writing a mingw C program to do what rebaseall does wouldn't be
>> *that* hard.
>
>Agreed.
>
>I would like to go with this approach except rewrite rebaseall as a
>Cygwin C program with the Cygwin DLL as its only dynamic dependency.
>However, given my limited free time, it may be a while before I can
>develop a C-based rebaseall.  So, what is the best short-term solution?
>Should I just release a new package with the following patch:
>
>    http://cygwin.com/ml/cygwin/2005-07/msg00319.html
>
>applied?

How about if for now you just make it an ash script (meaning that it
relies on ash) and use your technique of checking for other cygwin
processes running?  If "we" are going to make this a program anyway,
eventually, then I don't mind just using your technique which is really
more foolproof than mine.  No matter how this is implemented, checking
that no cygwin processes are running before running rebaseall has to
be a good idea.

If we do make this a program, maybe it should just be an extension to
rebase itself:  "rebase --all" ?

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: rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Jason Tishler]

On Thu, Jul 14, 2005 at 04:01:08PM -0400, Christopher Faylor wrote:
> On Thu, Jul 14, 2005 at 07:55:52AM -0400, Jason Tishler wrote:
> >On Mon, Jul 11, 2005 at 11:50:08PM -0400, Christopher Faylor wrote:
> >> OTOH, writing a mingw C program to do what rebaseall does wouldn't
> >> be *that* hard.
> >
> >Agreed.
> >
> >I would like to go with this approach except rewrite rebaseall as a
> >Cygwin C program with the Cygwin DLL as its only dynamic dependency.
> >However, given my limited free time, it may be a while before I can
> >develop a C-based rebaseall.  So, what is the best short-term
> >solution?  Should I just release a new package with the following
> >patch:
> >
> >    http://cygwin.com/ml/cygwin/2005-07/msg00319.html
> >
> >applied?
> 
> How about if for now you just make it an ash script (meaning that it
> relies on ash) and use your technique of checking for other cygwin
> processes running?  If "we" are going to make this a program anyway,
> eventually, then I don't mind just using your technique which is
> really more foolproof than mine.  No matter how this is implemented,
> checking that no cygwin processes are running before running rebaseall
> has to be a good idea.

I'm glad we agreed.  I will implement the above.

> If we do make this a program, maybe it should just be an extension to
> rebase itself: "rebase --all" ?

Exactly!  Right after my previous post, I started to investigate
enhancing rebase to support rebaseall functionality.  I quickly realized
that this change would not require too much effort.

I will also enhance rebase so if it is invoked as rebaseall, then the
"--all" option is implied.

So, it sounds like we have short and long term plans.  Now, I just have
to work 'em.

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

RE: rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Dave Korn]

----Original Message----
>From: Jason Tishler
>Sent: 15 July 2005 12:27

> Exactly!  Right after my previous post, I started to investigate
> enhancing rebase to support rebaseall functionality.  I quickly realized
> that this change would not require too much effort.

  Reading the .gz files will probably be the worst bit of it!

    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: rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Jason Tishler]

On Fri, Jul 15, 2005 at 01:21:11PM +0100, Dave Korn wrote:
> ----Original Message----
> >From: Jason Tishler
> >Sent: 15 July 2005 12:27
> 
> > Exactly!  Right after my previous post, I started to investigate
> > enhancing rebase to support rebaseall functionality.  I quickly
> > realized that this change would not require too much effort.
> 
>   Reading the .gz files will probably be the worst bit of it!

Actually, the above was much easier than I thought.  I came up with the
following test program in just a few minutes:

    #include <stdio.h>
    #include <string.h>
    #include <zlib.h>

    int
    main(int argc, const char* argv[])
    {
        const char* filename = argv[1];
        const char* mode = "rb";
        const int size = 1024;
        char buffer[size];

        gzFile file = gzopen(filename, mode);
        while (gzgets(file, buffer, size) > 0)
        {
            int length = strlen(buffer);
            if (buffer[length - 1] == '\n')
                buffer[length - 1] = '\0';
            puts(buffer);
        }
        gzclose(file);
    }

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/

Re: rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Gerrit P. Haase]

Jason Tishler wrote:

> On Fri, Jul 15, 2005 at 01:21:11PM +0100, Dave Korn wrote:
> 
>>----Original Message----
>>
>>>From: Jason Tishler
>>>Sent: 15 July 2005 12:27
>>
>>>Exactly!  Right after my previous post, I started to investigate
>>>enhancing rebase to support rebaseall functionality.  I quickly
>>>realized that this change would not require too much effort.
>>
>>  Reading the .gz files will probably be the worst bit of it!
> 
> 
> Actually, the above was much easier than I thought.  I came up with the
> following test program in just a few minutes:
> 
>     #include <stdio.h>
>     #include <string.h>
>     #include <zlib.h>
> 
>     int
>     main(int argc, const char* argv[])
>     {
>         const char* filename = argv[1];
>         const char* mode = "rb";
>         const int size = 1024;
>         char buffer[size];
> 
>         gzFile file = gzopen(filename, mode);
>         while (gzgets(file, buffer, size) > 0)
>         {
>             int length = strlen(buffer);
>             if (buffer[length - 1] == '\n')
>                 buffer[length - 1] = '\0';
>             puts(buffer);
>         }
>         gzclose(file);
>     }


Cool!  You're the best ;)

$ ./readgz /etc/setup/bc.lst.gz
usr/
usr/bin/
usr/bin/bc.exe
usr/bin/dc.exe
usr/share/
usr/share/info/
usr/share/info/bc.info
usr/share/info/dc.info
usr/share/man/
usr/share/man/man1/
usr/share/man/man1/bc.1
usr/share/man/man1/dc.1

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: rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Dave Korn]

----Original Message----
>From: Jason Tishler
>Sent: 15 July 2005 22:00

> On Fri, Jul 15, 2005 at 01:21:11PM +0100, Dave Korn wrote:

>>   Reading the .gz files will probably be the worst bit of it!
> 
> Actually, the above was much easier than I thought.  

>     #include <zlib.h>

>         gzFile file = gzopen(filename, mode);


  Ooh, zlib does gz as well as zip!  Well you learn something new and
valuable every day!



    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: rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Christopher Faylor]

On Fri, Jul 15, 2005 at 07:27:27AM -0400, Jason Tishler wrote:
>So, it sounds like we have short and long term plans.  Now, I just have
>to work 'em.

Is it done yet?

Is it done yet?

Is it done yet?

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: rebaseall (was Re: Perl Win32::Shortcut screws up fork)

[Jason Tishler]

On Fri, Jul 15, 2005 at 10:18:26AM -0400, Christopher Faylor wrote:
> On Fri, Jul 15, 2005 at 07:27:27AM -0400, Jason Tishler wrote:
> >So, it sounds like we have short and long term plans.  Now, I just
> >have to work 'em.
> 
> Is it done yet?

Yes.

> Is it done yet?

Yes.

> Is it done yet?

Yes. :,)

Well, at least the short term one.

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/

Re: Perl Win32::Shortcut screws up fork

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Brian Dessent on 7/7/2005 7:15 PM:
> This is a problem with the new bash version 3.0, which is dynamically
> linked to the readline, libiconv, and ncurses DLLs:
> 
> The prior version of bash, 2.05b-17, is statically linked:

The problem is that bash 3.0 has grown so much since 2.05b that statically
linking it roughly triples its size, it is already the biggest shell in
/bin, and it cannot be hardlinked to save disk space without complicating
future bash upgrades.  I suppose it may be possible to compile two
versions - the full-featured dynamically-linked bash.exe for interactive
use, and the minimally-configured statically-linked sh.exe (keep all POSIX
features like aliases, but strip all extensions like array variables) for
scripts.

Looking at ./configure --help, that would mean using:
- --disable-arith-for-command --disable-array-variables
- --disable-bang-history --disable-cond-command --disable-cond-regexp
- --disable-debugger --disable-directory-stack --disable-disabled-builtins
- --disable-dparen-arithmetic --disable-extended-glob --disable-help-builtin
- --disable-multibyte --disable-net-redirections
- --disable-process-substitution --disable-progcomp
- --disable-prompt-string-decoding --disable-select
- --disable-separate-helpfiles --enable-static-link

I dunno - shipping a static /bin/sh without the full features of bash is
once again going to lead to questions of why a shell script doesn't always
work when people use bash extensions.

> 
> This presents a somewhat serious problem for the rebaseall script.  It
> can be modified to exclude cyg{intl-3,iconv-2,readline6,ncurses-8}.dll
> but that is not a very good solution, because it means they will not be
> rebased.  These DLLs unfortunately are used by lots of programs and I
> fear not rebasing them is a poor solution.

Or, you could make rebaseall a #!/bin/ash script, which would require that
we never kill ash from the distribution, while freeing you from bash's
dynamic linking.

> 
> I think we will require a statically linked bash, or some kind of
> trickery in the rebaseall script.  One potential way around this might
> be for it to output a .cmd file (or .bat under 9x, grrr) and then exec()
> $COMSPEC to run the commands.  This would have the advantage of not
> requiring any Cygwin DLLs in use during the rebase, but it sounds more
> error prone and complicated.

Eww - outputting a .bat to do your work - that doesn't sound very appealing.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFCzdg084KuGfSFAYARAqiFAJi2Iur/PfoQASpJpV0Ou0Jt11bNAJ4mAC3b
Su5fKRP0rqGdQcDlzvBXaw==
=RMy7
-----END PGP SIGNATURE-----

--
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: Perl Win32::Shortcut screws up fork

[Brian Dessent]

Eric Blake wrote:

> Or, you could make rebaseall a #!/bin/ash script, which would require that
> we never kill ash from the distribution, while freeing you from bash's
> dynamic linking.

Ah, hadn't thought of that.  This seems like the best short-term
solution, since it involves minimal changes.  The only potential problem
is that it requires that the user upgrade their 'ash' package, but they
would have to also presumably upgrade their 'rebase' package too
anyway.  I don't think anyone here wants to try to support people that
refuse to upgrade certain packages to 'Curr', so it's not a big deal.

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/