Jay Buhner wrote:
The first problem is that the check for broken vi
attempts to write in the root directory instead of the
current directory. Changing "/nonexist-file" to
"./nonexist-file" fixes this.
Firstly, I don't think your change makes any difference -- we're
(deliberately) trying to read a non-existent file, not write it.
What problem did you encounter that made you think the current test
was broken?
Secondly, the test is like this:
if echo 'r /nonexist-file
q' | ex > /dev/null; then
broken
fi
and I note that GNU ex, for instance, fails this. Moreover, by my reading
of the POSIX spec for ex any POSIX-compliant ex should fail this test, because
it says:
# When any error is encountered and the standard input is not a terminal
# device file, ex shall not write the file or return to command or text
# input mode, and shall terminate with a non-zero exit status.
The problem we're trying to catch here is that some broken versions of vi
return that non-zero exit status if there's an error during an *interactive*
session (I think). We can hardly test for that in a configure script.
So I think we have two choices:
(1) remove this test and have the whatnowsbr code always ignore vi
return codes (this is what it is effectively doing now because the
test is broken)
(2) remove this test and treat vi like every other editor, and rely
on the FAQ entry for anybody who's still using hideous broken AT&T vi.
I think I'd vote for (2). Does anybody on this list actually have a
hideous broken AT&T vi? To test, run ex with no arguments and at the
':' prompt type 'r /nonexist' (should give you an error message) then
'q' (should quit). Then 'echo $?' and check the exit status was 0.
If it's not 0 your vi is broken...
-- PMM
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers