GNOME Bugzilla – Bug 121891
implement input from command line pipe
Last modified: 2011-10-05 18:45:44 UTC
Description of Problem: Even if in the README it's said that gedit accepts input pipe from command line, it seems it doesn't. I've made myself sure that there was Steps to reproduce the problem: 1. 'ls | gedit' in a non-empty directory Actual Results: Nothing change in gedit from starting it with a simple 'gedit'. Expected Results: gedit starts with a window in which there's the output of ls How often does this happen? Always
It works for me. Which version of gedit are you using? On which distro?
Mattia: ?
I think we should add a "-"command line parameter like in vi
Doesn't work for me either. The manpage says that gedit accepts pipes, it does not do anything when I give it a pipe. I'm using gedit 2.4.1 on Gnome 2.4.1 on Gentoo Linux 1.4 (x86).
cvs HEAD here: if I don't have any gedit windows open, ls | gedit doesn't work, but if I first run gedit in a terminal and then in another terminal I run ls | gedit then the second doc contains the output of ls just fine.
I can confirm that behaviour. If a gedit window does not already exist, the 'ls | gedit' just brings up a blank window.
I can also confirm this bug. This bug is still present in Gnome 2.6.0 running on Fedora Core 2 (i386). As a check, I enabled debugging via the "--debug" option on the command line, one with piped input to gedit and another with no input. I diff'ed the resultant files, which came back as identical. As mentioned before, if a prior copy of gedit is running and another initiated with piped input, behavior is as described in the man page.
for the record: it looks like the behavior is due to bad timings interactions. Anyway the current code is pretty hackish, probably the proper way to do it is using gtkiochannels which can integrate nicely with gtk main loop.
Created attachment 29502 [details] [review] Proposed patch
*** Bug 147256 has been marked as a duplicate of this bug. ***
here it is a first cut of how I think this should be properly implemented (with GIOChannels) NB: the patch works but it's just a prototype, among other things it probably leaks and doesn't remove all the old code. Suggestion are more than welcome on various issues: - how to do proper error reporting - should we emit DOCUMENT_LOADED signal? and LOADING? - when should we close the Channel? - how should this integrate with the Application server (it actually seems to automagically work, but...) - whatever comes tpyour mind
Created attachment 32748 [details] [review] prototype patch
*** Bug 160255 has been marked as a duplicate of this bug. ***
It is still there in Gnome 2.9.3. It is just opening a blank window in gedit.
I'm attaching a patch which makes use of GIOChannel to handle commandline pipes. However, I need refinement on the below issues: 1. To use option --read-stdin (or something liek this) to read commandline pipes or to use just "-" as vi does? 2. What needs to be done when user specifies the option (--read-stdin or just -) without any pipe, for example: gedit --read-stdin (or) gedit - 3. Comments are welcome to improve the code in patch.
Created attachment 36163 [details] [review] Patch to handle commandline pipes through GIOChannel
1. I think you should use "-" as vim 2. In this case you should wait for a timeout (for example 60 secs) and then give up. 3. I have not read the code.
Comment on attachment 36163 [details] [review] Patch to handle commandline pipes through GIOChannel santhu_: I'm marking the patch as needs work so that it doesn't show up in the unreviewed patches report. As I told you on irc I have not looked at it accurately, but from a quick look there are some things which need to be changed. - I don't like the use of a global variable to hold the data. - I don't like that we have gtk_main in an util function On a way less important level there is the fact that you are not using th preferred codying stile, in particulare "if( foo )" vs "if (foo)" it would be very helpful for reviewing the code properly if you could do the following two things: - provide the core function which retrieves the stdin dta separatelly, so that it is easier to read (ideally in a small test program, which takes stuff from stdin and fills a text view, but I guess I'm asking too much ;) - summarize the call chain (in other words who calls who) of the two cases (first gedit instance and following ones)
It is too late to fix this bug for gnome 2.10.0. I'm going to punt it.
Was this fixed in 2.12.0 or will we get it for 2.12.1?
Nope, all of our attention has been on http://live.gnome.org/Gedit_2fNewMdi and this issue has dropped off of our radar and it isn't going going to reach the top of our todo list anytime soon. If anyone wants to give it a try, he's more then welcome to do so: it would need to be almost a rewrite of the feature, given that both the file loading code changed in new_mdi and the use of bonobo-activation-server for IPC was dropped. (daniel, I took the liberty of adding ou to CC since you asked the question, feel free to remove yourself)
Created attachment 52506 [details] [review] prototype patch #2 As usual when I say something is way down on my todo list I end up poking at it :) Anyway, here is another prototype patch which implements part of the functionality for the new_mdi branch. The patch is incomplete because it still needs some work and in particular we need to find a way to make it work with bacon-message-connection. The patch adds the ability to gedit-document-loader to load files from stdin using GIOChannels. Minor things that still needs to be done: - check the code for correctness - do not leak the GIOChannel in the loader destructor - fix some assertions in the caller-side (gedit-document) about the uri beiing null etc - properly add api to gedit-window etc (the call chain goes like this: main -> gedit_window_new_tab_from_stdin -> gedit_tab_new_from_stdin -> gedit_doc_load_stdin -> gedit_doc_loader_load_stdin) Major issues: - we need to decide how to design the command line interface: the current "ls | gedit" doesn't cut it because stdin has to be checked every time. Vim use '-' to indicate stdin. However '-' gets eat by popt... as a temporary solution my patch uses --stdin, that is "ls | gedit --stdin" - We need to design a way to make it work when gedit is launched a second time: in that case the stdin has to be passed to the running gedit instance... the easy/ugly way is collecting the data client side and then pass it to the server but that sucks because it introduces buffering. The better way is to splice the stdin from the client to the server, using a pipe or some other UNIX gymnastic I don't know about :)
A way to solve the problem with the second instance of gedit could be creating a IPC fifo (with mkfifo), and sending its file name through the bacon. The server would only have to read from the fifo and close it when it's done. The client would pass the contents of its stdin to the fifo.
[some context for Jose's comment so that it's more clear if I read it again in the next weeks] Jose pointed out that the "server" (the running instance of gedit) cannot just read from stdin when a client is launched, since at least in theory there may be more than one client reading from stdin at the same time. Named fifo sounds like a viable solution if we stick[1] to bacon-message-connection. [1] the obvious alternative being D-BUS
https://launchpad.net/distros/ubuntu/+source/gedit/+bug/9054 is the Ubuntu bug about that.
*** Bug 361987 has been marked as a duplicate of this bug. ***
This bug remains in Ubuntu 7.04: Piping to gedit opens a gedit, but the document is completely blank.
This would be a VERY nice feature to have... would make gedit more accessible to the command line junky.
Hello, I am using Ubuntu 8.04 (gedit 2.22.1), and would love to see piping work. I find myself wanting to do "bzr diff | gedit" all the time, for example. Let me know if there is anything I can do to help. If it is documented that it should work this way, it seems rather important that it does. Thanks for the great text editor :]
Newly-created bugs.redhat.com bz# 494781 tracks this in fedora. ( http://bugzilla.redhat.com/show_bug.cgi?id=494781 ) If the functionality is not going to be a simple fix (which PBorelli's migration of this to "Enhancement Request" at the start of this year seems to indicate it's not) and may never actually materialize, could the GEdit documentation section that describes the feature be removed? I think it better manages user expectations to avoid teasing them with features that don't actually exist. The documentation can be put back when the functionality actually exists. :) (The section in question is "Features/Piping the Output of a Command to a File" in the GEdit manual. Standard yelp GNOME documentation, Utilities category.) ...Mind you, it's a nice change from the usual situation in software documentation: the functionality exists, but documentation on it doesn't catch up until months later. I think this case overcompensates a bit too far in the other direction, is all. ;)
*** Bug 593383 has been marked as a duplicate of this bug. ***
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Just to confirm -- this *does* appear to work now in Gnome 3.0.6. Still seems missing as of the Gnome 2.30.4 in Ubuntu 11.04 though, so presumably it didn't make it into any Gnome 2.x version?
nop, this was implemented for the 3.0 version.