amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Amiga, AmigaOS 4 > Schwerwiegende Bugs im "Version"-Befehl: [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2 [ - Beitrag schreiben - ]

11.11.2008, 19:46 Uhr

uho
Posts: 114
Nutzer
Schwerwiegende Bugs im "Version"-Befehl:

Den Version-Befehl kann man sehr vorteilhaft verwenden, um z.B. in unübersichtlich gewordenen Datenbeständen oder zwischen verschiedenen
Computern Daten abzugleichen bzw. Doppelgänger zu löschen.
Dummerweise gibt's da einen bösen Bug, der einen dazu verleiten kann noch benötigte Libraries zu löschen:

Denn es wird eine falsche Versionsnummer angezeigt, wenn eine Library
schon im Speicher steht, man aber die Version auf einem File z.B. auf
Diskette wissen will.
Dieser Effekt tritt sogar auf, wenn man den Pfad explizit angibt und
auf diesem Verzeichnis auch kein Path- bzw. Assign-Eintrag liegt.
Beispiel:

version df0:libs/compressors/xpkFAST.library
> V1.10 (richtig)

version libs:compressors/xpkFAST.library
> V0.90 (auf HD; ebenfalls korrekt)

Jetzt die Library laden (z.B. entspr. Backup-Prog starten und wieder beenden
(Libs sollten eigtl. wieder entfernt werden, das Use-Count 0 - und selbst wenn
nicht - ich frage ja ein bestimmtes File und nicht das RAM ab.)

Jetzt nochmal:

version df0:libs/compressors/xpkFAST.library
> V0.90 (FALSCH !!)


Diese Fehlinformation bleibt bis zum nächsten Reset bestehen (nein,
ein Avail FLUSH hilft nicht...) und kann insbesondere dazu führen,
daß man versehentlich neuere Library-Versionen löscht, weil man sie
für ältere bzw. Doppelgänger hält...


Nach einigen Tests konnte ich den Bug wie folgt eingrenzen:

- Tritt nur auf,wenn ein File auf ".library" endet.
Benennt man das File auf der Disk um ("y" entfernen reicht)
und paßt den Version-Aufruf entspr. an, wird die
korrekte Versionsnummer ausgegeben !
Beispiel:

rename df0:libs/compressors/xpkFAST.library...
...df0:libs/compressors/xpkFAST.librar (ohne 'y')

version df0:libs/compressors/xpkFAST.librar
> V1.10 (Richtig !!)

Selbst wenn man dieses File an eine komplett andere Stelle
kopiert, wird die Version trotz expliziter Pfadangabe
nur solange korrekt angezeigt, bis man die Endung wieder
in ".library" ändert.


- Der Bug tritt (mindestens) bei den Versionen KS_1.3, 37.4 und
39.4 auf.
(Version_KS1.3 [enthält keinen Versionsstring] weigert sich
im Übrigen komplett, Dateien die nicht auf ".library" enden,
zu öffnen ("Error in Open").
Und - um es ganz verrückt zu machen - führt man den
vorherigen Aufruf (.library) auf das jetzt nicht mehr
existierende File aus, wird es (angeblich) geöffnet und
die (falsche!) Versionsnummer von vorhin ausgegeben).

V37.4 macht's auch nicht besser und meint, daß da gar
kein Versionstring wäre. Nach dem Umbenennen klappt's
dann aber wieder. Aber das nur nebenbei...)


Weitere Versionen zu testen überlasse ich der werten Leserschaft
als Übungsaufgabe ;-)


Gruß

uho

[ - Antworten - Zitieren - Direktlink - ]

11.11.2008, 20:07 Uhr

NoImag
Posts: 1050
Nutzer
@uho:
Dazu kann ich nur sagen RTFM:

Du musst beim Version-Befehl FILE angeben, wenn Du die Version auf dem Datenträger wissen willst.

Tschüß



[ - Antworten - Zitieren - Direktlink - ]

12.11.2008, 10:49 Uhr

Holger
Posts: 8116
Nutzer
Wenn die xpkFAST.library trotz avail flush nicht aus dem Speicher verschwindet, ist entweder diese Version der Library oder das Programm, das die Library nicht geschlossen hat, buggy.

Ansonsten gilt das von NoImag gesagte.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

12.11.2008, 15:51 Uhr

uho
Posts: 114
Nutzer
@Holger, NoImag:

Klar, Handbuch lesen ist kein Fehler. Und ich gestehe, daß ich
dies zumindest in den letzten Jahren kaum noch gemacht habe.
Aber in diesem Fall liegt ihr dennoch falsch, denn

a) heißt es im Handbuch für die Ausgabe OHNE FILE-Parameter:

"Wenn ein Name angegeben wird, wird die Bibliothek, der Geräte-
treiber, das Laufwerk bzw. die Datei geöffnet..."

Mein Test war also korrekt.


b) Die Option FILE ist in der Tat naheliegend. Doch bevor man
mit RTFMs schleudert, sollte man die Sache erstmal ausprobieren !

Es wird dann nämlich keine Version mehr angegeben, sondern
lediglich das Erstellungsdatum (xpkFAST) bzw. gar nichts
mehr (xpkSHRI) - abgesehen vom - ohnehin bekannten absolute Pfad.
Daran ändert auch die FULL-Option nichts.
Auch mit "richtigen" Libraries wie der req.library wird keine
Version mehr ausgegeben und die Sache wird sinnlos...


Gruß

uho

[ - Antworten - Zitieren - Direktlink - ]

12.11.2008, 21:04 Uhr

NoImag
Posts: 1050
Nutzer
@uho:
Bei mir tut der version Befehl was er soll.

Tschüß



[ - Antworten - Zitieren - Direktlink - ]

12.11.2008, 21:05 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von uho:
a) heißt es im Handbuch für die Ausgabe OHNE FILE-Parameter:

"Wenn ein Name angegeben wird, wird die Bibliothek, der Geräte-
treiber, das Laufwerk bzw. die Datei geöffnet..."

Mein Test war also korrekt.

und was heißt "wird die Bibliothek ... geöffnet"?
Was passiert bei version graphics.library?
Wird da eine Datei geöffnet?
Zitat:
b) Die Option FILE ist in der Tat naheliegend. Doch bevor man
mit RTFMs schleudert, sollte man die Sache erstmal ausprobieren !

Hab ich schon tausende Male gemacht.
Aber extra für Dich:
code:
10.System:Libs/compressors> version xpkFAST.library 
xpkFAST.library 1.10
10.System:Libs/compressors> version xpkFAST.library full
xpkFAST.library 1.10 (20.09.1998)
10.System:Libs/compressors> version xpkFAST.library file
xpkFAST.library 1.10
10.System:Libs/compressors> version xpkFAST.library file full
xpkFAST.library 1.10 (20.09.1998)
10.System:Libs/compressors>

