This is the mail archive of the
automake@gnu.org
mailing list for the automake project.
Re: Running ./config.status
- From: Ralf Corsepius <rc040203 at freenet dot de>
- To: Noah Misch <noah at cs dot caltech dot edu>
- Cc: Autoconf Patches List <autoconf-patches at gnu dot org>,Automake List <automake at gnu dot org>
- Date: Fri, 04 Feb 2005 14:49:29 +0100
- Subject: Re: Running ./config.status
- References: <20050202135654.GA13165@matsrv.math.cas.cz><873bwdqs0f.fsf@penguin.cs.ucla.edu><20050204075351.GA8958@math.cas.cz><20050204131037.GB545@orchestra.cs.caltech.edu>
On Fri, 2005-02-04 at 05:10 -0800, Noah Misch wrote:
> On Fri, Feb 04, 2005 at 08:53:51AM +0100, Stepan Kasal wrote:
> > - cd $(top_builddir) && ./config.status $(subdir)/$@
> > + cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@
>
> > The question: Why does Automake add "$(SHELL)" to the command?
>
> If you believe `man perlrun', some systems do not respect #! and start all
> scripts under csh.
I assume, the systems they refer to, actually are victim to the length
limitations some systems impose on "!# " lines.
Unlike shells, which typically are found "short dirs"
like /bin, /usr/bin, /usr/local/bin etc., perl installation tend to be
installed to "obscure directories" like
/nfs/myos/mymachine/home/username/local/perl/somewhere/bin/perl
and therefore perl scripts are much likely to suffer from the
limitations.
So I'd guess, perlrun is drawing incorrect conclusions.
> $(SHELL) ./script defends against that.
Theoretically, the "#!" limitations also could hit autoconf scripts,
esp. if autoconf is heading towards choosing "suitable shells on $PATH"
instead of using standard shells.
So adding $(SHELL) might not be wrong.
Ralf