Re: [gedit-list] external tool path?

[Doug McNutt <douglist macnauchtan com>]

At 13:01 -0500 11/11/08, John Kitzmiller wrote:
> This plea is about gedit on Dell Mini 9 Ubuntu version (hardy). My daily
> machine is Dell XPS m1330 with hardy.
>
> On the latter (laptop) I made external tool to compile Metapost code:
>
> #!/bin/sh
> mpost "$GEDIT_CURRENT_DOCUMENT_NAME"
>
> All works fine, e.g.:
>
> 	Running tool: metapost
> 	This is MetaPost, Version 1.005 (Web2C 7.5.5)
> 	(spigot.mp [0] [1] [2] [3] )
> 	4 output files written: spigot0.mps .. spigot3.mps
> 	Transcript written on spigot.log.
> 	Done.
>
> On the mini, the same external tool gives:
>
> 	Running tool: metapost
> 	This is MetaPost, Version 1.005 (Web2C 7.5.5)
> 	/home/john/.gnome2/gedit/tools/metapost: 11: spigot.mp not found
> 	**
> 	! End of file on the terminal... why?
> 	Exited 32512
>
> I think the 'not found' error comes from gedit. It is in red on my
> screen which is unlike other metapost error messages I get (with
> alarming frequency ;-) which are always in black and preceded with ! as
> the eof error above.
>
> echo $PATH gives exactly the same results on both machines

Try:
$GEDIT_CURRENT_DOCUMENT_PATH

Instead of
$GEDIT_CURRENT_DOCUMENT_NAME

$GEDIT_CWD, id the current directory that gedit has in mind which is 
likely NOT the same on both machines. I think it depends on just how 
gedit was invoked.  Try a quickie tool that, for me, looks like this:

#!/bin/tcsh
setenv

That will return all of gedit's environment variables to the 
insertion point of an open document if you set the conditions for the 
tool appropriately.  $PATH will be there. Take note of gedit's 
environment variables that refer to multiple open tabs. The way they 
deal with spaces is an invitation to real problems if a file name has 
a space in it.

The external tool path, which I think is not what you mean: is

$HOME/.gnome2/gedit/tools/

--

--> From the U S of A, the only socialist country that refuses to admit it. <--