Mail Archives: djgpp-workers/2001/08/04/10:12:36
> From: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
> Date: Sat, 4 Aug 2001 23:16:10 +1000
>
> One step at a time. This time I have come up against issues with /dev/null
> permissions. It's getting late so I thought I would ask and start
> testing/debugging/building again in the morning. Any ideas on where to
> start?
>
> My thoughts are:
> a) Could be a bash issue.
> b) Search the mail archives to see where /dev/nul support was added and
> start searching from there.
It's not a Bash issue, it's an issue with one of our library functions
called when we redirect output: some of them fail on Windows 2000 when
the target is the null device (or maybe any device they emulate for
DOS).
How do I know? Simple: Charles tried, at my request, to run a simple
Makefile:
all:
djecho foo > nul
This failed ("djecho foo >> nul" succeeded). Since this doesn't
involve Bash, we now know that the redirection done by `system' (which
is what Make calls when it sees this command) is enough to trigger the
problem.
So here's a suggestion for attacking this nuisance: look at system.c,
where it handles redirection (search for "open (f_out"). Then see
which library function -- open, dup, or dup2 -- fails. Finally, step
into the failing function with a debugger and see what exactly fails
there (or in one of the functions it calls), and why. You will
probably need to paste the suspect function's source into system.c and
compile with -g to make it possible to debug the library functions.
Note that system.c already has a convenient provision for testing
itself: just compile with -DTEST and you have a test program.
- Raw text -