Re: [gedit-list] Ubuntu 9.10 or gedit 2.28.0 kills external tools

[Jesse van den Kieboom <jessevdk gnome org>]

External tools was reworked during this release cycle, and it seems that 
you found quite some unfortunate regressions. If you can find the time 
to file some bugs (see comments inline below) that would be great. I 
will see to it that these problems are fixed as soon as possible.


Jesse

Doug McNutt wrote:
> At 22:19 +0100 11/2/09, Jef Driesen wrote:
>   
> > Doug McNutt wrote:
> >     
> > > Ubuntu newly upgraded to 9.10, gedit 2.28.0
> > > My tools don't work any more.
> > > [..]
> > > The error returned is:   "Could not execute command [Errno 8] Exec  format error"
> > >       
> > I noticed this too! It seems that the "body" of an external tool needs to be a complete shell script. For instance if I try to create a tool which tries to execute a single command, like
> >
> > make
> >
> > it doesn't work. But if I specify
> >
> > #!/bin/sh
> > make
> >
> > it works for me.
> >     
>
> Wonderful.  It works for me too. Thanks for the prompt reply.
>   
So, if this worked before, this clearly a bug now. Could you file this 
(i.e. tools without explicit hash/bang should default to sh or something).
> The selection window for the tools still converts underlines in the file names to spaces in the menu .
>   
I'm not sure if this is really a problem or not? Also, with selection 
window, do you mean the tools manager? Could you file this as a separate 
bug too?
> For my curl operations my tools are copying both stdin and stderr from the shell into the text file where I have asked for replacement of the current selection.
>
> I suspect that redirecting the error to /dev/null will fix that except that it was nice to see curl's progress in the bottom window while getting only the contents of the file in the main window.
>   
If I understand correctly, both stdout and stderr are now used to 
replace the text whereas before stderr was always put in the bottom 
window? Could you file a bug about this too?
> I'm also getting a response from my rc file for the shell into the text area. It's the message I send when I log in remotely. I'll check some more but the shell in the #! line may being invoked as a login shell by gedit.
>   
The external tools should simply open the exact file as a shell script. 
It's possible that the python subprocess module (which is used by 
external tools) uses a login shell for this. Could you file a bug about 
this, providing the way you display the message so that we can easily 
reproduce this?
> My tools that have always started with #!/usr/bin/perl have worked OK though I may not have tried them all.
>