x-files must die: generate *config.h from the Makefile, etc

[Zack Weinberg]

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.

>  > What system is this, and can you trace mv or rm and see which system
>  > call is failing?
>  > zw
> 
> Yes, what platform?  By any chance, is your build directory is NFS
> mounted?

I can't think what NFS would have to do with it... unless this is the
'silly rename' thing, which ought to have produced "Stale file handle"
when we later (hypothetically) tried to modify the file some more...

The GNU coding standards should require that error messages reporting
system-call failures include the name of the failing system call,
unambiguously.  'write error' is way too vague.  mv might call write(2)
if it thought it was moving a file across devices; rm oughtn't ever to
need to.  In fact, rm oughtn't ever need to open the file it's
deleting.

Feh.

zw