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:]

  1. <code></code> Tags eingefügt (siehe Formatierungshinweise)

forum: 

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 \@textsubscript nicht 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 \newcommand für die Definition von \@textsubscript in 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.

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:

\documentclass{scrartcl}
\begin{document}
Lorem
\end{document} 

(nur der Vollständigkeit halber)

Hoffe, das hilft...

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.

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:

  • Man verwendet für einen einzelnen Anwender keine Multi-User-Installation, sondern eine reine Benutzerinstallation. Dann gibt es keine Werkzeuge, die Admin-Rechte benötigen.
  • Man installiert mit dem Admin-Paketmanager alle Pakete. Dann werden keine Pakete mehr on-the-fly nachinstalliert. Daher benötigt man für ein Update auch nur den Admin-Updatemanager. Falls man noch Benutzerpakete hat, sind diese über den Benutzer-Paketmanager zu löschen.

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...

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.

Comments for "Command \@textsubscript already defined" abonnieren