| blmblm@myrealbox.com 2005-09-17, 9:04 pm |
| In article <op.sw78ubdenxtvbs@apeiron.home.lan>,
Enrique Perez-Terron <enrio@online.no> wrote:
>On Fri, 16 Sep 2005 12:30:12 +0200, blmblm@myrealbox.com
><blmblm@myrealbox.com> wrote:
>
>
>That was a good question.
Glad someone else thought so. :-)
>I was wondering if somebody would come forward and tell us how
>to get out of 'vi' in that situation, or at least what was
>happening. (NB, because I could not figure it out, either.)
Maybe someone (else) will. I just tried a few experiments, and ....
This is strange. I don't get the symptoms the OP reports; vi starts,
and I can edit the files as usual, but when I try to exit (:q),
I end up in a state in which I'm not back at the bash prompt (and
the terminal isn't responding to any input), but there don't seem
to be any processes running vi, xargs, etc., that could be killed to
recover from the situation. All that seems to work is to kill the
appropriate invocation of bash, with -9. Now, while vi is actually
running, I can suspend it, and then kill it, and that leaves me
back in a normal-seeming state. But trying to exit vi normally ....
This is not the behavior I remember from previous experience with
this problem, but I might be misremembering.
>Thinking a little more about it I tried this:
>
> $ find . -type f | xargs bash -c 'ls -l /proc/$$/fd'
> total 4
> lr-x------ 1 quique quique 64 Sep 17 04:55 0 -> /dev/null
> lrwx------ 1 quique quique 64 Sep 17 04:55 1 -> /dev/pts/1
> lrwx------ 1 quique quique 64 Sep 17 04:55 2 -> /dev/pts/1
> lr-x------ 1 quique quique 64 Sep 17 04:55 3 -> /proc/25822/fd
>
>It turns out that the victim of (er, the program run under)
>xargs gets its standard input redirected from /dev/null.
>
>How many times have I not been happy to use unix or linux, not windows,
>because under unix you can go inside things and fix them? But here
>is a big gaping hole in the othogonality and flexibility of unix:
>
>You cannot rewire the web of file redirections after a program has been
>started, from outside. You cannot take that running instance of vi,
>and rewire its standard input to come from another file. You cannot
>inject any data into that association of /dev/null with the running
>vi's file descriptor zero.
>
>Obviously, the authors of vi never thought of the possibility that
>its standard input could be /dev/null, so even they have put in a
>test and a warning that it is not a terminal (they have a test
>because they try to set the terminal in raw mode, and get an error
>return) - they never inserted code to exit the program
>if they got and end of file from the standard input. Or that is what
>I conclude from the OP's question.
Hm .... That sounds plausible. I'm getting a different behavior,
but I should note that "vi" on my system is really vim. But if it's
doing what you say vi is doing, I can't explain the behavior I'm
observing; it seems that instead everything's fine until the program
tries to -- close all files on exit??
>I guess that vi keeps trying to read from file descriptor
>zero even after getting zero bytes (which is the end-of-file
>indication). It should have been possible to rewire and get vi
>to work.
>
>Since that is not possible, the user will have to use signals.
>Open another terminal window, use "ps" to find the process id of
>the running "vi", and say "kill -TERM 1234" where 1234 is the
>process id. Anything better?
This is what I remember having to do in the past.
--
| B. L. Massingill
| ObDisclaimer: I don't speak for my employers; they return the favor.
|