Ich weiß nicht, was für ein Problem Du mit dem Versionsbefehl hast. Vielleicht solltest Du mal which version, bzw. version C:version full ausprobieren.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

13.11.2008, 18:50 Uhr

uho
Posts: 114
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von uho:
a) heißt es im Handbuch für die Ausgabe OHNE FILE-Parameter:

"Wenn ein Name angegeben wird, wird die Bibliothek, der Geräte-
treiber, das Laufwerk bzw. die Datei geöffnet..."

Mein Test war also korrekt.

und was heißt "wird die Bibliothek ... geöffnet"?
Was passiert bei version graphics.library?
Wird da eine Datei geöffnet?


Muß ich jetzt das Wort "beziehungsweise" erläutern ?!

Schließlich habe ich nicht umsonst stets den expliziten Pfad
angegeben, da es in diesem Bug-Report ausschließlich um
Dateien gehen soll.

Zitat:
Hab ich schon tausende Male gemacht.

Aber extra für Dich:
code:
10.System:Libs/compressors> version xpkFAST.library 
xpkFAST.library 1.10
10.System:Libs/compressors> version xpkFAST.library full
xpkFAST.library 1.10 (20.09.1998)
10.System:Libs/compressors> version xpkFAST.library file
xpkFAST.library 1.10
10.System:Libs/compressors> version xpkFAST.library file full
xpkFAST.library 1.10 (20.09.1998)
10.System:Libs/compressors>



Ja, mit einer Version. S.u. ...



Unsere Version-Befehle haben wohl unterschiedliche Versionen :)
Jedenfalls verhalten sie sich unterschiedlich, womit dann
dieser Nebendisput zu erklären ist.

Hier die Resultate, die ich erhalte:

code:
10.RamDisk:> version xpkFAST.library
Objekt nicht gefunden
10.RamDisk:> version xpkFAST.library full
Objekt nicht gefunden
10.RamDisk:> version xpkFAST.library file full
Objekt nicht gefunden
10.RamDisk:> version xpkFAST.library file
Objekt nicht gefunden


(logisch, wenn nicht im Speicher)

code:
10.RamDisk:> version sys:Libs/compressors/xpkFAST.library
xpkFAST.library 1.9

10.RamDisk:> version sys:Libs/compressors/xpkFAST.library full
xpkFAST.library 1.9 (29.10.92)

10.RamDisk:> version sys:Libs/compressors/xpkFAST.library file
Online:Libs/compressors/xpkFAST.library

10.RamDisk:> version sys:Libs/compressors/xpkFAST.library file full
Online:Libs/compressors/xpkFAST.library (29.10.92)

10.RamDisk:> version sys:Libs/compressors/xpkSHRI.library file full
Online:Libs/compressors/xpkSHRI.library

10.RamDisk:> version sys:c/Version 
version 39.4



Wie erläutert, unterdrückt die Option FILE die Versionsausgabe sogar !

Sinn macht lediglich die FULL-Option. Zum nachvollziehen des Bugs
ist sie aber weder notwendig noch hilfreich...

Der springende Punkt war halt die Falschausgabe der Versionsnummer.
Und die läßt sich auch mit obigen Parameterkombinationen nicht
unterbinden.


Jetzt also nochmal - und damit den Thread unnötig verlängernd - der
Test in aller Ausführlichkeit mit Files von Diskette:

code:
10.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library 
xpkFAST.library V0.90 (28-Mar-1993)

10.RamDisk:> version df0:Libs_neu/compressors/xpkFAST.library 
xpkFAST.library 1.10


Diese Versionen sind korrekt !


Nun z.B. Backup-Prog starten und wieder beenden.

Und nun gibt's folgende - völlig falsche - Versionsnummern TROTZ
expliziter Pfadangabe:

code:
10.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library 
xpkFAST.library 1.9

10.RamDisk:> version df0:Libs_neu/compressors/xpkFAST.library 
xpkFAST.library 1.9


10.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library file
Leer:Libs_alt/compressors/xpkFAST.library

10.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library full
xpkFAST.library 1.9 (29.10.92)

10.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library file full
Leer:Libs_alt/compressors/xpkFAST.library


Es wird ab jetzt und bis zum nächsten Reset (!) einfach die im Speicher
stehende Version widergegeben.
DAS ist der Bug, um den es hier geht. V1.9 sollte nur ausgegeben werden,
wenn ich die Library OHNE Pfad angebe !

Und selbst jetzt - wo ja aufgrund der Version-Ausgabe zu vermuten
wäre, daß V1.9 (fälschlicherweise, da UseCnt 0) irgendwo im Speicher
'rumhängt, lautet die Ausgabe ohne Pfadangabe wie folgt:

code:
10.RamDisk:> version xpkFAST.library file full
Objekt nicht gefunden



Hier, wo ausnahmsweise nicht die Datei gemeint ist, wäre V1.9 zu erwarten...



Also, anstatt hier ständig 'rumzumäkeln wäre es sinnvoller, meine
Tests mal wirklich mit (im Hex-Editor überprüften) UNTERSCHIEDLICHEN
Library-Versionen nachzuvollziehen.

(Ich weiß, manchmal sind meine Beiträge bischen lang - aber einzig, um
möglichst
komplett zu sein und so Mißverständnisse und Mehrfacherläuterungen
zu vermeiden. Denn die sind im Endeffekt viel länger und schwieriger
zu lesen. War leider wiedermal umsonst).

Vielleicht tritt der Bug ja bei Euch wirklich nicht auf.
Ist aber eher unwahrscheinlich...


Schließlich veröffentliche ich ja meine mühsam erlangten Erkenntnisse
nicht zum Spaß, sondern um andere Amiga-User vor Schaden zu bewahren
bzw. einfach um Erkenntnisse zu teilen, damit das Rad nicht mehrfach
erfunden werden muß.

Eine (hilfreiche) Resonanz würde mich zwar freuen, ist aber leider
viel zu oft unerfüllte Hoffnung...

Man könnte z.B. versuchen, einen Patch zu entwickeln bzw. eine
bugfreie Version zu entwickeln (ersteres wäre auch für den ebenfalls
von mir entdeckten XCopy-Bug wünschenswert).

Das wäre ein überschaubares (ok, man könnte auch weniger schönes
Wort benutzen, hehe ;-) ) Projekt, in das sich mehrere Leute
einbringen könnten...


Gruß

uho

[ - Antworten - Zitieren - Direktlink - ]

13.11.2008, 23:05 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von uho:
code:
10.RamDisk:> version xpkFAST.library file full
Objekt nicht gefunden



Hier, wo ausnahmsweise nicht die Datei gemeint ist, wäre V1.9 zu erwarten...

Unter solchen Umständen ist es absolut sinnlos, mit Dir weiter zu diskutieren. Du gibst die Option file an und wunderst Dich, dass die Datei nicht (in der Ram-Disk) gefunden wird.
Natürlich interessiert es den Versionsbefehl nicht die Bohne, was Du gemeint hast. Sondern nur, welche Option Du angegeben hast.

Zitat:
Also, anstatt hier ständig 'rumzumäkeln wäre es sinnvoller, meine
Tests mal wirklich mit (im Hex-Editor überprüften) UNTERSCHIEDLICHEN
Library-Versionen nachzuvollziehen.

Das ist vollkommen überflüssig, da Du immer noch das genaue Gegenteil des richtigen Verhaltens erwartest und den Fehler immer bei jemand anderen suchst.

Zitat:
Vielleicht tritt der Bug ja bei Euch wirklich nicht auf.
Ist aber eher unwahrscheinlich...

Nein, er tritt nicht auf.
Die gespostete Ausgabe zeigt deutlich, dass die Option file nicht die Versionsnummer unterdrückt.

Natürlich könntest Du auch mal das Hirn einschalten, und ein paar Tests mit Standard-Bibliotheken machen, bevor Du einen Bug in einem Systembefehl postulierst. Ist Dir schon mal der Gedanke gekommen, dass der Versionsstring in der über 15 Jahre alten xpk...-Library falsch sein könnte?

Zitat:
Schließlich veröffentliche ich ja meine mühsam erlangten Erkenntnisse
nicht zum Spaß, sondern um andere Amiga-User vor Schaden zu bewahren
bzw. einfach um Erkenntnisse zu teilen, damit das Rad nicht mehrfach
erfunden werden muß.

Andere User können mit dem Handbuch umgehen.
Zitat:
Man könnte z.B. versuchen, einen Patch zu entwickeln bzw. eine
bugfreie Version zu entwickeln

Ich weiß nicht, ob es für Dich einen Patch gibt.
Der Versionsbefehl braucht offensichtlich keinen.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

14.11.2008, 06:34 Uhr

Lippi
Posts: 1247
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von uho:
code:
10.RamDisk:> version xpkFAST.library file full
Objekt nicht gefunden


Hier, wo ausnahmsweise nicht die Datei gemeint ist, wäre V1.9 zu erwarten...

Unter solchen Umständen ist es absolut sinnlos, mit Dir weiter zu diskutieren. Du gibst die Option file an und wunderst Dich, dass die Datei nicht (in der Ram-Disk) gefunden wird.
Natürlich interessiert es den Versionsbefehl nicht die Bohne, was Du gemeint hast. Sondern nur, welche Option Du angegeben hast.
.....



Das dachte ich mir gestern abend schon beim Studium dieses Beitrages, da ich davon aber nicht viel Ahnung habe, habe mal abgewartet :-)

--
mfg - lippi --- Mario Lippert
Infokanal-tv.de     infokanal@t-online.de

[ - Antworten - Zitieren - Direktlink - ]

17.11.2008, 12:51 Uhr

uho
Posts: 114
Nutzer
@Lippi:

Ja, kleiner Flüchtigkeitsfehler in dieser Zeile, da unter Zeitdruck
geschrieben.
Die Ausgabe bleibt aber dieselbe - siehe Antwort an Holger


Gruß

uho

[ - Antworten - Zitieren - Direktlink - ]

17.11.2008, 12:55 Uhr

uho
Posts: 114
Nutzer
@Holger:

Zitat:
Original von Holger:
Zitat:
Original von uho:
code:
10.RamDisk:> version xpkFAST.library file full
Objekt nicht gefunden



Hier, wo ausnahmsweise nicht die Datei gemeint ist, wäre V1.9 zu erwarten...

Unter solchen Umständen ist es absolut sinnlos, mit Dir weiter zu diskutieren. Du gibst die Option file an und wunderst Dich, dass die Datei nicht (in der Ram-Disk) gefunden wird.
Natürlich interessiert es den Versionsbefehl nicht die Bohne, was Du gemeint hast. Sondern nur, welche Option Du angegeben hast.


Stimmt. Diese Zeile habe ich online (also unter Zeitdruck) hinzugefügt und prompt
vergessen, die FILE-Option zu entfernen.

Die Ausgabe ("Objekt nicht gefunden") bleibt davon aber unberührt.

Dies legt nahe, daß die xpk-Lib doch wieder aus dem Speicher entfernt wurde.

Gleichzeitig belegt dies aber auch den von mir beschriebenen Bug, daß trotz
expliziter Pfadangabe eine falsche Versionsnummer angezeigt wird - noch dazu
von einer Library-Version, die es offiziell gar nicht mehr im System geben dürfte !


Zitat:
Original von Holger:
Zitat:
Original von uho:
Vielleicht tritt der Bug ja bei Euch wirklich nicht auf.
Ist aber eher unwahrscheinlich...

Nein, er tritt nicht auf.
Die gespostete Ausgabe zeigt deutlich, dass die Option file nicht die Versionsnummer unterdrückt.


Ja, DEINE Ausgabe. Es ging aber um die Bugs auf meinem Rechner - aber man muß
die Beiträge halt KOMPLETT LESEN.
Und nicht nur die Zeile, die evtl. in die eigene Argumentation paßt.
Nicht umsonst habe ich die gängigsten Versionen von WB 1.3 - 3.1 getestet.

Hier also nochmals die entscheidenden Ausgaben:

(Beachte, daß es um zwei unterschiedliche Pfade [Libs_alt
und Libs_neu] geht - kann man leicht übersehen)

Zitat:
Original von uho:
Jetzt also nochmal - und damit den Thread unnötig verlängernd - der
Test in aller Ausführlichkeit mit Files von Diskette:

code:
:

10.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library 
xpkFAST.library V0.90 (28-Mar-1993)

10.RamDisk:> version df0:Libs_neu/compressors/xpkFAST.library 
xpkFAST.library 1.10


Diese Versionen sind korrekt !


Nun z.B. Backup-Prog starten und wieder beenden.

Und nun gibt's folgende - völlig falsche - Versionsnummern TROTZ
expliziter Pfadangabe:


code:
:

10.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library 
xpkFAST.library 1.9

