Hauptmenü
Sie sind hier
Command \@textsubscript already defined
Seit einiger Zeit erzeugt das Erstellen von KOMA-Script-Dokumenten die Fehlermeldung "Command \@textsubscript already defined¹". (Windows 7, MiKTeX 2.9, alle Pakte auf dem aktuellsten Stand, getestet mit LyX 2.1.3)
Das auskommentieren der folgenden Zeilen in den KOMA-Script cls-Dateien löst das Problem:¹
\DeclareRobustCommand*\textsubscript[1]{% \@textsubscript{\selectfont#1}% } \newcommand{\@textsubscript}[1]{% {\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}% }
[Admin-Edit:]
Aktuelle KOMA-Script Release
Die aktuelle KOMA-Script-Release finden sich primär im Dateien-Bereich des Projekts KOMA-Script auf SourceForge.
Schnelle Bugfixes und Prereleases finden sich im KOMA-Script-Repository.
Näheres zur aktuellen und früheren Releases ist dem Beitrag »Welches ist die aktuelle KOMA-Script-Release und wo finde ich sie?« zu entnehmen.
Beispiele aus der 7. Auflage des KOMA-Script-Buchs
Hingucker
Sponsoren
In der Reihenfolge der Spendeneingänge:
2024
Paul Kloß, Manuel Kuehner, Julian u. a.
2023
Paul Kloß, Manuel Kuehner, Martin Bierbaum, Ulrich Groh, Elke Schubert u. a.
Näheres zu Kosten und Betrieb ist in einem Blog-Beitrag zu finden. Natürlich sind auch Spenden ohne Namensnennung möglich.
Newsfeeds
Problem nicht nachvollziebar, Lösung Unsinn
Das Problem ist nicht reproduzierbar. Daher kann ich dazu nur allgemein sagen:
In KOMA-Script wird diese Anweisung seit 2001 definiert. Es waren damals die ersten Klassen/Pakete, die das gemacht haben. Schon seit 2011 verwendet KOMA-Script für die Definition von
\@textsubscriptnicht mehr\newcommand, wie bei Dir angegeben, sondern\providecommand, weil fixltx2e diese Anweisung ebenfalls definiert und von manchen Anwendern sogar noch vor der Klasse geladen wird. Seit LaTeX 2015/01/01 definiert bereits der LaTeX-Kern diese Anweisung.Wenn Du also ein Paket lädst, das sich daran stört, dann ist das ein Fehler dieses Pakets und nicht von KOMA-Script. KOMA-Script macht an der Stelle alles richtig.
Wenn Deine Angaben stimmen, also bei Dir tatsächlich noch
\newcommandfür die Definition von\@textsubscriptin den Klassen verwendet wird, sei außerdem ein Update von KOMA-Script empfohlen. Das ist bei Dir dann nämlich extrem veraltet!Darüber hinaus sollte man niemals etwas an den Original-Klassendateien ändern.
Gleiches Problem, Ursache MikTex
Ich hatte heute das gleiche Problem (unter Win 7 64 bit, MikTex 2.9, alle Pakete aktuell).
Meine Lösung:
Ich fand unter C:\Users\<username>\AppData\Roaming\MiKTeX\2.9\tex\latex ein KOMA-Paket von 2011 (Ver. 3.08), das nicht im Paket-Manager aufschien. Dort war das KOMA-Paket nämlich gar nicht installiert.
Ein entfernen des Pakets aus diesem Pfad mittels Explorers und dann Installation mit dem Paket-Manager des aktuellen Paketes brachte den Fehler zum Verschwinden.
Wahrscheinlich sollte der ganze Pfad (samt Unterverzeichnissen) C:\Users\<username>\AppData\Roaming\MiKTeX\ bei mir gelöscht werden, da alle Datein ein Änderungsdatum von 2011 haben, aber das habe ich noch nicht geprüft... Das Verzeichnis dürfte wohl von einer früheren Installation übriggeblieben sein, und im Roots-Tab der Settings habe ich es auch nicht gesehen.
Das MWE dafür war übrigens:
(nur der Vollständigkeit halber)
Hoffe, das hilft...
MiKTeX Update Bug
Verantwortlich ist in der Tat MiKTeX und die Tatsache, dass es Pakte sowohl unter "C:\Program Files (x86)" als auch unter "...\Roaming\..." geben kann. Ruft man das MiKTeX -Update mit dem Zusatz "admin" auf (was ich immer gemacht habe) wird C:\Program Files (x86) aktualisiert - ohne den Zusatz "admin" wird "Roaming" aktualisiert (was ich allerdings bisher nicht gemacht habe). Windows bevorzugt nun Roaming vor C:\Program Files (x86) weshalb bei mir immer ein veraltetes KOMA-Script package geladen wurde.
Der Bug liegt also vielmehr in einem nicht offensichtlichen update-Verhalten von MiKTeX.
Danke theoky für den Tipp in die richtige Richtung.
Kein Bug
Das ist kein Bug, sondern das normale Verhalten von MiKTeX bei einer Multi-User-Installation. Bei der vollautomatischen Auto-Installation von Paketen kann MiKTeX keine Admin-Rechte erlangen. Daher installiert es dann Pakete in einem Benutzer-TEXMF- Baum. Beim Update als Admin wiederum, hat der Admin keinen Zugriff auf die Benutzer-TEXMF-Bäume aller Benutzer. Daher muss man die dort installierten Pakete über den Updatemanager für Benutzer aktualisieren.
Es gibt zwei Auswege:
On-the-fly Installation
Ich hab mir eingebildet, dass ich immer nur mittels Admin-Update und Admin-Paketmanager installiert habe (aber Einbildung ist ja auch eine Bildung und der Baum stammt aus 2011, ist also schon vier Jahre alt...).
Das on-the-fly Nachinstallieren funktioniert bei mir aber mittels Admin-Rechten. Ich verwende TeXstudio und wenn beim Übersetzen ein Paket nachinstalliert werden muss, dann erscheint der MikTeX Package Installation Dialog und der Install-Button hat das Schield-Symbol für die Erlangung der Admin-Rechte.
Ich hab allerdings MikTeX so konfiguriert, dass die Option "Install missing packages on-the-fly" in den Settings auf "Ask me first" steht. Evt. ist das Verhalten bei der Auswahl von "yes" anders...
Einbildung ist bekanntlich auch eine Bildung
Du hast eine nachgefragte Installation. Das ist etwas anderes als die meisten Anwender verwenden. Definitiv installiert MiKTeX der Admin-Paketmanager in demselben Baum wie der Admin-Updatemanager und der Benutzer-Paketmanager in demselben Baum wie der Benutzer-Updatemanager. Darüber hinaus ist es zwar möglich, weitere TEXMF-Bäume zu haben. In diesen installiert MiKTeX selbst aber keine Pakete. Alles weitere dazu erfährst Du bei MiKTeX. Außerdem ist das inzwischen sehr off-topic. Ich verwende MiKTeX auch nicht, sondern beschäftige mich damit nur notgedrungen von Support-Seite aus. Für die MiKTeX-Installationspakete der aktuellen KOMA-Script-Version war diese Beschäftigung aber recht intensiv. Es wäre wünschenswert, wenn sich normale MiKTeX-Anwender wenigstens halb so intensiv mit dem von ihnen verwendeten System beschäftigen würden.