This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: x-files must die: generate *config.h from the Makefile, etc
- To: zackw at Stanford dot EDU
- Subject: Re: x-files must die: generate *config.h from the Makefile, etc
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Thu, 22 Mar 2001 22:58:34 -0500 (EST)
- Cc: gcc-patches at gcc dot gnu dot org, grahams at redhat dot com
> From: "Zack Weinberg" <zackw@Stanford.EDU>
>
> On Wed, Mar 21, 2001 at 10:23:11PM -0500, Kaveh R. Ghazi wrote:
> > > On Wed, Mar 21, 2001 at 03:30:58PM +0000, Graham Stott wrote:
> > > > Zack
> > > >
> > > > On the trunk when ever your new mkconfig.sh script gets executed
> > > > I see one of the following messages.
> > > >
> > > > "mv: write error: Bad file descriptor"
> > > > "rm: write error: Bad file descriptor"
> > > >
> > > > I think it's because $output.T is still open when this bit of
> > > > the script get executed.
> > >
> > > It's not supposed to be; the line immediately above
> > >
> > > exec >&-
> > >
> > > is supposed to close it.
> >
> > Hmm, that rings a bell, some distant memory of a shell bug... Try
> > changing the line to:
> >
> > exec >& /dev/null
>
> Um, as far as I know >& is csh syntax (adopted by bash, but not
> portable). > /dev/null might work, however; we haven't done anything
> with stderr.
Oops, right you are. I think I meant exec > /dev/null. IIRC, there
was some sort of shell bug which triggered with closing stdout (>&-),
but redirecting stdout to /dev/null was a workaround. Not sure if its
relevant here, especially since I think bash was being used on linux.
--Kaveh
PS: you're using "echo >&2" in a couple of places. I think you should
be using "echo 1>&2" based on what you said above.
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions