Mail Archives: djgpp/1997/11/02/08:01:16
On Sat, 1 Nov 1997, Kris Heidenstrom wrote:
> But, info seems to do some weird things. Here is what I have tried:
Thank you for this comprehensive and accurate report! Using it, it
took me about 10 seconds to find out the reason for this misbehavior.
> If there is no 'man' program, then I get the symptoms that I described
> earlier - the message 'Bad command or file name' is displayed, then the
> machine appears to hang (but can be broken with Ctrl-C) for 15 seconds
> (this is on a Pentium 75), then starts up with a beep, with the message
> 'there is no menu item no_such_subject in this node'.
>
> So the question is, why was it hanging for 15 seconds.
It's not hanging, it's waiting for exactly 15 seconds. Here's why.
When Info doesn't find the topic you pass to it on the command line in
the Info files directory, it invokes the `man' command via a pipe.
`man' is expected to write the contents of the appropriate man page to
its standard output, which is redirected to a pipe, and Info reads the
other end of that pipe.
But Info is originally a Unix program, where programs connected by a
pipe run asynchronously. So it might happen that by the time Info
begins reading its end of the pipe, `man' didn't write its output yet.
So Info waits for 15 seconds (see `read_from_fd' function on `man.c'
in the Info sources) by calling the `select' library function. That
call to `select' will return immediately if some input is available
from the pipe file handle; otherwise, it will wait for it to become
available, or for 15 seconds, whichever happens first. When there's
no `man' program, there's no output, so it waits.
When I ported Info, I left that wait alone, since under the normal
circumstances it would never need to wait, and I usually prefer to
change the original sources as little as I can. I have a `man' clone
for a long time, so I guess I never tested this without a `man'
program somewhere on my PATH. So much for my testing standards...
> Info appears to create the temporary file and invoke the command
> interpreter with this inappropriate option, only if it doesn't
> find the 'man' command itself. If 'man' is present in djgpp/bin,
> info invokes man directly (changing COMSPEC to my dumper program
> doesn't have any effect).
The reason that COMMAND.COM is called is that Info is instructed to
invoke the command "man". The standard behavior of the DJGPP library
function `system' (called internally by `popen') is to look for "man"
either verbatim or with all known executable extensions (.exe, .com,
.bat, and some others) either in the current working directory or
along the PATH. If it doesn't find any such program, then it calls
the shell, assuming that this might be some built-in command, or that
the shell has its own private ways to store scripts (not on PATH).
A simple solution that will avoid calling the shell would be to change
"man" to "man.exe". (But this will defeat systems which have `man' as
a batch file or a shell script.)
This should be fixed when the next version of Texinfo is ported to
DJGPP. There should be no futile waiting on MS-DOS, or at least there
should be a message to the effect that it's waiting.
> To do this, I changed my COMSPEC environment
> variable so that it pointed to a small program which dumps its program
> segment prefix (including the command tail) and exits. This showed me
> that the command interpreter was being called up with a command line of:
>
> c:/s/djgpp/tmp/dj300000
This has nothing to do with the original problem. What you see is the
artifact of your testing method, whereby you point COMSPEC to an
arbitrary file name. DJGPP's `system' function knows about
COMMAND.COM and several other names which are typical for DOS shells,
and it correctly translates the forward slashes to backslashes and
adds the "/c" switch when COMSPEC points to one of these names.
Otherwise, it assumes that the shell is of the Unix-style variety, and
that it can grok forward slashes, and calls it in a way that Unix
shells can handle. If you named your substitute shell COMMAND.COM, or
4DOS.COM, or NDOS.COM, you would have seen that it is called
correctly. (This is, btw, explained in the libc reference; type
"info libc alpha system" and read there.)
> I've grepped the info source code for system( and spawn*( but found
> nothing. Perhaps you can tell me where to look.
gnu/texinfo3.9/info/man.c, look for the call to `popen', and the
`read_from_fd' function further down.
- Raw text -