-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Changes from 3.0-3:
- - compiled against cygwin-1.5.18 (because of the new strtoimax, this bash
will not work with cygwin-1.5.17)
- - added preremove script that nukes /bin/sh if it is a version of bash
Corinna wrote:
> I'm ready when you're ready. D
On Jul 5 07:33, Eric Blake wrote:
> Corinna wrote:
> > I'm ready when you're ready. Do I need to add a postinstall script
> > or will your postinstall script care for everything?
>
> You should be able to use my postinstall script unchanged -
> /etc/postinstall/00bash.sh is a one-liner, although
On Jul 5 16:03, Corinna Vinschen wrote:
> 00ash.sh:
>
> #!/bin/ash
> link /bin/bash.exe /bin/sh.exe || link /bin/ash.exe /bin/sh.exe
>
> 00bash.sh:
>
> #!/bin/bash
> link /bin/bash.exe /bin/sh.exe || link /bin/ash.exe /bin/sh.exe
Erm... make that
00ash.sh:
#!/bin/as
On Tue, 5 Jul 2005, Corinna Vinschen wrote:
> This would also mean, you can get rid of your preremove script again.
> It seems somewhat dangerous to me anyway. I'd rather have a dangling
> /bin/sh.exe than none at all.
One possible problem, BTW, is that if a process that uses /bin/sh is
running
> In theory. I'm just wondering if your script is safe enough.
>
> test -x /bin/sh.exe || link /bin/bash.exe /bin/sh.exe
>
> The point is, if somebody wants to upgrade bash but not ash for
> whatever reason ("Gee, *nobody* needs ash, right?"), this person
> will get stuck with ash as sh. witho
On Jul 5 16:05, Eric Blake wrote:
> At any rate, you are probably right that a postinstall script may be
> all that is needed (no preremove script) if it ensures that /bin/sh
> always exists, and that if it is missing, is ash, or is an older version
> of bash, that it gets upgraded. But I would s
On Jul 5 18:22, Corinna Vinschen wrote:
> Cool with me (and thanks for preparing the ash script). If you want to
> release another test release using the above 00bash.sh script, please do.
>
> If you want to move bash out of test (this week or in August), just ping
> me and I'll release a new as
On Tue, 5 Jul 2005, Eric Blake wrote:
> > In theory. I'm just wondering if your script is safe enough.
> >
> > test -x /bin/sh.exe || link /bin/bash.exe /bin/sh.exe
> >
> > The point is, if somebody wants to upgrade bash but not ash for
> > whatever reason ("Gee, *nobody* needs ash, right?"), t
> On Tue, 5 Jul 2005, Eric Blake wrote:
> > #!/bin/bash
> > # If /bin/sh is missing, ash, or bash, upgrade it to the current bash.
> > case `/bin/sh.exe --version 2>&1
>
> FYI, this is missing a closing backtick and the "in".
Yep, you caught me typing on the fly instead of pasting a tested script
On Tue, 5 Jul 2005, Eric Blake wrote:
> > On Tue, 5 Jul 2005, Eric Blake wrote:
> > > #!/bin/bash
> > > # If /bin/sh is missing, ash, or bash, upgrade it to the current bash.
> > > case `/bin/sh.exe --version 2>&1
> >
> > FYI, this is missing a closing backtick and the "in".
>
> Yep, you caught me
On Jul 5 12:33, Igor Pechtchanski wrote:
> This isn't good enough -- I think you do need a preremove script. I've
> been trying to figure out why the no-preremove solution seems wrong, and
> came up with the following scenario: suppose bash is linked against an
> older libreadline, and the user u
On Jul 5 16:52, Eric Blake wrote:
> Should man/man1/sh.1 always belong to bash, or should I use readlink
> to ensure that I am only upgrading that link if it was to ash? In other
> words, for users smart enough to replace /bin/sh with zsh, are they
> also going to want to replace the /bin/sh manp
On Tue, 5 Jul 2005, Corinna Vinschen wrote:
> On Jul 5 12:33, Igor Pechtchanski wrote:
> > This isn't good enough -- I think you do need a preremove script. I've
> > been trying to figure out why the no-preremove solution seems wrong, and
> > came up with the following scenario: suppose bash is
On Jul 5 13:32, Igor Pechtchanski wrote:
> How about using a dummy executable that doesn't depend on anything and
> does nothing but print out some pre-defined message, and copying that to
> /bin/sh in the preremove script? That way, there will always be a
> (non-working, but who cares) /bin/sh..
On Tue, 5 Jul 2005, Corinna Vinschen wrote:
> On Jul 5 13:32, Igor Pechtchanski wrote:
> > How about using a dummy executable that doesn't depend on anything and
> > does nothing but print out some pre-defined message, and copying that to
> > /bin/sh in the preremove script? That way, there will
On Jul 5 13:55, Igor Pechtchanski wrote:
> On Tue, 5 Jul 2005, Corinna Vinschen wrote:
>
> > On Jul 5 13:32, Igor Pechtchanski wrote:
> > > How about using a dummy executable that doesn't depend on anything and
> > > does nothing but print out some pre-defined message, and copying that to
> > >
> > > This isn't good enough -- I think you do need a preremove script. I've
> > > been trying to figure out why the no-preremove solution seems wrong, and
> > > came up with the following scenario: suppose bash is linked against an
> > > older libreadline, and the user upgrades both bash and libr
> What message gets printed by bash when trying to invoke an executable
> whose dependent library can't be found? Even if the user does get
> the popup box, the bash script can still be made to treat that the same
> as /bin/sh not being installed, as its trigger to update to the current
> version
On Tue, 5 Jul 2005, Eric Blake wrote:
> > > > This isn't good enough -- I think you do need a preremove script.
> > > > I've been trying to figure out why the no-preremove solution seems
> > > > wrong, and came up with the following scenario: suppose bash is
> > > > linked against an older libread
On Jul 5 18:23, Eric Blake wrote:
> Or, I could first do "cygcheck /bin/sh.exe", and see if "Error: could
> not find .dll" appears in the output [...]
Or even just test -f...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader
> > Or, I could first do "cygcheck /bin/sh.exe", and see if "Error: could
> > not find .dll" appears in the output [...]
>
> Or even just test -f...
"test -f /bin/sh.exe" checks whether /bin/sh exists. From there,
"cygcheck /bin/sh.exe" and parsing the output for "Error: could not find"
checks w
On Tue, 5 Jul 2005, Igor Pechtchanski wrote:
> On Tue, 5 Jul 2005, Eric Blake wrote:
> > OK, then, does anyone else have ideas on how to determine if /bin/sh
> > is ash with resorting to running it, and without resorting to packing
> > an ever-increasing list of known md5sums of all prior versions
> > Should man/man1/sh.1 always belong to bash, or should I use readlink
> > to ensure that I am only upgrading that link if it was to ash? In other
> > words, for users smart enough to replace /bin/sh with zsh, are they
> > also going to want to replace the /bin/sh manpage and expect that
> > rep
On Jul 5 19:52, Eric Blake wrote:
> > > Or, I could first do "cygcheck /bin/sh.exe", and see if "Error: could
> > > not find .dll" appears in the output [...]
> >
> > Or even just test -f...
>
> "test -f /bin/sh.exe" checks whether /bin/sh exists. From there,
> "cygcheck /bin/sh.exe" and parsin
On Jul 6 02:01, Eric Blake wrote:
> > > Should man/man1/sh.1 always belong to bash, or should I use readlink
> > > to ensure that I am only upgrading that link if it was to ash? In other
> > > words, for users smart enough to replace /bin/sh with zsh, are they
> > > also going to want to replace
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Corinna Vinschen on 7/6/2005 1:19 AM:
> Looks basically good to me and I was going to use it for the 00ash.sh
> script. It just doesn't work on NTFS. The reason is that, as soon as
> the hardlink has been created, the script will fail to
On Tue, 5 Jul 2005, Igor Pechtchanski wrote:
> > > > > This isn't good enough -- I think you do need a preremove script.
> > > > > I've been trying to figure out why the no-preremove solution seems
> > > > > wrong, and came up with the following scenario: suppose bash is
> > > > > linked against a
On Tue, 5 Jul 2005, Corinna Vinschen wrote:
> Hang on, what about /usr/share/man/man1/sh.1 ?
>
> Right now it's a fixed symlink to ash.1. THe postinstall scripts should
> better symlink it to the shell's man page which really is sh after the
> script did its job, right?
Speaking of files/symlink
> Speaking of files/symlinks created in postinstall scripts -- perhaps we
> should come up with some unified mechanism for listing them. Some
> postinstall scripts use /etc/preremove/-manifest.lst.
>
> The reason it may be useful to have a common mechanism is that "cygcheck
> -c" could then use t
29 matches
Mail list logo