10.RamDisk:> version df0:Libs_neu/compressors/xpkFAST.library 
xpkFAST.library 1.9


10.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library file
Leer:Libs_alt/compressors/xpkFAST.library

10.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library full
xpkFAST.library 1.9 (29.10.92)

10.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library file full
Leer:Libs_alt/compressors/xpkFAST.library


Es wird ab jetzt und bis zum nächsten Reset (!) einfach die im Speicher
stehende Version widergegeben.
DAS ist der Bug, um den es hier geht. V1.9 sollte nur ausgegeben werden,
wenn ich die Library OHNE Pfad angebe !



Man kann sogar genau sagen, welche Option was bewirkt:

FILE unterdrückt die (sonst vorhandene) Versionsausgabe und fügt stattdessen
den absoluten Pfad hinzu.

FULL bewirkt, daß zusätzlich das Erstellungsdatum angezeigt wird.


Vor allem Ersteres ist sicher nicht im Sinne des Erfinders gewesen - halt ein
weiterer Bug - zusätzlich zur falschen Versionsausgabe.
(Denn wozu sollte ein "Version"-Aufruf gut sein, wenn gerade die Versionsnummer
nicht angezeigt wird ?!)


Apropos falsch:

Deine Shell-Zitate beweisen, daß Du das Anliegen dieses Threads gar nicht
verstanden hast, denn mit nur einem Pfad bzw. einer Library-Version kann
man den ganz oben angesprochenen Bug halt nicht nachvollziehen...


Zitat:
Original von Holger:
Zitat:
Original von uho:
Also, anstatt hier ständig 'rumzumäkeln wäre es sinnvoller, meine
Tests mal wirklich mit (im Hex-Editor überprüften) UNTERSCHIEDLICHEN
Library-Versionen nachzuvollziehen.

Das ist vollkommen überflüssig, da Du immer noch das genaue Gegenteil des richtigen Verhaltens erwartest und den Fehler immer bei jemand anderen suchst.

Natürlich könntest Du auch mal das Hirn einschalten, und ein paar Tests mit Standard-Bibliotheken machen, bevor Du einen Bug in einem Systembefehl postulierst. Ist Dir schon mal der Gedanke gekommen, dass der Versionsstring in der über 15 Jahre alten xpk...-Library falsch sein könnte?


Und wieder: Erst LESEN, dann kritisieren !


Erstens haben sich die meisten xpk-Libs stets als zuverlässig erwiesen.

Hier bist DU es also, der lieber armen Libraries die Schuld in die
Schuhe zu schieben versucht, anstatt sich mit meiner Argumentation
zu befassen...


Zweitens kann man den Versions-String im Hex-Editor ansehen,
falls man derartige Zweifel hegt.

Aber für Dich ist das ja "vollkommen überflüssig"...


Drittens mögen die Libs zwar alt sein, sind aber durchs "Lagern"
sicher nicht fehlerhafter geworden.


Und viertens habe ich schon in meinem ersten (!) Beitrag erwähnt,
daß ich auch andere Libs mit dem gleichen Ergebnis getestet habe.



Die xpk-Libs habe ich einfach deshalb gewählt, da sie normalerweise
beim Bootvorgang nicht benötigt werden, aber jederzeit temporär oder
auch dauerhaft in die Liste der genutzten Libraries aufgenommen werden
können.
Dadurch werden die Beispiele für andere leichter nachvollziehbar.


Zusammenfassend kann man sagen:

Du hast Deine "Version"-Versionsnummer nicht verraten. Das wäre
Grundlage für sinnvolle Vergleiche gewesen.

Du hast keinen Hex-Editor benutzt, um unabhängig vom "Version"-Befehl
festzustellen, mit welchen Libraries du wirklich arbeitest.

Du hast meine Beispiele nicht nachvollzogen, da es Dir wohl zu aufwendig
war, eine Library in zwei unterschiedlichen Versionen zu besorgen.

Daher hast Du meinen Bericht nicht vollständig gelesen/verstanden.

Dafür hast Du viel kritisiert und dabei nur einen kleinen Treffer
gelandet, mich aber zu vielen unnötigen Wiederholungen genötigt.

Und Du hast nichts (hilfreiches) zu dieser Diskussion beigetragen

Zitat:
Original von Holger:
Good coders do not comment. What was hard to write should be hard to read too.

Wenn Du meinst...


Gruß

uho

[ - Antworten - Zitieren - Direktlink - ]

17.11.2008, 14:48 Uhr

Wishmaster
Posts: 140
Nutzer
Entweder du willst uns veräppeln oder das Problem sitzt vor dem Bildschirm.
--
Pegasos MorphOS

[ - Antworten - Zitieren - Direktlink - ]

17.11.2008, 23:20 Uhr

DieterG
Posts: 164
Nutzer
Ich bin mir zwar nicht mehr ganz sicher, daher zerschlagt mich ruhig, wenn ich unsiinn erzähle, aber gab es nicht
eine zeilang den Parameter "library" für den versionsbefehl ?
soweit ich mic erinneren, war vor einführen der "$ver"-versionsbezeichnung nur die libary mit der internen versionsbezeichnung ausgestattet.
Daher war der versions-befehl früher auch nur auf diese anwendbar.
Später, ich glaube mit 1.3 oder gar erst 2.0 wurden der versionsbefehl dann o erweitert, das er auch eben den versionsstring auslesen konnte, daher der parameter für die libraries.
Heute ist es ja immer noch so, das jede library die version 2mal enthält, einmal im libnode, und einmal eben im versionsstring.
Woher weiß nun der verisons-befehl, welche gewünscht ist.
Ich habe eben nachgesehen, unter AOS4 zumindest gibt es keinen Parameter mehr zurunterscheidung, also muss es am namen, also der endung .library festgemacht werden.

Auch ich erhalte unterschiedliche werten, wenn ich die gleiche library einmal mit und einmal ohne pfad angebe, als ob da auf die verschiedenen einträge geschaut wird.

Ich weiß, das ict nicht Den grundsätzliches problem, aber es bringt Dich der lösung vieleicht näher.

[ - Antworten - Zitieren - Direktlink - ]

19.11.2008, 21:47 Uhr

uho
Posts: 114
Nutzer
Hallo,

