0

What puzzles me is, how does it come that the Python Shell plug-in for jEdit does not work with Python3? The issue seem to be known since year 2012 and apparently no one has yet provided an updated version ( http://www.jedit.org/oldtrackers/Plugin%20Feature%20Requests/3498547.html ) of this plug-in working for both Python2.x and Python3.x . Am I alone with the need of having this plug-in up an running in jEdit?

The problem is that this plug-in uses the execfile() function which is not available in Python3. In order to provide a fix it is necessary to replace in PythonShell.java code of this plugin: 

    execfile("filename")

with 

    exec( open("filename").read() )

For me who is not very familiar with Java it was very hard to get an updated PythonShell.jar out of the adjusted PyhonShell.java file. What I still fail to understand after success with fixing the problem is how to use jar. After many various approaches I came finally out with: 

    jar -u PythonShell.jar -C python/shell  PythonShell.class

but also this gave me the same as I was getting all the time: 

     jar: `-u' mode requires a file name

The jar's -help was not able to help me understand what I did wrong in all my attempts to replace the PythonShell.class file in the PythonShell.jar with the new version got from compiled PythonShell.java file.

My workaround was to rename the .jar to .zip, put the PythonShell.class file into it using a File Manager and then rename it back to .jar, but I would be glad to get rid of the bad gut feeling of not understanding how the 'jar' command works.

Claudio
  • 7,474
  • 3
  • 18
  • 48

2 Answers2

1

The jar command by default works in streamed mode. This means if you do jar -c foo, it takes the file foo creates a JAR out of it and outputs it to stdout. You can then either redirect this to a file (jar -c foo >foo.jar), or you can use -f to instruct jar to create a file (jar -cf foo.jar foo).

The same applies when updating a JAR file, you can either stream the input in and the output out like cat foo.jar | jar -u foo >foo2.jar or you can use -f to instruct it to update the file in place like jar -uf foo.jar foo.

If you tell it to update a file using -u, but you don't specify which file to update with -f and are not giving anything on stdin, then it cannot work as it does not know what file to update.

PS: You are welcome to submit a patch to https://sourceforge.net/p/jedit/plugin-patches for the plugin maintainer to accept, or overtake maintenance of the plugin if there is no active maintainer and you want to overtake.

Vampire
  • 35,631
  • 4
  • 76
  • 102
  • Before I re-try to cope with it any further I would like in addition to the already provided hints to understand how to pack a file into the `.jar` archive when the file goes into a directory? In case of `PythonShell.class` it should be saved into the `[python/shell]` directory in the `PythonShell.jar` file. How do `jar` know in which directory the file should be updated? I thought/think the -C parameter is there to point to the directory ... Hmmm ... – Claudio Mar 22 '17 at 13:52
  • Nope, you forced the reverse behavior. If you do `jar -c foo/bar | jar -t` you will see that the file `bar` in the folder `foo` is added. If you instead call `jar -c -C foo bar | jar -t` you will see that the file `foo` is directly in the root of the JAR. `-C` "cds" into the given directory and then uses that directory as "root" directory for the files you specify. – Vampire Mar 22 '17 at 14:28
0

Down to the core of my question it turned out that my attempt and my previous intuitive understanding how to update a Java jar archive:

XXX jar -u PythonShell.jar -C python/shell  PythonShell.class XXX

was a case of pure living nonsense ... Here my new gained understanding

how it should be done: 

jar -uf PythonShell.jar python/shell/PythonShell.class

To be able to do that this way it is apparently vital to re-create the right directories to form the required path for the file PythonShell.class . A case of a command where the current directory really matters. It's still not may case, but at least the bad gut feeling I am on a dead end path is now gone.

Here an exercise I have performed to test my new gained understanding of how the jar command works:

Let's create in directory [foo] a file named 'bar' with the text "bar" in it: 

~ $ mkdir foo
~ $ echo bar > foo/bar

Let's put the file 'bar' into an jar-archive 'foo.jar' along with the directory [foo] the file 'bar' is stored in: 

~ $ jar -c foo/bar > foo.jar

Let's take a look what's "in", in the 'foo.jar' jar-archive file: 

~ $ cat foo.jar | jar -t
META-INF/
META-INF/MANIFEST.MF
foo/bar

Let's get rid of the directory [foo] and extract the jar-archive to get the directory and the file in it back again. Then look what's the content of the file 'bar': 

~ $ mv foo foo-old-1  
~ $ cat foo.jar | jar -x
~ $ cat foo/bar
bar

OK - up to now all as expected ?

Now prepare what is necessary for updating the file 'bar' in the jar-archive with a patched 'bar' file containing now the text "foo":

~ $ echo foo > foo/bar

Here the CORRECT syntax for updating a jar-archive file 'bar' being stored there in a directory [foo]. For me in this context is surprising that how the path of the file 'bar' is specified strongly impacts what happens: 

~ $ jar -uf foo.jar foo/bar

Let's check if this was successful: 

~ $ mv foo foo-old-2
~ $ cat foo.jar | jar -x
~ $ cat foo/bar
foo

OK - that is how I expected it. I see it myself as a good sign that now I have got it right.

Claudio
  • 7,474
  • 3
  • 18
  • 48