PATCH: use pipe() instead of a temp file
Oliver Kiddle
selection through a command are not supported under GTK and thought I'd
have a look. However, I got side-tracked when looking at the code.
When commands are run from the output pane, is there a good reason why you
use mkfifo on a file in /tmp rather than calling pipe(2). I've attached
a patch to change this. This seems much cleaner to me, it avoids any
concern of security race conditions and there's no chance of old temp
files getting left behind in /tmp.
In the Output pane, running ls -l /proc/self/fd shows that open files
such as the pipe for talking to scite are left open. My patch closes
them all. You may prefer to set them to be close on exec at the point
where they are opened. I also point stdin to /dev/null instead of the
pipe which I thing is cleaner. Also, note that you should use _exit()
instead of exit() in the forked process. I also wonder whether it would
be better to use dup2() to fill out stdin/out/err but am not sure that's
fully portable.
Any pointers to help me work out how to get the command.input,
command.replace and command.quiet working on GTK would be good. Note
that I don't have access to Windows to verify exactly how they
work there. Presumably, stderr gets sent to the output pane.
Sorry if this isn't the right place to send patches.
Thanks
Oliver
Neil Hodgson
> When commands are run from the output pane, is there a good reason why you
> use mkfifo on a file in /tmp rather than calling pipe(2).
Its a while back and there were multiple contributors but I think
the main issue was portability. There are some platforms that support
GTK+ with incomplete POSIX compatibility and on these a temporary file
could be used rather than a fifo. I haven't received any OpenVMS
patches recently so I suspect that support has now rotted away. I'd
expect that cygwin users would use the native Windows SciTE but maybe
a cygwin/GTK+ version interacts better with cygwin tools.
It may be worth the potential cost of incompatibility so anyone
using OpenVMS or cygwin (or similar like QNX) should have a look at
this now.
Swapping the I/O redirection approach for a pty would allow better
interaction with subprocesses but again raises portability and
compatibility issues.
> Any pointers to help me work out how to get the command.input,
> command.replace and command.quiet working on GTK would be good. Note
> that I don't have access to Windows to verify exactly how they
> work there. Presumably, stderr gets sent to the output pane.
You can search the code for jobQuiet and repSelBuf.
> Sorry if this isn't the right place to send patches.
The feature request tracker is at
http://sourceforge.net/tracker/?group_id=2439&atid=352439
The benefit with the tracker is that other people can use your
patch and improve on it even if I don't like it. OTOH, you probably
still want to talk about it here as relatively few people are
subscribed to the tracker.
Neil
Oliver Kiddle
> Its a while back and there were multiple contributors but I think
> the main issue was portability. There are some platforms that support
> GTK+ with incomplete POSIX compatibility and on these a temporary file
> could be used rather than a fifo. I haven't received any OpenVMS
know works on some of these more unusual platforms and I can see
nothing
to indicate that pipe() wouldn't work for QNX, Cygwin and OpenVMS.
Given
that a named pipe requires POSIX symantics on the file system, I'd
generally expect pipe() to be more portable than mknod()/mkfifo().
pipe() really is a very ancient system call.
> Swapping the I/O redirection approach for a pty would allow better
> interaction with subprocesses but again raises portability and
> compatibility issues.
to
do portably. As it is, the output pane (and in particular, the ability
to type commands into it) is the one feature of scite which to me
looks
like a feature that isn't really a text editor feature. pty support
would be a big step towards it having an embedded terminal emulator.
Oliver
D.G.
more robust. I am using a workaround to allow myself to get input/
output with an external terminal and I send the stderr from the
program to SciTE so I get the yellow (x) next to lines when you click
on errors feature. I'm replying to you about this because I was
wondering if my workaround would be affected by your patch. Don't mind
the extra comments please as they are for anybody else who might come
across this.
Right now I do the following for a language such as ruby:
I change the go command in Options->Edit properties->Open
ruby.properties and near the bottom I change the line:
---------
if PLAT_GTK
command.go.*.rb=ruby $(FileNameExt)
---------
to:
=-=-=-=-=-=-=--=
if PLAT_GTK
command.go.*.rb=xterm -hold -e /usr/bin/sciteredirection_for_ruby.sh $
(FileNameExt)
-=-=-=-=-=-=-=-=
I then run the following shell script saved(and chmod 755) to /usr/bin/
sciteredirection_for_ruby.sh:
=+=+=+=+=+=+=+=+=+=+
#! /bin/bash
ruby $1 2> /proc/$PPID/fd/2
=+=+=+=+=+=+=+=+=+=+
I use xterm because konsole doesn't play well with the output terminal
(it doesn't cease its input immediately, SciTE takes a while to figure
out it has exited)
If you know a better way, or a more portable way for people who work
on windows, I'd be glad to know. I hope this helps somebody
somewhere. I looked at the mailing list for other solutions, but
perhaps I didn't do an exhaustive enough search.
Thanks for your time!
> 4KViewDownload
Oliver Kiddle
> It is excellent that the work you are doing will make the output panel
> more robust. I am using a workaround to allow myself to get input/
> output with an external terminal and I send the stderr from the
> program to SciTE so I get the yellow (x) next to lines when you click
> on errors feature. I'm replying to you about this because I was
> wondering if my workaround would be affected by your patch. Don't mind
> the extra comments please as they are for anybody else who might come
> across this.
be there, it'll just be a pipe instead of a named pipe.
That's a nice trick of yours.
You can actually get rid of your external shell script. The following
works for perl:
command.go.*.pl=xterm -hold -e sh -c "exec perl $(FileNameExt) 2>/
proc/$$/fd/
2"
The intermediate sh in there is needed for the redirection because
xterm doesn't do that. Anyone know if a perl/ruby option can be used
to open the file and avoid the extra shell? Note that $$ is expanded
by the earlier shell (the parent of xterm) so the use of double quotes
(as opposed to single) is important. Using exec is an optimisation
that
avoids a fork. Some shells such as zsh will do that automatically. You
can't exec the xterm and use $PPID, mainly because xterm is setuid
root
so you can't access it's file descriptors.
Note that it is also possible to run the following in the output
terminal:
xterm -hold -e "script -f /proc/$$/fd/1"
That gives you a terminal where all the output is copied back to the
scite output pane. It makes the lack of ANSI escape sequence support
(or even backspace characters) quite obvious. You can help a bit by
using env to set TERM to dumb. You could even use a zsh or ksh script
with a coprocess to do further clever tricks but it's probably a
better
use of time to hack things in the C++ code.
> If you know a better way, or a more portable way for people who work
> on windows, I'd be glad to know. I hope this helps somebody
> somewhere. I looked at the mailing list for other solutions, but
> perhaps I didn't do an exhaustive enough search.
proc
won't work on many Unices. Apart from the -hold option to xterm this
does work on Solaris. The only really portably solution would be to
have
a pseudo-tty for the output pane and support escape sequences.
Basically, reimplement xterm in scite. I don't really like that idea.
One idea, if anyone interested in coding the C++ is still reading,
would
be to open two separate pipes for stdin and stderr. stdin and stderr
could then be coloured differently and there could be options for
hiding/showing one or the other, perhaps similar to the editor pane
folding for lines that aren't mixed.
Oliver
Neil Hodgson
> When commands are run from the output pane, is there a good reason why you
> use mkfifo on a file in /tmp rather than calling pipe(2). I've attached
> a patch to change this.
I will commit this now although I think there is a some chance it
will break Cygwin or OpenVMS.
> One idea, if anyone interested in coding the C++ is still reading,
> would
> be to open two separate pipes for stdin and stderr. stdin and stderr
> could then be coloured differently and there could be options for
> hiding/showing one or the other, perhaps similar to the editor pane
> folding for lines that aren't mixed.
If you separate these out there is more chance of the two streams
being rendered out of order due to buffering.
If anyone is using OpenVMS or Cygwin could they please check the
current CVS code. It would also be useful to know if all the OpenVMS
code (#ifdef __vms) is still needed as I would expect OpenVMS to have
improved compatibility with Linux over time.
Neil
Oliver Kiddle
> > When commands are run from the output pane, is there a good reason why you
> > use mkfifo on a file in /tmp rather than calling pipe(2). I've attached
> > a patch to change this.
help fix it if that can be done without simply reverting to the
temporary file.
> > be to open two separate pipes for stdin and stderr. stdin and stderr
> > could then be coloured differently and there could be options for
> being rendered out of order due to buffering.
what gdk_input_add() does underneath but would assume it doesn't leave
stuff hanging around in the buffer long and that it can watch multiple
descriptors concurrently (like select()). In practice, it's rare for
Unix commands to output less than a full line to stderr. Mixed up
output is more often due to having two commands running in parallel
in which case you might actually improve the readability of the
output.
Oliver