[Nano-devel] Patch to files.c

[David Benbennick]

Here is another seg fault fix.  It includes the patch I sent at 3:14.  
Again with files.c,v 1.155, do
        nano -z
        ^R     (Read File)
        ^X     (Execute Command)
        bash
Of course it freezes.  Now type ^Z to stop nano, then fg from the
shell to resume nano.  You get
        nano -z
        stdin: Interrupted system call
        Segmentation fault
The attached patch fixes the seg fault.  The problem was that read_byte()
was reporting it had read 1 byte even when the read() had an error.

Note that the same seg fault happens for any I/O error.  For example,
doing "nano /proc/<certain-PIDs>/mem" caused a seg fault for some PIDs,
and doesn't with the patch.

I also changed "char input[2];" to "char input" in read_file,
since only the first character of that array was ever used.

Finally, in open_pipe() I replaced
        execl("/bin/sh","/bin/sh","-c",command,0);
with
        execl("/bin/sh","sh","-c",command,0);
The second argument to execl is supposed to be the executable file name,
not the whole path.


There are two issues here that still could be fixed.

* In files.c:read_byte(), there is a call to perror.  perror is
used nowhere else in nano.  I guess it should be replaced by
something like
        statusbar(_("Error reading file: %s"), strerror(errno));
But there are plenty of other system calls, such as execl, wait, dup2,
close (and others), for which we should report errors to stderr and not to
the status bar (because the user wouldn't have any clue why dup2 is
complaining of too many file descriptors).  Thus, there should be a
generic function, call it nperror, that handles the necessary Curses
calls.  Any opinions on that?


* Perhaps we can fix the silly bash-freezing thing.  Here are two
ideas.

First idea: Change the code so that read_file() always reports I/O errors.  
Then make open_pipe() kill the forked process if there is a read error.  
Then if you freeze nano by running bash, you can simply ^Z then fg to get
it back.  Of course, this only works if you use "nano -z".

Second idea: before doing "wait(&fork_status);" in open_pipe(), change the
SIGINT action from SIG_IGN to a routine that kills the fork.  Thus, typing
^C will unfreeze nano in that case.



David

26mar05:50.diff
Description: Text document