File contents from standard input (stdin)

Andre Miranda @andreldm said:

+1 This feature seems very useful, but I can't gEdit(3.10.1) to read from stdin, it just opens a blank file.

Ian Griffiths submitted a patch:

Patch 6250, "Create files from stdin":
0001-Added-ability-to-create-file-from-stdin.patch

Matthew Brush @matt said:

What would happen if you did this?

cat /dev/random | mousepad

Does it block the UI until cat gets killed?

Other than the blocking read (which IIRC Mousepad already uses anyway), and that locale encoding is assumed (which may or may not be a decent assumption, depending on the usage ... echo vs files vs OSes like windows with non-locale console encodings, etc), it looks pretty good to me.

I will review, test and try and get it merged next time I can dedicate some time to go through the patches in tracker.

Thanks

Ian Griffiths said:

(In reply to Matthew Brush from comment 3)

What would happen if you did this?
cat /dev/random | mousepad
Does it block the UI until cat gets killed?

Yes, it will do - I'm not sure of how this could be prevented. Perhaps a maximum read size, but that could cause more problems.

Other than the blocking read (which IIRC Mousepad already uses anyway), and that locale encoding is assumed (which may or may not be a decent assumption, depending on the usage ... echo vs files vs OSes like windows with non-locale console encodings, etc), it looks pretty good to me.

I think the majority of uses will be echoes and command outputs, so locale encoding makes the most sense. But it could be changed to guess the encoding based on the contents.

I will review, test and try and get it merged next time I can dedicate some time to go through the patches in tracker.

Thanks - if anything needs changing, just shout (this is my first patch).

Andre Miranda @andreldm said:

Nicely done Ian, I have just applied the patch and it works (almost) smoothly here. Besides the problems mentioned by Matt, I noticed that if you run "echo test | mousepad" and run it again in another terminal, second mousepad window is blank. Right now I'm a bit busy, but I guess this is something related to how mousepad handles(or it was supposed to handle) instances.

Ian Griffiths said:

I am guessing that is due to only the file name being passed through dbus. With the second process exiting after sending the dbus command, so that its stdin is lost.

I'm not sure of a simple way of getting round this - sending the contents of stdin across dbus might be difficult (as it isn't a fixed size and can range massively).

I've had a look at gedit, it seems they now require a file name of '-' to read from stdin (i.e. "echo hi|gedit -"). They have an interesting solution to the problem pointed out by Matt - they essentially launch another process to read from stdin, with the data being added to the bottom of the window. This allows it to follow the input, for example "tail -f /var/log/syslog|gedit -" will update the window with new content from syslog, which is quite nice.

I'm thinking that a similar approach might fix both problems, although I'm not sure how this could be done with dbus in the middle. Perhaps switching to background process file loading might also help with large files.

Matthew Brush @matt said:

Maybe - could imply --disable-server (and put a note to that effect in the --help output).

added 2. Feature Patch labels

marked this issue as related to #10

added Future Plugin label

unassigned @matt

marked this issue as related to ristretto#42

mentioned in issue #159 (closed)

marked #291 (closed) as a duplicate of this issue

marked this issue as related to #291 (closed)

File contents from standard input (stdin)

Submitted by Ian Griffiths

Description

Designs

Child items 0

Activity