Was sind das denn für fragwürdige Antworten?
Mal so als Hintergrund: Ich arbeite seit 1986 mit *nix Systemen und habe zu den gesamten System(en) inkl. der Software vermutlich mehr beigetragen, als die meisten Foren Nutzer hier zusammen.
stefanhusmann Keine Ahnung. Vermutlich die Mechanismen der ksh selbst.
Wie soll ein Executable, dass von root
nicht mal aufgerufen wurde, Änderungen am Filesystem (Erzeugen von Hardlinks unter /usr
und /usr/bin
) vorgenommen haben ???
Und auch der einmalige Start unter meinem User-Account kann das nicht erzeugt haben, denn diese ksh lief nicht mit setuid 0 und zudem zeigten die Hardlinks unmittelbar vor dem Löschen des offiziellen Pakets auf eben dessen Executables (Andere inodes!).
Das Readme in dem neu übersetzten ksh-Baum stellt auch klar, dass
Automated installation is not supported yet.
Das müsste man wohl kaum schreiben, wenn man wüsste, dass das Executable sich quasi wie ein Virus selbst in die relevanten Stellen "kopiert", sobald es die dafür nötigen Rechte besitzt.
Dirk Ist bei Software die bald seit 10 Jahren kein Update mehr erhalten hat schwer zu sagen.
Das galt nur für die 93u+, die ich eigentlich haben wollte. Die 93u+m ist wesentlich neuer, wird aber nicht mehr bei AT&T entwickelt.
Dirk der modernen Verzeichnishierarchie zurecht kommt
Und jetzt erklär Du mir mal, was sich an der hier relevanten "modernen Verzeichnishierarchie" seit 40 Jahren geändert haben soll ...
Dirk Gerade, wenn man wild irgendwelche Binarys irgendwo hin und her kopiert.
Ich kopiere nicht "wild" irgendwas hin und her. /usr/local/bin
war seit jeher und schon bevor es Linux/GNU überhaupt gab - zusammen mit /opt
- ein gängiger Ort, um AddOn-Executables für den User zu installieren. Ob man das mit install
oder cp+chmod
macht, ist dabei vollkommen egal.
Es verbleibt - auch im Hinblick auf die Erstellung eines AUR Pakets - die Frage, weshalb das arch nach dem pacman -R ksh
oder nach Booten diese neuen Hardlinks erzeugt hat. Ich habe sie jedenfalls nicht angelegt.