> 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
> > 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 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
--- Teun Burgers wrote:
>
> I overrode the PATH in my .bash_login, so the /usr/lib/lapack
> was not in the PATH, leading to cygblas.dll and cyglapack.dll not
> being found. Maybe an idea to put a remark on the importance
> of /usr/lib/lapack being in the PATH in octave-2.1.71.README.
OK. I'll
> > 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
James R. Phillips wrote:
Trial Cygwin packages are now available for octave-2.1.71. These packages are
dependent on the lapack-3.0 package now awaiting upload.
Looks good. A very nice contribution to the cygwin packages.
octave starts and seems to work, though I can't judge
that very well sin
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
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
> 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
> > > 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
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
> > >
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: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 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 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 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 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 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, 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
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 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 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
> 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 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
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 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
-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
Igor Pechtchanski schrieb:
On Sat, 2 Jul 2005, Eric Blake wrote:
When I'm at my home computer, my email is configured properly. But
when I'm elsewhere and have to use the piece-of-trash webmail interface
from my ISP, there is no way for me to control it. I have already tried
contacting comcast
28 matches
Mail list logo
