|
DEUTSCHE VERSION |
|
 |
| Links | | | Forums | | | Comments | | | Report news |
|
| Chat | | | Polls | | | Newsticker | | | Archive |
|
| amiga-news.de Forum > Amiga, AmigaOS 4 > Schwerwiegende Bugs im "Version"-Befehl: | [ - Search - New posts - Register - Login - ] |
| -1- 2 | [ - Post reply - ] |
|
2008-11-11, 19:46 h uho Posts: 114 User |
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 [ - Answer - Quote - Direct link - ] |
|
2008-11-11, 20:07 h NoImag Posts: 1050 User |
@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üß [ - Answer - Quote - Direct link - ] |
|
2008-11-12, 10:49 h Holger Posts: 8116 User |
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. [ - Answer - Quote - Direct link - ] |
|
2008-11-12, 15:51 h uho Posts: 114 User |
@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 [ - Answer - Quote - Direct link - ] |
|
2008-11-12, 21:04 h NoImag Posts: 1050 User |
@uho: Bei mir tut der version Befehl was er soll. Tschüß [ - Answer - Quote - Direct link - ] |
|
2008-11-12, 21:05 h Holger Posts: 8116 User |
Zitat:und was heißt "wird die Bibliothek ... geöffnet"? Was passiert bei version graphics.library? Wird da eine Datei geöffnet? Zitat:Hab ich schon tausende Male gemacht. Aber extra für Dich: code: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.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> mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2008-11-13, 18:50 h uho Posts: 114 User |
Zitat: 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: 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 [ - Answer - Quote - Direct link - ] |
|
2008-11-13, 23:05 h Holger Posts: 8116 User |
Zitat: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: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: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:Andere User können mit dem Handbuch umgehen. Zitat: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. [ - Answer - Quote - Direct link - ] |
|
2008-11-14, 06:34 h Lippi Posts: 1247 User |
Zitat: 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 [ - Answer - Quote - Direct link - ] |
|
2008-11-17, 12:51 h uho Posts: 114 User |
@Lippi: Ja, kleiner Flüchtigkeitsfehler in dieser Zeile, da unter Zeitdruck geschrieben. Die Ausgabe bleibt aber dieselbe - siehe Antwort an Holger Gruß uho [ - Answer - Quote - Direct link - ] |
|
2008-11-17, 12:55 h uho Posts: 114 User |
@Holger:Zitat: 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: 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: 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: 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:Wenn Du meinst... Gruß uho [ - Answer - Quote - Direct link - ] |
|
2008-11-17, 14:48 h Wishmaster Posts: 140 User |
Entweder du willst uns veräppeln oder das Problem sitzt vor dem Bildschirm. -- Pegasos MorphOS [ - Answer - Quote - Direct link - ] |
|
2008-11-17, 23:20 h DieterG Posts: 164 User |
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. [ - Answer - Quote - Direct link - ] |
|
2008-11-19, 21:47 h uho Posts: 114 User |
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:--> Falsch !4.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library xpkFAST.library 1.9 code:--> Falsch !4.RamDisk:> version df0:Libs_neu/compressors/xpkFAST.library xpkFAST.library 1.9 code:--> (zufällig) richtig, da identisch mit der Version der geladenen Lib4.RamDisk:> version libs:compressors/xpkFAST.library xpkFAST.library 1.9 Und nun die Ausgabe von My-Version: code:--> Richtig !4.RamDisk:> My-Version df0:Libs_alt/compressors/xpkFAST.library xpkFAST.library V0.90 (28-Mar-1993) code:--> Richtig !5.RamDisk:> wb:c/My-Version df2:Libs_neu/compressors/xpkFAST.library xpkFAST 1.10 (20.09.1998) code:--> Richtig !5.RamDisk:> wb:c/My-Version libs:compressors/xpkFAST.library xpkFAST 1.9 (04.04.1998) 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]) [ - Answer - Quote - Direct link - ] |
|
2008-11-19, 22:30 h Holger Posts: 8116 User |
Zitat: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: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: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 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: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. [ - Answer - Quote - Direct link - ] |
|
2008-11-19, 22:42 h Holger Posts: 8116 User |
Zitat: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. [ - Answer - Quote - Direct link - ] |
|
2008-11-20, 18:43 h DrNOP Posts: 4118 User |
@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 [ - Answer - Quote - Direct link - ] |
|
2008-11-20, 19:31 h thomas Posts: 7718 User |
@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/ [ - Answer - Quote - Direct link - ] |
|
2008-11-20, 19:57 h Blackbird Posts: 634 User |
Zitat: 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 [ - Answer - Quote - Direct link - ] |
|
2008-11-21, 16:39 h DrNOP Posts: 4118 User |
Zitat: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 [ - Answer - Quote - Direct link - ] |
|
2008-11-21, 17:33 h Lippi Posts: 1247 User |
@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 [ - Answer - Quote - Direct link - ] |
|
2008-11-21, 18:56 h Blackbird Posts: 634 User |
Zitat: 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: es zieht sich doch keiner dran hoch, wenn doch ist mir das entgangen.... Nenn mal bitte Beispiele damit ich das auch verstehe Zitat: ach quaaaaatschhhh, die Dingerchen können da gar nix dazu, außerdem werden die nicht gekackt, sondern getrocknet...sollte dann also Korinthentrocknerei heisen  -- regards Blackbird Have a look at: http://www.blackbird-net.de Skins for PlayCD OS3.9 BlackShoot, Zombies Apocalypse, GalagaWars, VcdImager-Gui,PerfectPaint [ - Answer - Quote - Direct link - ] |
|
2008-11-21, 19:57 h Flinx Posts: 1073 User |
Zitat: 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. [ - Answer - Quote - Direct link - ] |
|
2008-11-21, 23:30 h Holger Posts: 8116 User |
Zitat: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. [ - Answer - Quote - Direct link - ] |
|
2008-11-24, 20:36 h uho Posts: 114 User |
@Holger:Zitat: 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: 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: 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: 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: 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 [ - Answer - Quote - Direct link - ] |
|
2008-11-24, 21:06 h thomas Posts: 7718 User |
@uho:Zitat: Weil du es nicht verstanden hast ? Zitat: 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/ [ - Answer - Quote - Direct link - ] |
|
2008-11-24, 22:18 h cgutjahr Posts: 2783 [Administrator] |
Zitat:Was uns dein Handbuch-Zitat sagen soll weiß ich nicht, aber Holger liegt völlig richtig. Zitat: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: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: Zitat:Es gibt offensichtlich noch mehr Leute, die die Dokumentation genauso gründlich gelesen haben wie du  -- Gutjahrs Amiga Seiten [ - Answer - Quote - Direct link - ] |
|
2008-11-24, 22:26 h Flinx Posts: 1073 User |
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. [ - Answer - Quote - Direct link - ] |
|
2008-11-24, 23:00 h Flinx Posts: 1073 User |
Fehler, gelöscht. [ Dieser Beitrag wurde von Flinx am 24.11.2008 um 23:01 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2008-11-25, 16:29 h Holger Posts: 8116 User |
Zitat: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. [ - Answer - Quote - Direct link - ] |
| -1- 2 | [ - Post reply - ] |
| amiga-news.de Forum > Amiga, AmigaOS 4 > Schwerwiegende Bugs im "Version"-Befehl: | [ - Search - New posts - Register - Login - ] |
|
|
Masthead |
Privacy policy |
Netiquette |
Advertising |
Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved. |
|