Ubuntu 9.10 or gedit 2.28.0 kills external tools

[Doug McNutt]

Ubuntu newly upgraded to 9.10, gedit 2.28.0

My tools don't work any more.

The first error showed up with a simple call to the curl tool to download a short text file from a local server with a dotted decimal IP address.  It works OK when run in a Terminal window.

I have been mucking with it using the Tools Management window. This is what it looks like now.  The Save-files line was apparently added for me.

# [Gedit Tool]
# Comment=Read finance snippet into selection
# Name=Finance Get
# Languages=
# Applicability=all
# Output=replace-selection
# Input=nothing
# Save-files=nothing
# curl -u Mars:Mars ftp://Saturn.suntide/Mimas/Transfer/USBpay.txt
/usr/bin/curl -u Mars:Mars ftp://192.168.1.13/Mimas/Transfer/USBpay.txt

The error returned is:   "Could not execute command [Errno 8] Exec  format error"
There is a minute or so delay before gedit will accept commands. The stop option is not enabled. I can't copy the error for pasting.

Permissions on the tool are read and execute for group,  everything for user.

$HOME/.gnome2/gedit/tools/Finance_Get     ;#  works OK printing the file content to stdout.

I have disabled the external tools addin and re-enabled it after restarting gedit. Still no workee.

I just noticed that the Name line got changed so that an underline character was replaced with a space. I swear I didn't do it. Anyway I changed the file name to make it FinanceGet  in the file system and the Name: line and restarted gedit. The displayed tool name no longer contained a space but the error persists.

I also don't know what the Languages= line means. I don't think I care but I can't seem to change it.

It there anything about the colon in the -u option that might be confusing the way gedit performs an execve?

I need a work around badly.

--

--> From the U S of A, the only socialist country that refuses to admit it. <--
_______________________________________________
gedit-list mailing list
gedit-list@...
http://mail.gnome.org/mailman/listinfo/gedit-list

[Jef Driesen]

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.

_______________________________________________
gedit-list mailing list
gedit-list@...
http://mail.gnome.org/mailman/listinfo/gedit-list

[Doug McNutt]

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.

The selection window for the tools still converts underlines in the file names to spaces in the menu .

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.

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.

My tools that have always started with #!/usr/bin/perl have worked OK though I may not have tried them all.
--

--> From the U S of A, the only socialist country that refuses to admit it. <--
_______________________________________________
gedit-list mailing list
gedit-list@...
http://mail.gnome.org/mailman/listinfo/gedit-list

[Jesse van den Kieboom-2]

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.
>  

_______________________________________________
gedit-list mailing list
gedit-list@...
http://mail.gnome.org/mailman/listinfo/gedit-list