nachdem ich mich letztens über Holgers Reaktionen ärgern mußte,
habe ich den heutigen Feiertag gleich mal genutzt, um meine eigenes
Programm zu diesem Problemchen zu schreiben. Eine Sache, die ich eigtl.
vermeiden wollte.
Rückblickend betrachtet wäre es aber der schnellere Weg gewesen :-((

Nochmal kurz die Ausgangsposition:

Eine Library stand/steht durch Benutzung in der entsprechenden Liste.
Hier: xpkFAST.library V1.9

Weitere Files, die auf ".library" enden müssen, um den Bug zum Vorschein
zu bringen, werden testweise aufgerufen.
Hier: dieselbe Library in den Versionen 0.90 in Libs_alt/ und 1.10 in Libs_neu/

Alle oben aufgezählten "Version"-Versionen zeigen V1.9 für alle drei
Dateien bzw. gar keine Version - ein klarer Bug.
Und das bei allen möglichen Options-Kombinationen aus FILE und FULL.
Eine mögliche Fehlbedienung, die mir hier vorgeworfen wurde, ist und war
also nie gegeben.

Hier nochmal kurz die Ausgabe von Version:

code:
4.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library 
xpkFAST.library 1.9

--> Falsch !
code:
4.RamDisk:> version df0:Libs_neu/compressors/xpkFAST.library 
xpkFAST.library 1.9

--> Falsch !
code:
4.RamDisk:> version libs:compressors/xpkFAST.library 
xpkFAST.library 1.9

--> (zufällig) richtig, da identisch mit der Version der geladenen Lib


Und nun die Ausgabe von My-Version:
code:
4.RamDisk:> My-Version df0:Libs_alt/compressors/xpkFAST.library 
xpkFAST.library V0.90 (28-Mar-1993)

--> Richtig !

code:
5.RamDisk:> wb:c/My-Version df2:Libs_neu/compressors/xpkFAST.library 
xpkFAST 1.10 (20.09.1998)

--> Richtig !

code:
5.RamDisk:> wb:c/My-Version libs:compressors/xpkFAST.library 
xpkFAST 1.9 (04.04.1998)

--> Richtig !

Beim mittleren Beispiel habe ich beim Programmieren gemerkt,
daß es zwei verschiedene Versionsstringarten gibt:

Die "offizielle", die mit "$VER: " beginnt sowie die verbreitetere,
bei der der Name der Library, abgeschlossen mit einem Nullbyte,
dem eigtl. Versionstring vorangeht.


Perfekt ist das Programm noch nicht (V0.1, ein Abend), aber
für den Tests beliebiger Files allemal besser als das Original...

Mein Befehl hat sogar den Vorteil, daß er die Datei - in Schritten von
11264 Bytes, also DD-Disk-Trackgröße - nur bis zum Versionsstring
liest.
Das Commodore-Prog dagegen liest das komplette File ein, selbst wenn
der String ganz am Anfang steht - da kann man dann schonmal 'ne
Minute sinnlos warten...


Apropos unzulänglich: Beim Testen habe ich heute noch einen Bug
entdeckt:
Eigtl. wollte ich ja die version.library verwenden, doch weder in den
RKRMs, dem Guru- oder dem Profi-Know-How-Buch, den Autodocs, den
LVO/FD-Files oder den Includes waren Infos über die enthaltenen
Funktionen zu bekommen. Also habe ich mein Prog halt selber geschrieben.

Um zu testen, ob die Library überhaupt im Speicher steht, habe ich
zuerst ein großes File auf Diskette untersuchen lassen, um während
der Laufzeit von "Version" mit einem Monitor die Library-Liste
anzusehen - nix. Und das, obwohl der Befehl jedesmal die version.library
öffnet.
Also habe ich versucht, den Befehl möglichst oft hintereinander zu
starten, um während dieser Zeit die Liste durchzugehen:

code:
list libs:#? all lformat "version %s%s" >ram:test
execute ram:test


Das habe ich erstmal so durchlaufen lassen - alles OK.
Und dann dasselbe mit SnoopDOS (noch ohne Monitor) -> Crash !
Dieser Crash ist reproduzierbar und tritt 1-2 Sekunden nach dem Start des
Scripts ein. Führt man die Zeilen einzeln (bei laufendem SnoopDOS) aus,
passiert auch nichts.
Erklären kann ich mir dies nicht, denn selbst wenn "Version" nicht
reentrant wäre, startet doch der nächste Befehl erst, wenn der vorherige
die Kontrolle abgegeben hat.
Auch sind bei mir noch nie Abstürze durch das Starten von SnoopDOS
aufgetreten.
Natürlich ist bei mir jetzt erstmal das Prog verdächtig, welches bisher
viele Bugs gezeigt hat...
Aber vielleicht gibt es ja noch eine andere Erklärung ?

Gruß

uho


@DieterG: Klingt plausibel, kann ich jetzt auf die Schnelle (online)
nix dazu sagen ("SEARCHING FOR $" [alter Insiderwitz])

[ - Antworten - Zitieren - Direktlink - ]

19.11.2008, 22:30 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von uho:
Gleichzeitig belegt dies aber auch den von mir beschriebenen Bug, daß trotz
expliziter Pfadangabe eine falsche Versionsnummer angezeigt wird - noch dazu
von einer Library-Version, die es offiziell gar nicht mehr im System geben dürfte !

Junge, kapier es doch endlich:
Wenn Du die Option file nicht angibst, wird immer die Version im Speicher verwendet, und der angegebene Pfad ist dann nur relevant, wenn die Bibliothek nicht im Speicher ist. Dafür ist die Option file da. Was gibt es daran nicht zu verstehen?

Zitat:
Ja, DEINE Ausgabe. Es ging aber um die Bugs auf meinem Rechner - aber man muß die Beiträge halt KOMPLETT LESEN.
Dein Bug interessiert keine Sau. Du bist der einzige, der Deinen Rechner benutzen muss. Du hast behauptet, der Versionsbefehl hätte einen Bug. Das hat er aber nicht. Sondern nur irgendetwas auf Deinem Rechner.
Zitat:
Man kann sogar genau sagen, welche Option was bewirkt:

FILE unterdrückt die (sonst vorhandene) Versionsausgabe und fügt stattdessen
den absoluten Pfad hinzu.

Ausschließlich auf Deinem Rechner!

Auf meinem Rechner zeigt der Versionsbefehl mit der Option file genau das an, was er soll: die in der Datei enthaltene Version. Wie bereits gepostet. Aber das spielt ja keine Rolle. Die Welt dreht sich ja nur um Deinen Rechner.
Zitat:
Deine Shell-Zitate beweisen, daß Du das Anliegen dieses Threads gar nicht
verstanden hast, denn mit nur einem Pfad bzw. einer Library-Version kann
man den ganz oben angesprochenen Bug halt nicht nachvollziehen...

Deine Behauptung, dass die Versionsnummer bei der Option file nicht ausgegeben wird, kann man sehr wohl widerlegen. Und dass ohne die Option file die im Speicher befindliche Version anzeigt, braucht man nicht zu überprüfen. Das ist bekanntes und dokumentiertes Verhalten. Deshalb gibt es ja die Option file!
Zitat:
Und Du hast nichts (hilfreiches) zu dieser Diskussion beigetragen
Diese Diskussion ist ja auch sinnlos. Dein verbuggter Rechner, der, wie Du inzwischen gepostet hast, ja auch Abstürze produziert, macht irgendetwas falsch, woraufhin Du das tust, was Du von Anfang an vor hattest: Deinen eigenen Versionsbefehl programmieren.

Dann befriedige Dein Ego, schreib den einzig wahren Versionsbefehl, der selbst auf Deinem Rechner das richtige tut, aber verschone den Rest der Welt.


--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

19.11.2008, 22:42 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von uho:
Und nun die Ausgabe von My-Version:
code:
4.RamDisk:> My-Version df0:Libs_alt/compressors/xpkFAST.library 
xpkFAST.library V0.90 (28-Mar-1993)

--> Richtig !
Und da postet der Verursacher dieser sinnlosen Diskussion auch noch den Beweis, dass die xpkFAST.library in der Version 0.90 einen ungültigen Versionsstring besitzt...

Fazit: der Versionsbefehl macht das richtige (unter der Voraussetzung, man weiß, was er exakt tun soll), aber eine gewisse Spezies programmiert sich erst einmal selbst den einzig wahren Versionsbefehl, ohne überhaupt zu wissen, wie die Spezifikation aussieht.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

20.11.2008, 18:43 Uhr

DrNOP
Posts: 4118
Nutzer
@Holger:
Könntest du dich über diesen Beweis etwas länger auslassen? Bitte entschuldige, daß ich nicht alle Versionsstrings aller Bibliotheken im Kopf habe...
--
Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker

[ - Antworten - Zitieren - Direktlink - ]

20.11.2008, 19:31 Uhr

thomas
Posts: 7716
Nutzer
@DrNOP:

Die Versionsnummer muß numerisch sein. Das V ist nicht erlaubt.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

20.11.2008, 19:57 Uhr

Blackbird
Posts: 634
Nutzer
Zitat:
Original von DrNOP:
@Holger:
Könntest du dich über diesen Beweis etwas länger auslassen? Bitte entschuldige, daß ich nicht alle Versionsstrings aller Bibliotheken im Kopf habe...
--
Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker


hmmm, schau dir den String doch mal genauer an,
evtl. liegts an dem "V"0.90 was meinst du ?
--
regards
Blackbird

Have a look at:
http://www.blackbird-net.de

Skins for PlayCD OS3.9
BlackShoot, Zombies Apocalypse, GalagaWars, VcdImager-Gui,PerfectPaint

[ - Antworten - Zitieren - Direktlink - ]

21.11.2008, 16:39 Uhr

DrNOP
Posts: 4118
Nutzer
Zitat:
Original von Blackbird:
hmmm, schau dir den String doch mal genauer an,
evtl. liegts an dem "V"0.90 was meinst du ?

Ich schaue und lese eine Version. Ich lese auch ein Datum. Und ich meine, sich an diesem "V" hochzuziehen wenn's uho um einen größeren Kontext ging, braucht ein Diplom in Korinthenkackerei.
--
Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker

[ - Antworten - Zitieren - Direktlink - ]

21.11.2008, 17:33 Uhr

Lippi
Posts: 1247
Nutzer
@DrNOP:
Na moment mal,
wenn der Versions-Befehl nun mal halt keine Vs zulässt, ist das doch keine Kackerei - schon gar nicht mit Korinth - kommt das nicht in den Weihnachtsstollen ? :-)
--
mfg - lippi --- Mario Lippert
Infokanal-tv.de     infokanal@t-online.de

[ - Antworten - Zitieren - Direktlink - ]

21.11.2008, 18:56 Uhr

Blackbird
Posts: 634
Nutzer
Zitat:
Ich schaue und lese eine Version.

ok, habe ich auch kein Problem damit, aber wenn du fragst, dann darf man dir antworten was falsch ist auch wenn du es nicht erkennst oder warum hast du gefragt ?

Zitat:
Ich lese auch ein Datum. Und ich meine, sich an diesem "V" hochzuziehen

es zieht sich doch keiner dran hoch, wenn doch ist mir das entgangen.... Nenn mal bitte Beispiele damit ich das auch verstehe

Zitat:
wenn's uho um einen größeren Kontext ging, braucht ein Diplom in Korinthenkackerei.

ach quaaaaatschhhh, die Dingerchen können da gar nix dazu, außerdem werden die nicht gekackt, sondern getrocknet...sollte dann also Korinthentrocknerei heisen :D
--
regards
Blackbird

Have a look at:
http://www.blackbird-net.de

Skins for PlayCD OS3.9
BlackShoot, Zombies Apocalypse, GalagaWars, VcdImager-Gui,PerfectPaint

[ - Antworten - Zitieren - Direktlink - ]

21.11.2008, 19:57 Uhr

Flinx
Posts: 1073
Nutzer
Zitat:
Original von DrNOP:
Und ich meine, sich an diesem "V" hochzuziehen wenn's uho um einen größeren Kontext ging, braucht ein Diplom in Korinthenkackerei.


Dann hast Du nicht mitbekommen, was abgelaufen ist.
Dieses V ist zuständig für das in Uhos bombastischen Berichten über "schwerwiegende Bugs" gemeldete Verhalten, nur daß er das falsch interpretiert hat. Und obwohl Holger ziemlich zeitig einen falschen Versionsstring vermutet hat, ist Uho dem nicht nachgegangen und hat unnötige Mengen Befehlsausgaben aufgelistet, die nur zeigen, daß er das Verhalten des Versionsbefehls nicht erfaßt hat, obwohl es ihm mehrfach richtig erklärt worden ist.
Als was ich einen solchen "größeren Kontext" auffasse, schreibe ich jetzt mal lieber nicht.

[ - Antworten - Zitieren - Direktlink - ]

21.11.2008, 23:30 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von DrNOP:
Ich schaue und lese eine Version. Ich lese auch ein Datum.

Ja Du liest eine Version und ein Datum. Aber nur, weil uho sich ein eigenes Programm geschrieben hat, das Dir diesen String ausgibt. Eben weil der originale Versionsbefehl, den uho verwendet hat, diesen ungültigen String nicht verarbeiten konnte und nichts ausgegeben hat.
Womit Du also keine Version gesehen hättest. Und auch nicht die richtige Datumsausgabe.

Der echte Versionsbefehl gibt nämlich nicht einfach den Text aus, der nach $VER: folgt, sondern parst ihn nach der gültigen Syntax
name x.y (dd.mm.jjjj) optionaler text

Das Datum wird dann gemäß der eingestellten Landessprache ausgegeben, was wir Deutschen i.A. nicht bemerken, weil die gültige Syntax zufällig auch dem deutschen Datumsformat entspricht. Der Text "(28-Mar-1993)" wird dagegen nur dann als Datum erkannt, wenn die eingestellte Landessprache englisch ist (natürlich sowieso nur, wenn die vorangestellte Versionsnummer kein V enthält). Dann wird sie z.B. wenn US eingestellt ist, als 3/28/1993 ausgegeben. Andernfalls erkennt der Versionsbefehl es nicht als Datum, interpretiert es als nachfolgenden optionalen Text, der nur mit der Option full ausgegeben wird.

Ich hätte den Fehler mit dem V übrigens gar nicht bemerkt, wenn mir nicht zuerst aufgefallen wäre, dass in der Ausgabe bei den Datumsangaben die Sprache wechselt, was bei dem originalen Versionsbefehl und gültigen Strings niemals passieren würde. Aber es war ja klar, dass uhos Programm lediglich die im Code enthaltenen Strings unverändert ausgibt, somit ausgegebene ungültige Versionsstrings auch exakt so in den Bibliotheken stehen.

Zusätzlich besitzt der Versionsbefehl zumindest in neueren Versionen auch die Option zu überprüfen, ob die Datei ein bestimmte Mindestversion besitzt. Kann natürlich nur funktionieren, wenn die Versionsnummer auch als solche erkannt wird.

Bleibt nur noch zu sagen, dass der Versionsbefehl in der Version 44.4 einen Fallback-Modus zu besitzen scheint, der ungültige Strings einfach komplett ausgibt. Das kann Diskussionen mit Leuten, die schnell Bugs in den Programmen (der anderen) finden, ersparen. Ist aber auch ein probates Mittel, um Autoren beim Testen ihrer Produkte übersehen zu lassen, wenn der Versionsstring falsch ist.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

24.11.2008, 20:36 Uhr

uho
Posts: 114
Nutzer
@Holger:

Zitat:
Original von Holger:
Junge, kapier es doch endlich:
Wenn Du die Option file nicht angibst, wird immer die Version im Speicher
verwendet, und der angegebene Pfad ist dann nur relevant, wenn die Bibliothek
nicht im Speicher ist. Dafür ist die Option file da. Was gibt es daran nicht zu
verstehen?


Das ist und bleibt falsch - egal wie oft Du es hinschreibst !
Wozu habe ich eigtl. das Commo-Handbuch zitiert ?!

Die Option FILE - so sie funktioniert - ist nur bei Mehrdeutigkeiten
erforderlich:
Also falls man keinen Pfad angibt UND das File im aktuellen Verzeichnis
UND außerdem im Speicher steht.
Kannste auch leicht überprüfen: Wenn nur die ersten beiden Bedingungen
zutreffen, sollte nach DEINER Theorie "Objekt nicht gefunden" erscheinen -
da ja ohne die Option angebl. nur der Speicher geprüft wird.
Tatsächlich wird aber die Datei verarbeitet - wie man nicht nur an der
Ausgabe sieht, sondern auch mit SnoopDOS nachprüfen kann...


Zitat:
Original von Holger:
Zitat:
Original von Uwe:
Ja, DEINE Ausgabe. Es ging aber um die Bugs auf meinem Rechner - aber man muß
die Beiträge halt KOMPLETT LESEN.


Dein Bug interessiert keine Sau. Du bist der einzige, der Deinen Rechner
benutzen muss. Du hast behauptet, der Versionsbefehl hätte einen Bug. Das hat er
aber nicht. Sondern nur irgendetwas auf Deinem Rechner.


Diese Meinung kannst Du natürlich gerne vertreten.

Aber wenn Dich die Rechner anderer Leute nicht interessieren -
was zum Teufel machst Du dann hier ?


Zitat:
Original von Holger:
...woraufhin Du das tust, was Du von Anfang an vor hattest: Deinen eigenen
Versionsbefehl programmieren.

Dann befriedige Dein Ego, schreib den einzig wahren Versionsbefehl, der selbst
auf Deinem Rechner das richtige tut, aber verschone den Rest der Welt.


Warum ich mir die Mühe mache, entsprechende Beiträge zu schreiben,
habe ich bereits ausführlich dargelegt.
Ansonsten wäre es ja viel einfacher und schneller gewesen einfach mit dem
proggen anzufangen, stimmt's ?


Zitat:
Original von Holger:
Und da postet der Verursacher dieser sinnlosen Diskussion auch noch den Beweis,
dass die xpkFAST.library in der Version 0.90 einen ungültigen Versionsstring
besitzt...


Zu der Sache mit dem "V" vor der Versionsnummer habe ich im Guru-Book
folgendes gefunden:


"This version string should be specified in the following format:

code:
dc.b '$VER: name version (date)',13,10,0



"Although the version string may be terminated by any of the three
control characters used above, and 'name', 'version' and 'date'
may comprise almost any sequence of printable characters..."


Es folgen Beispiele. Kurz gesagt: Nach "$VER: " ist fast alles erlaubt.

Annahmen über die genaue Zeichenabfolge sind reine Spekulation !

Es sieht vielmehr so aus, daß "Version" hier ein bischen zuviel des
Guten tut - und prompt scheitert.

Im Übrigen ist das mit dem "V" auch kein "Ausrutscher" eines Autors -
auch in folgenden Libraries habe ich es gefunden:

CBR0, DLTA, HUFF, (HFMN), IDEA, MASH, (RAKE), SHRI

(): statt "V" steht "Version"


Obwohl die obenstehende Erläuterung aus dem Abschnitt "Libraries" stammt,
haben viele Libraries den "klassischen" Versionstring nicht.


Hier muß man wohl - wie von DieterG angeregt - über den Aufbau
der Lib gehen. Das muß ich erst noch ausknobeln B-) .


