Mail Archives: cygwin/2006/04/27/14:02:45
Webb Roberts <webb.roberts <at> gtri.gatech.edu> writes:
>
> I just updated my cygwin install.
>
> on running /bin/sh -login, I got the following message:
>
> /bin/cp: cannot remove `/bin/sh.exe': Permission denied
Not the nicest thing to have a random error message appear on stdout
during a login, especially if it would interfere with ssh or other
remote protocols. But you at least still have a working /bin/sh
(albeit out-of-date, or the error wouldn't have printed).
>
> Looks like the error is coming out of /etc/profile.d/00bash.sh: the part
> where it's trying to update /bin/sh.exe via a copy in the midst of
> running profiles:
>
> /bin/cp -fpuv /bin/bash.exe /bin/sh.exe 2>&1 >> /var/log/setup.log.full
Bah - and I'm the bash maintainer, so I should know better when writing
a shell script! Not only that, but I've corrected other people on this
very list for doing redirections in the wrong order! [/me goes and
crawls in a hole]
>
> 1. Isn't it a little strange to have this done on user time every time
> users run profiles?
No - because once the update has been done successfully, /bin/sh is no
longer out of date, so the profile script short circuits without any
further attempt to update /bin/sh. Once up-to-date, the time spent by
/bin/test to check timestamps on every user's login is minimal compared
to the time wasted on this list for bug reports that /bin/sh was
altogether missing when people had upgrade problems that prevented the
bash postinstall script from running.
> 2. If the redirect and the file append were reversed, I'd never see the
> error; it would go straight to the logs. As it is, nothing goes to the
> logs.
Yep. And the next release of bash (expect it in the next day or two)
will fix this heinous bug.
> 3. Once I killed all my /bin/sh processes, and ran /bin/bash -login, the
> copyover happened OK.
Yep - Windows won't let you replace an in-use file, which is why you
were getting permission denied errors on subsequent shells. When you
upgrade a cygwin installation, it is MUCH better if you don't have any
cygwin processes, including /bin/sh, running at the time.
> I'm just a freak trying to stick to sh.
But in cygwin, /bin/sh IS bash (by default). The only difference is that
bash turns on POSIX behavior by default when invoked as sh instead of bash.
> 4. Should this code be running when I'm under /bin/sh? Looks like it's
> bash-specific; I'd expect the default profile code for sh to be sh-specific.
The code should be run for EVERY bourne-style login shell (sh, ash, bash,
ksh, pdksh, zsh), because experience has shown that cygwin without
/bin/sh installed is pretty much broken (think system(2), for example).
In fact, I might even try to make a counterpart 00bash.csh profile script
that runs for a tcsh login shell, now that I think about it. When cygwin
swapped from /bin/sh being ash to being bash, I wanted to make sure that
everyone has a working /bin/sh. But I also wanted to make sure that
advanced users who don't want bash as their /bin/sh (for whatever reason)
can have their wish too, by touching /bin/sh to have a timestamp further
out into the future so that the upgrade script will not attempt to install
bash in place of whatever shell you prefer as your own /bin/sh.
I will also try to clean up the profile script to short-circuit when you
are running /bin/sh instead of /bin/bash (obviously, if you are in sh, it
is not missing, which is the worst problem the profile script tries to
prevent; and since attempts to upgrade it must fail, all I can do is
let you be aware that your /bin/sh may be out-of-date).
>
> Thanks!
> Webb
Thank you for catching the bug in my postinstall script.
--
Eric Blake
volunteer cygwin bash maintainer
--
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/
- Raw text -