----- Original Message -----
From: "Bruce Dubbs" <[EMAIL PROTECTED]>
To: "LFS Developers Mailinglist" <lfs-dev@linuxfromscratch.org>
Sent: Monday, June 02, 2008 3:39 AM
Subject: Re: cp foo{,.bak} not always supported
> Bryan Kadzban wrote:
>
> > I strongly suspect the user was running either sh (which was not linked
> > to bash) or dash. I left that in there just in case they were running
> > it, but someone decided to "set +B" in one of the startup files. No, I
> > don't know why anyone would want to do this, but it is one possible
> > explanation for the failure. :-)
>
> My point is that this is an unusual user problem and it is not appropriate
for
> the book to address it.
>
Thank for all the answers.
I have not yet personnally tested and will not find time before a week.
We check for bash version in our master script and explicitely call bash
everytime.
But this master script call child packages scripts wich are makefile
scripts.
That's how LSFMake was...
I check in make-3.81 sources and /bin/sh is the default shell.
NEWS file say
* The `SHELL' variable is now never taken from the environment.
Each makefile that wants a shell other than the default (/bin/sh) must
set SHELL itself. SHELL is always exported to child processes.
This change was made for compatibility with POSIX.2.
To my understanding, just to workaround sh symlink not bash in Ubuntu, this
would imply we add in each of our makefile scripts
SHELL = /bin/bash
It has been reported that symlinking bash to sh fixe the issue.
This is consistent with my understanding, forcing make to use bash as
default shell.
Anyway what I will enlight is that "cp configure configure.bak"
by this experience has proven to be more portable than "cp configure{,.bak}"
Again I am not sure of the gain of this second syntax.
Gilles
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