Zitat:
Original von Holger:
Bleibt nur noch zu sagen, dass der Versionsbefehl in der Version 44.4
einen Fallback-Modus zu besitzen scheint, der ungültige Strings einfach
komplett ausgibt. Das kann Diskussionen mit Leuten, die schnell Bugs in
den Programmen (der anderen) finden, ersparen. Ist aber auch ein probates
Mittel, um Autoren beim Testen ihrer Produkte übersehen zu lassen, wenn
der Versionsstring falsch ist.


Wie schon vorher erwähnt, hättest Du die entspr. Versionen auch wirklich
testen/kundgeben sollen.
Dann wären wir schneller zum Ziel gekommen, anstatt Äpfel mit Birnen
zu vergleichen.

Ansonsten hatte Dein letzter Beitrag sogar mal Substanz. Weiter so.


Gruß

uho

[ - Antworten - Zitieren - Direktlink - ]

24.11.2008, 21:06 Uhr

thomas
Posts: 7716
Nutzer
@uho:
Zitat:
Wozu habe ich eigtl. das Commo-Handbuch zitiert ?!

Weil du es nicht verstanden hast ?

Zitat:
sondern auch mit SnoopDOS nachprüfen kann...

Offenbar kannst du nicht noch einmal ein SnoopDOS-Log richtig lesen.

