brikler file pkglist
pkglist: ASCII text, with CRLF line terminators
Die Eingabetextdatei muß eine Unix-Datei sein, also CR LF statt CRLF als Zeilenende.
Das kann mit einer Testdatei auch nachvollzogen werden, z.B.
# file plist.txt
plist.txt: ASCII text, with CRLF line terminators
# pacman -S - < plist.txt
Fehler: Ziel nicht gefunden: a52dec
Fehler: Ziel nicht gefunden: aalib
# pacman -Si - < plist.txt
« wurde nicht gefunden
« wurde nicht gefunden
# $ dos2unix -n plist.txt plist-unix.txt
# pacman -Si - < plist-unix.txt
(funktioniert dann)
Die gleiche Datei im Unix-Textformat funktioniert.
//Edit2:
brikler das liegt eher an pacman
Fehler: Ziel nicht gefunden: zimg
Fehler: Ziel nicht gefunden: zip
Fehler: Ziel nicht gefunden: zlib
Warnung: zstd-1.5.2-7 ist aktuell -- Reinstalliere
[tom@donar ~]$
allerdings, zip ist auch schon installiert, irgendwie erkenne ich keine regel
Hier dürfte zstd einfach die letzte Zeile in der Eingabetextdatei sein, und hat wohl kein Zeilenende-Zeichen. Also kein fehlerhaftes CRLF, im Gegensatz zu den vorhergehenden Zeilen.
Aber natürlich ist immer erst "pacman Schuld"...
Wenn Mist oben in einen Trichter gefüllt wird, dann kann unten auch nur Mist rauskommen ;-)
Und: die Funktion des Trichters (hatte ich ja vorgeschlagen) läßt sich ja sehr einfach durch Testen sicherstellen. My 2 cent...
//Edit3:
brikler allerdings hab ich mir die liste als mail geschickt, damit ich bequem vom neuen laptop zugreifen kann.
streng genommen ist es nicht die gleiche list, sondern eine kopie davon.
Lexikalisch (und in deinem Sinn) vielleicht identisch, aber im Format unterschiedlich. Die Datei mit CRLF ist z.B. um ein Byte pro Zeile größer als die mit nur LF als Zeilentrennzeichen.
Zur Verdeutlichung was da passiert:
In der korrekten Version bekommt pacman aus der Eingabedatei z.B. "a52dec" geliefert. LF als Trennzeichen wird dabei gefiltert, somit wird "a52dec" in der lokalen Syncdatenbank gesucht, gefunden und installiert.
In der fehlerhaften Version bekommt pacman aus der Eingabedatei "a52dec<CR>" geliefert. Das LF Byte wird gefiltert, in der lokalen Syncdatenbank wird somit nach "a52dec<CR>" gesucht. Und das wird nicht gefunden.
In HEX wird's deutlicher. Eine Zeile mit "a52dec" im Win-Format(CRLF) ist:
61 35 32 64 │ 65 63 0D 0A │
Im Unix-Format:
61 35 32 64 │ 65 63 0A
0d ist hier das (unsichtbare) CR-Steuerzeichen, 0a das LF-Zeichen. Und dieses CR/0d wandert halt noch in den Paketnamen, was dann zu "Paket nicht gefunden" führt - obwohl lexikalisch/visuell eigentlich kein Unterschied bestehen mag.