Linux: JES startet nicht mehr ohne Angabe eines Pfades

[René Neumann]

Moin,

JES (mindestens Versionen 2.6.51 und 2.6.52) starten unter Linux via
jes.sh nicht mehr ohne Angabe einer Datei. Wenn man es unterlässt kommt
der Fehler "Eine Datei mit dem angebenen Pfad existiert nicht:".

Auslöser ist das Quoting um $1 in der jes.sh, das immer ein Argument
weiterreicht -- und JES überprüft nicht, ob das Argument leer ist.

Anschauungsbeispiel:

> f() { echo $#; }
> f
0
> f foo
1
> f ''
1
> f ""
1
> a=foo
> f $a
1
> f $b
0
> f "$b"
1

Gruß,
René

[Uwe Mock]

Hallo.

Ich kann das nicht nachvollziehen. Jes prüft zwar beim Programmstart nicht, ob ein übergebenes Argument leer ist. Jes prüft aber, ob das Argument der Name einer existierenden Datei ist. Ist das nicht der Fall, dann startet Jes einfach so, als hätte man kein Argument angegeben.

Wenn ich das aktuelle Jes starte mit

java -jar jes.jar ""

dann startet Jes einfach mit dem Startdialog, der mich fragt, was ich machen möchte. Das gleiche passiert, wenn ich mit

java -jar jes.jar xyz

einen Dateinamen angebe, der nicht existiert.

[Uwe Mock]

Als ich über den Code drübergeschaut habe, ist mir aufgefallen, daß er schon sehr alt ist. Ich habe ihn deshalb mal modernisiert und eine Testversion gebaut. Vielleicht probierst Du die mal.

[René Neumann]

Moin,

java -jar jes.jar ""

führt bei mir schon zu dem Fehler. Der Vollständigkeit halber noch der
Traceback dazu:

[2025-10-06 18:08:13] [SCHWERWIEGEND] Mon Oct 06 18:08:13 CEST 2025,
Java 25.0.1
java.io.FileNotFoundException thrown in
de.uwemock.eur.gui.ProgressBarForReadEuxFile:
Eine Datei mit dem angegebenen Namen existiert nicht:
de.uwemock.eur.kernels.KernelReadEuxFile.work(KernelReadEuxFile.java:117)
de.uwemock.eur.kernels.KernelReadEuxFile.work(KernelReadEuxFile.java:48)
de.uwemock.kernel.AbstractKernel.executeWork(AbstractKernel.java:15)
de.uwemock.kernel.RunnableAdapterForKernel.run(RunnableAdapterForKernel.java:29)
de.uwemock.guitools.ProgressBarForRunnable$1.run(ProgressBarForRunnable.java:63)


Am 06.10.25 um 07:39 schrieb Uwe Mock:

> Hallo.
>
> Ich kann das nicht nachvollziehen. Jes prüft zwar beim Programmstart nicht,

> ob ein übergebenes Argument *leer* ist. Jes prüft aber, ob das Argument der

> Name einer existierenden Datei ist. Ist das nicht der Fall, dann startet
> Jes einfach so, als hätte man kein Argument angegeben.
>
> Wenn ich das aktuelle Jes starte mit

> *java -jar jes.jar ""*

> dann startet Jes einfach mit dem Startdialog, der mich fragt, was ich
> machen möchte. Das gleiche passiert, wenn ich mit

> *java -jar jes.jar xyz*

[René Neumann]

Moin,

das funktioniert nun.

Ich habe auch spaßenshalber mal ältere Versionen getestet, die in der
Vergangenheit einwandfrei funktioniert haben: Die werfen alle den
Fehler. Ich tippe also auf ein verändertes Verhalten in der JRE (*urgs*).
Aktuell verwende ich: OpenJDK-25.

Gegentest mit OpenJDK-21: Funktioniert wieder. Da ab es wohl wirklich
eine nicht rückwärtskompatible Änderung in Java.

Die "gefixte" JES-Version funktioniert mit beiden Versionen.


Am 06.10.25 um 08:35 schrieb Uwe Mock:

> Als ich über den Code drübergeschaut habe, ist mir aufgefallen, daß er
> schon sehr alt ist. Ich habe ihn deshalb mal modernisiert und eine
> Testversion

> <https://www.dropbox.com/scl/fo/f0tfua0k6auziirq3077r/ANUUFTrcV8o2tcC4K3hc4Cw?rlkey=3dvg7n1ja5r6v9tlny60epksx&dl=0>

[Uwe Mock]

Es handelt sich offenbar um diese Änderung in Java 25:

java.io.File Treats the Empty Pathname As the Current User Directory (JDK-8024695)core-libs/java.io

The java.io.File class is changed so that an instance of File created from the empty abstract pathname ("") now behaves consistently like a File created from the current user directory. Long standing behavior was for some methods to fail for the empty pathname. The change means that the canRead, exists, and isDirectory methods return true instead of failing with false, and the getFreeSpace, lastModified, and length methods return the expected values instead of zero. Methods such as setReadable and setLastModified will attempt to change the file's attributes instead of failing. WIth this change, java.io.File now matches the behavior of the java.nio.file API.

[Uwe Mock]

Ich mach am Dienstag eine neue Version. Danke fürs Bescheid geben.