Alle wissen wie es funktioniert, nur du nicht. Aber anstatt dir erklären zu lassen, wie es richtig ist, beharrst du auf deiner Meinung, die nichts aber auch absolut gar nichts mit den Tatsachen zu tun hat. Anstatt zuzuhören und zu lernen, beleidigst du die Leute, die dir helfen möchten.

Was willst du überhaupt hier ? Warum fragst du, wenn du doch alles besser weißt ?

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

24.11.2008, 22:18 Uhr

cgutjahr
Posts: 2779
[Administrator]
Zitat:
Original von uho:
Das ist und bleibt falsch - egal wie oft Du es hinschreibst !
Wozu habe ich eigtl. das Commo-Handbuch zitiert ?!

Was uns dein Handbuch-Zitat sagen soll weiß ich nicht, aber Holger liegt völlig richtig.

Zitat:
Die Option FILE - so sie funktioniert - ist nur bei Mehrdeutigkeiten
erforderlich:

Wo hast du das her? So lange du mit dieser Fehlannahme argumentierst, ist es tatsächlich sinnlos, das Gespräch weiterzuführen.

Ohne "FILE":

Erst wird nach einer Datei im Speicher gesucht. Schlägt das fehl, wird versucht die Datei auf Disk zu lokalisieren.

Mit FILE:

Es wird immer versucht, die Datei auf Disk zu lokalisieren.

Tests unter OS 1.x kannst du dir übrigens sparen, das einzige dokumentierte Verhalten von version unter OS 1.x ist es, die Versionsnummer von Kickstart und Workbench anzuzeigen.

Zitat:
Zu der Sache mit dem "V" vor der Versionsnummer habe ich im Guru-Book
folgendes gefunden: [...] Annahmen über die genaue Zeichenabfolge sind reine Spekulation !

Das Gurubook ist weder sonderlich aktuell (es behandelt nur OS 2.1) noch ist es Bestandteil der offiziellen Amiga-Dokumentation.

Hier ist die offizielle, seit mehr als 15 Jahren gültige Version:

Zitat:
V38, V39, V40 Changes

(c) 1992-93 Commodore-Amiga, Inc. All Rights Reserved

[...]

Version Command
===============

There has been some confusion about what the format of version strings
are. The exact format is detailled in the Amiga User Interface Style Guide on page 110. The format is:

$VER: <name> <version>.<revision> (dd.mm.yy)

The string starts with $VER: followed by a space, followed by <name>. <name> is the name of the program. <name> can NOT contain any spaces. You can use underscores to achieve a similar effect.

After <name> comes a single space, followed by <version>. <version> is the major version number for the program. There should be no leading zeros.

After <version> comes a single space, followed by <revision>. <revision> is the minor version number for the program. There should be no leading zeros.

Following the revision number comes a space, and then the date. The date is specified in numeric form only, with no leading zeros on any of the components. First comes the day of the month, then the month, then the two digits year. In the future, a four digit year format will also be supported, but not yet.


Zitat:
Im Übrigen ist das mit dem "V" auch kein "Ausrutscher" eines Autors -
auch in folgenden Libraries habe ich es gefunden:

Es gibt offensichtlich noch mehr Leute, die die Dokumentation genauso gründlich gelesen haben wie du ;)

--
Gutjahrs Amiga Seiten

[ - Antworten - Zitieren - Direktlink - ]

24.11.2008, 22:26 Uhr

Flinx
Posts: 1073
Nutzer
Während ich den nachfolgenden Text geschrieben habe, ist cgutjahr schon mit seinem fertig geworden. Da ich aber noch die andere Quelle zitiere, sende ich das Posting trotzdem ab:

Bezüglich des Versionsstrings ist Ralph vielleicht nicht der wahre Guru, was man schon daran sieht, daß er - wie sonst eigentlich kaum - unpräzise Angaben macht, indem er den zwingend nötigen Punkt zwischen Version und Revision unterschlägt. Sehen wir doch stattdessen also mal bei Commodere nach (User Interface Style Guide S.110):

"The Shell command VERSION provides support for version indentification, but you have to follow a standard template. A text sequence that indicates the current version of your application should be embedded within your code. [...] The format of this text sequence is:
$VER: <name> <version>.<revision> (<d>.<m>.<y>)
<name> The name of your application
<version> Major version number
<revision> Minor revision number
<d> Day created
<m> Numeric month created
<y> Year created"

Von beliebigen Zeichen bei <version>.<revision> steht da nichts, nur das Wort "number". Daß die zusätzlichen Zeichen nach der Revision mit ausgegeben werden, die im letzten Guru-Buch-Beispiel stehen, ist also eher Zufall und nicht dokumentiert.

[ - Antworten - Zitieren - Direktlink - ]

24.11.2008, 23:00 Uhr

Flinx
Posts: 1073
Nutzer
Fehler, gelöscht.

[ Dieser Beitrag wurde von Flinx am 24.11.2008 um 23:01 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

25.11.2008, 16:29 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von cgutjahr:
Es gibt offensichtlich noch mehr Leute, die die Dokumentation genauso gründlich gelesen haben wie du ;)

Vermutlich eine weitere Person.
Schließlich handelt es sich bei all den vielen Libraries ausschließlich um xpk-Module aus derselben Quelle. Vielleicht waren es auch zwei Autoren, einer schrieb "V", der andere "Version".
Und diese ein oder zwei Entwickler scheinen, wie man den neueren Versionen entnehmen kann, auch seit 1993 dazugelernt zu haben.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]


-1- 2 [ - Beitrag schreiben - ]


amiga-news.de Forum > Amiga, AmigaOS 4 > Schwerwiegende Bugs im "Version"-Befehl: [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.