gedit does not read from a pipe

Some additional information about the problem. It seems to be dependant on the
colors used by the shell. When I do

ls -l | gedit

gedit opens with an empty buffer. But if I do

ls -l | cat | gedit

gedit opens a buffer filled with the output of ls -l, as expected. Can this
filtering step be avoided ?

Neither of those pipelines work for me

(In reply to comment #2)
> Neither of those pipelines work for me

I'm using plain old warty, and the second pipeline worked when I posted it. Now
it fails miserably.

Can something updated in between have broken it ?

I've opened a bug upstream about this:
http://bugzilla.gnome.org/show_bug.cgi?id=160255

Corrected upstream bug report which contains the first draft of a patch that
apparently solves the problem::
http://bugzilla.gnome.org/show_bug.cgi?id=121891

This still seems to be an issue, gedit 2.14.0-0ubuntu1 (latest Dapper). Can anyone else confirm this?

Absolutely, "ls|gedit" still fails (opens an empty document), even when ls is called without the usual alias wich translates to "ls --color=auto".

Indeed, it fails (= opens an empty document) under gnome-terminal and rxvt. My version is 2.14.2 , I'm using Dapper.

+1 here... I'm using Edgy, with:

- gnome-terminal 2.16.1
- bash 3.1.17(1)
- gedit 2.16.1

All of the following open an empty doc:

ls | gedit
ls -l | gedit
ls | cat | gedit
ls -l | cat | gedit

It doesn't work here (Edgy), I tried
diff -bla bla bla | gedit

Still doesn't work in Feisty.

Doesn't work in gutsy either.

when I type:

ls -l | gedit

I get the following errors first:

(gedit:8745): atk-bridge-WARNING **: AT_SPI_REGISTRY was not started at session startup.

(gedit:8745): atk-bridge-WARNING **: IOR not set.

(gedit:8745): atk-bridge-WARNING **: Could not locate registry

Then gedit opens with an empty buffer.

I also have the same problem on my Ubuntu Gutsy install

2.6.22-14-generic

Same thing here. Tried: "ls -l | gedit" on latest gutsy.

you can do it like this:

ls -l > - | gedit -

On Feb 12, 2008 3:44 PM, descent <email address hidden> wrote:

> you can do it like this:
>
> ls -l > - | gedit -

Yes, but in this case this works because "-" is a physical file. So you end
up with a file named "-" in the folder (and probably in the 'ls -l' output,
too), which could be disturbing for some users (especially since 'rm -'
doesn't work, you have to issue 'rm "-"').

You can actually do this properly, like: ls -l >/tmp/dummy | gedit
/tmp/dummy (or /dev/shm/dummy, if available), but reading from a pipe would
be far nicer.
--
Arnold

Hello, I would just like to add that this also affects Hardy.

Also I appreciate the workaround Igor, but it is unwieldy and assumes you have write access to the working directory, which is not always going to be the case.

The upstream bug report seems somewhat stagnant; a patch or two is provided but from what I gather they are too old to be applicable to the current codebase.

Any reason this is 'Wishlist' if the documentation explicitly mentions piping as a feature (Gedit Manual / Programming Features):

    "You can use gedit to pipe the output of a command to a text file. For example, to pipe the output of an ls command to a text file, type ls | gedit, then press Return. The output of the ls command is displayed in a new text file in the gedit window."

It seems like either this bug shouldn't be wishlist (I assume Low instead), or there should be another bug to the effect of "gedit documentation says it can read from pipes although it can't"

marking it as low then.

This does not work on hardy either tried

ls -l | gedit
ls -l | cat | gedit

both render an empty document.

This would be a killer feature.

A 2004 bug is still not fixed? This was driving me mad as I read that gedit can read from pipe, only to find this bug. It should be fixed in Intrepid at the very latest.

I'd always tried
dmesg | gedit
dpkg -l | gedit
(etc...)

Supersonicdarky, the bug is a low priority one and there's also a couple of patches upstream that need to be tested and probably need some more work and you're welcome to try any of those options but just complaining is not going to solve anything, moreover it only create noise in the bug mail, so please if you want to comment on such bugs do it in the right way and not just complaining, thanks in advance.

Still doesn't work! (gedit 2.26.1 on Debian squeeze)
5 years anniversary closing!!!

Neither work for me also:

ls -l | gedit
ls -l | cat | gedit

gedit 2.26.1 on Ubuntu 9.04

Neither work for me:

ls -l | gedit
ls -l | cat | gedit

gedit 2.26.1 on Ubuntu 9.04

The bug was sent upstream and it's confirmed there as well, there's no need to re-re-re-re- confirm the issue with comments here, there's a nice button on the top of this reports that says "affects me too" please press that and subscribe to the report, commenting only generates bug noise, if you want this to be fixed then provide a patch. Thanks.

I love you too, sorry for the inconveniences.
Sometimes we are needed to recieve RTFMs to learn.
Thank you anyway.

On Fri, Aug 21, 2009 at 3:12 PM, Pedro Villavicencio<email address hidden> wrote:
> The bug was sent upstream and it's confirmed there as well, there's no
> need to re-re-re-re- confirm the issue with comments here, there's a
> nice button on the top of this reports that says "affects me too" please
> press that and subscribe to the report, commenting only generates bug
> noise, if you want this to be fixed then provide a patch. Thanks.
>
> --
> gedit does not read from a pipe
> https://bugs.launchpad.net/bugs/9054
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in gedit - Light-Weight Text Editor for Gnome: Confirmed
> Status in “gedit” package in Ubuntu: Triaged
>
> Bug description:
> The GNOME text editor, gedit, has a cool and documented feature (by documented I
> mean they tell about it in the man page) which allows it to read input from a
> pipe. For example 'ls -lR | gedit' allows one to open a new buffer in gedit and
> populate it with the output of 'ls -lR'.  This does not seem to work in Ubuntu,
> and thus breaks some of my working habits. Would it be possible to enable this
> feature in future releases ?
>
> http://bugzilla.gnome.org/show_bug.cgi?id=121891: http://bugzilla.gnome.org/show_bug.cgi?id=121891
>

The man page included in Karmic for gedit 2.28.0 removes the reference to gedit being able to read from a pipe, so I think this bug should become a wishlist one again.

On the Sun terminal I have at work, it works perfectly. I copy-paste the
information about the platform in case it is useful.

Operating System: SunOS Release 5.10 Generic_142900-02
Desktop: CDE 5.10, X11 Version 6.6.2

@Jc Really? Thats, weird. Maybe it somehow got implemented when Sun ported gnome to Solaris.

Just an update, references to reading from a pipe is no longer in the gedit man page as of Karmic, but it still is in the yelp docs.

This is fixed upstream now

Polaris:
you wrote "You can actually do this properly, like: ls -l >/tmp/dummy | gedit
/tmp/dummy (or /dev/shm/dummy, if available), but reading from a pipe would
be far nicer." i believe you meant "ls -l > /tmp/dummy && gedit /tmp/dummy", yes?

i dunno if this's the solution. but "grep -l pattern * | xargs gedit" seems to be working xargs

When do we get this in natty?