Igor Pechtchanski schrieb:
On Sat, 2 Jul 2005, Eric Blake wrote:
When I'm at my home computer, my email is configured properly. rantBut
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
-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.
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 you
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/ash
ln
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: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
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 ash
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?), this person
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/symlinks
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 21
FYI, this is missing a closing backtick and the in.
Yep, you caught me typing on the fly instead of pasting a tested script.
Should
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 21
FYI, this is missing a closing backtick and the in.
Yep, you caught me typing on the fly
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
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
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 libreadline to
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 of
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 libreadline, and the
On Jul 5 18:23, Eric Blake wrote:
Or, I could first do cygcheck /bin/sh.exe, and see if Error: could
not find libname.dll appears in the output [...]
Or even just test -f...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader
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
Or, I could first do cygcheck /bin/sh.exe, and see if Error: could
not find libname.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 whether
--- 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 fix
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 in
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/PKGNAME-manifest.lst.
The reason it may be useful to have a common mechanism is that cygcheck
-c could then use
23 matches
Mail list logo
