Das Ziel ist es, mehrere Dateien mit einem bestimmten Muster zu kopieren
und gleichzeitig umzubenennen.
Geht in DOS mit copy:
1
mk b
2
cd a
3
copy *.tx2 ..\b\*.txt
4
eins.tx2 =>> ..\b\eins.txt
5
zwei.tx2 =>> ..\b\zwei.txt
6
drei.tx2 =>> ..\b\drei.txt
Geht nicht in Linux mit cp:
1
mkdir b
2
cd a
3
cp *.tx2 ../b/*.txt
4
cp: das angegebene Ziel '../b/*.txt' ist kein Verzeichnis
Ja, man kann das unter Linux auch anders lösen, z.B. mit einer for
Schleife, siehe:
https://tosbourn.com/copy-rename-multiple-files-linux/
Aber so elegant wie unter DOS scheint es nicht zu gehen.
Falls ich mich irre, dann würde ich gerne wissen, wie es allein mit dem
cp Befehl geht.
Was aber geht wäre eine Ergänzung der Dateinamenserweiterung:
1
cp --suffix=.txt *.tx2 ../b/
2
ls ../b/*.txt
3
eins.tx2.txt
4
zwei.tx2.txt
5
drei.tx2.txt
6
[/quote]
7
8
Interessanterweise scheint die man page hier aber irreführend zu sein:
9
[code]
10
man cp
11
-S, --suffix=ENDUNG
12
Die übliche Endung für Sicherungskopien überschreiben
bzw.
1
LC_ALL=en man cp
2
-S, --suffix=SUFFIX
3
override the usual backup suffix
Die bestehende Dateinamenserweiterung wird nämlich nicht überschrieben,
wie die man page behauptet, sondern lediglich um den angegebenen SUFFIX
String erweitert.
heißen.
Die lange Schreibweise mkdir geht aber natürlich genauso.
[quote]
Wir haben das Jahr 2022!
[/quote]
Ja, und? Für Nostalgierechner ist das immer noch relevant.
[quote]
Und unter DOS gab es noch XCOPY.
[/quote]
Es gab sogar DISKCOPY
Nano schrieb:> Falls ich mich irre, dann würde ich gerne wissen, wie es allein mit dem> cp Befehl geht.
Das kann nicht gehen. Die Wildcard Expansion ist Aufgabe der Shell, cp
sieht nur die resultierenden Files.
Hmmm schrieb:> Nano schrieb:>> Falls ich mich irre, dann würde ich gerne wissen, wie es allein mit dem>> cp Befehl geht.>> Das kann nicht gehen. Die Wildcard Expansion ist Aufgabe der Shell, cp> sieht nur die resultierenden Files.
Hm, okay, dann frage ich mal anders.
Gibt es Shells (bash, zsh, csh usw.) für Linux oder Unix mit der das im
Zusammenhang mit allein dem cp Befehl geht?
Nano schrieb:> Gibt es Shells (bash, zsh, csh usw.) für Linux oder Unix mit der das im> Zusammenhang mit allein dem cp Befehl geht?
Das würde indirekt am gleichen Problem scheitern: Die Shell würde dann
eine expandierte Liste von Source- und Destination-Files liefern, und cp
akzeptiert zwar mehrere Source-Parameter, aber nur einen
Destination-Parameter.
Eine Schleife dürfte schon die eleganteste Lösung sein, das geht aber
schlanker:
for FILE in *.tx2; do cp $FILE "../b/`basename $FILE .tx2`.txt"; done
Nano schrieb:> Hmmm schrieb:>> Nano schrieb:>>> Falls ich mich irre, dann würde ich gerne wissen, wie es allein mit dem>>> cp Befehl geht.>>>> Das kann nicht gehen. Die Wildcard Expansion ist Aufgabe der Shell, cp>> sieht nur die resultierenden Files.>> Hm, okay, dann frage ich mal anders.> Gibt es Shells (bash, zsh, csh usw.) für Linux oder Unix mit der das im> Zusammenhang mit allein dem cp Befehl geht?
Ziemlich sicher nicht. cp erwartet einfach, dass es von der Shell eine
Liste an Dateinamen und keine Wildcards bekommt.
Es entspricht auch nicht der Unix-Philosophie solche Funktionen zu
integrieren. Jedes Tool soll eine Aufgabe erledigen, die dafür aber gut.
Wenn man Dateien kopieren will nimmt man cp. Wenn man Dateien umbenennen
will nimmt man mv oder für komplexere Ersetzungen rename.
Wäre auch irgendwie unsinnig das zu integrieren. Weil wo macht man dann
Schluss? Was ist wenn jemand Textdateien kopieren will und sie
gleichzeitig in PDF konvertieren will. Soll das dann auch von cp
erledigt werden?
Danke für deine Erklärung.
Das ist schon interessant, dass man in DOS noch Sachen entdeckt, die
sogar "mächtiger" sind als in Linux.
Für den RENAME bzw. REN Befehl (bzw. MOVE ab DOS 6) gilt übrigens das
gleiche. Da kommt man unter Linux mit nur mv auch nicht weiter.
Nano schrieb:> Das ist schon interessant, dass man in DOS noch Sachen entdeckt, die> sogar "mächtiger" sind als in Linux.
Das war eben ein anderes Konzept. Hatte den Nachteil, dass jedes
Commandline-Tool sich selbst um Wildcard-Expansion kümmern musste, aber
daraus ergaben sich dann auch solche Möglichkeiten.
Hermann K. schrieb:> Jedes Tool soll eine Aufgabe erledigen, die dafür aber gut.
Genau, und durch Features wie Pipes gibt es interessante
Kombinationsmöglichkeiten. Hier mal eine Spielerei-Version der obigen
Aufgabe ohne cp und Schleifen, dafür mit GNU-tar:
tar cf - *.tx2 | tar xf - --transform 's/tx2$/txt/' -C ../b
Wenn Befehle wie cp wildcards nehmen würden, wäre das schwierig nicht
versehentlich Sicherheitslücken & unerwartete Fehler einzubauen. Denn
vielleicht will man ja eine Datei namens "*" erstellen.
Nano schrieb:> Unter meinem Linux ist rename nicht einmal standardmäßig installiert.
Was linux userspace enthalten soll, ist nicht standardisiert. Es gibt
standards wie posix, aber das war hier nicht vorausgesetzt.
Hmmm schrieb:> Das würde indirekt am gleichen Problem scheitern: Die Shell würde dann> eine expandierte Liste von Source- und Destination-Files liefern, und cp> akzeptiert zwar mehrere Source-Parameter, aber nur einen> Destination-Parameter.
Müsste man dann aber nicht cp darum erweitern, dass es auch mehrere
Destination-Parameter akzeptiert?
Die Expandierung der Wildcards würde so ja weiterhin die Shell
erledigen.
Nano schrieb:> Müsste man dann aber nicht cp darum erweitern, dass es auch mehrere> Destination-Parameter akzeptiert?
Ja, cp müsste dafür z.B. einen Parameter haben, der dafür sorgt, dass
die erste Hälfte der übergebenen Files die Source Files sind und die
zweite Hälfte die Destination Files.
Ziemlicher Aufwand für ein Feature, das man nicht braucht, weil es
(etwas langsamere) Alternativen gibt, die auf jedem unixoiden System
funktionieren.
Hmmm schrieb:> Nano schrieb:>> Müsste man dann aber nicht cp darum erweitern, dass es auch mehrere>> Destination-Parameter akzeptiert?>> Ja, cp müsste dafür z.B. einen Parameter haben, der dafür sorgt, dass> die erste Hälfte der übergebenen Files die Source Files sind und die> zweite Hälfte die Destination Files.>> Ziemlicher Aufwand für ein Feature, das man nicht braucht, weil es> (etwas langsamere) Alternativen gibt, die auf jedem unixoiden System> funktionieren.
Nunja, grep hat man ja auch erweitert.
Wollte man alle Dateien die auf *.txt enden rekursiv mit grep
durchsuchen,
dann musste man früher bspw. folgenden Befehl verwenden:
Heute geht das gleiche schneller, da ohne find und viel einfacher mit
dem --include Parameter:
1
grep --include=*.txt -ir suchbegriff
Da hat man den Aufwand gewagt.
Gut, so ne Suche mit grep wird man wahrscheinlich wesentlich häufiger
benötigen als obiges cp Beispiel und da ist dann zusätzlich eingesparte
Zeit schon ein Vorteil der den Aufwand für die neue Version
rechtfertigt, aber vielleicht macht das auch mal jemand mit cp und mv.
Ich hoffe es mal.
Die althergebrachte Unix-Philosophie ist nunmal, dass jedes Programm nur
genau die Aufgabe erledigen soll, für die es geschaffen wurde, das aber
dafür besonders gut.
Einen der Nachteile dieser Philosophie hast du wortreich benannt.
Die eierlegende Wollmilchsau gibt es halt nicht.
Naja, die Möglichkeiten mit den Wildcards bei dem DOS Befehl sind ja
auch sehr stark beschränkt. Es könnten ja zig andere Varianten gewünscht
sein, wenn es um das gleichzeitige Kopieren und umbenennen von Dateien
geht.
Man könnte Dateien nach bestimmten Mustern in Unterverzeichnisse
verteilen wollen, man könnte prüfen wollen, ob die Zieldatei bereits
existiert und dann einen Zähler einbauen, (z.b. .bak1 .bak2 .bak3,
etc.), man könnte Datumsstempel einsetzen wollen, ...
Da gibt es sicher hunderte Anwendungsfälle. Je nachdem, was man halt so
vor hat.
Ausgerechnet eine bestimmte davon in einen copy-Befehl zu integrieren,
halte ich für Unsinn. Viel besser wäre, man eignet sich etwas
Grundwissen über diverse Standardwerkzeuge wie grep, sed, awk und find
an und kann dann hinterher wirklich alles machen anstatt von Fall zu
Fall nach irgendeinem Parameter oder Ersatz für einen DOS Befehl zu
suchen.
Genau diese "Vorteile" von Linux sorgen halt auch dafür, weshalb es im
Desktop MArkt nicht ankommt.
Für MSDOS bruachst du keinen dicken Schinken um es umfangreich bentuzen
zu können.
Es gibt ein überschaubares Verzeichnis namens DOS, mit dessen Befehlen
bereits alles wichtige zu erledigen ist, vieles selbsterklärend,
notfalls nutzt man halt mal den /H Parameter wenn etwas nicht klar ist.
Auch sind die Dateinamen halbwegs eindeutig.
Bei Linux?
Braucht es einen dicken Wälzer um überhaupt mal eine Übersicht der
vielen Dateien zu erhalten, wozu die eigentlich dienen wie diese
angewendet werden können etc.
Welcher normale Anwender will sich das antun?
Das tun nur Leute denen Computern Spaß macht, die sich gerne damit
beschäftigen, die es als Hobby sehen.
Der Normale Anwender will damit lediglich seine Aufgaben erledigen und
das Teil dann wieder abschalten.
Daher ist das ein gutes Beispiel von vielen anderen, weshalb Linux auf
dem Consumer Markt kein Bein auf den Boden bekommt im Desktop Bereich
Beim handy bekommt man davon nichts mit, da Google es geschickt verpackt
hat.
Solange also Google keine eigene Distribution auf den Markt wirft oder
Apple, wird es sich nicht durchsetzen und weiter bei 1-2% Markanteil
rumdümpeln eher sogar weiter zurückgehen wie es momentan aussieht
"Viel besser wäre, man eignet sich etwas
Grundwissen über diverse Standardwerkzeuge wie grep, sed, awk und find
an und kann dann hinterher wirklich alles machen "
und genau das ist der Punkt den ich meine..
Anders gesagt, manchmal ist weniger, mehr!
Mit diesem Konzept kommt Apple sehr gut auf dem Markt an.
Linux erschlägt einen mit Möglichkeiten und Umwegen um alles erreichen
zu können.
Das ist schlicht nicht Anwenderfreundlich
Donnerblitz schrieb:> Linux erschlägt einen mit Möglichkeiten und Umwegen um alles erreichen> zu können.> Das ist schlicht nicht Anwenderfreundlich
Wäre schön, wenn zur Kenntnis genommen würde, dass es nicht „das Linux“
gibt. Es gibt sehr wohl auch Distributionen, welche die Möglichkeiten
zugunsten einfacher Erlernbarkeit einschränken, und den User vom
darunterliegenden System zu isolieren versuchen. Solche User würden aber
auch nicht mit ›copy‹ in Windows’ Eingabeaufforderung hantieren, so dass
das in diesem Thread irgendwie sowieso völlig am Thema vorbei ist.
oder sowas..ist nicht euer Ernst, oder?
WARNING top
The renaming has no safeguards by default or without any one of
the options --no-overwrite, --interactive or --no-act. If the
user has permission to rewrite file names, the command will
perform the action without any questions. For example, the result
can be quite drastic when the command is run as root in the /lib
directory. Always make a backup before running the command,
unless you truly know what you are doing.
"Wäre schön, wenn zur Kenntnis genommen würde, dass es nicht „das Linux“
gibt. Es gibt sehr wohl auch Distributionen"
Jepp, und das ist wieder so ein gutes Beispiel, das zeigt das zu viel
Vielfallt mehr schadet als nutzt.
Kein Normalanwender steigt bei den vielen Distributionen durch.
Daher ist DAS Linux, wie von mir geschrieben, absolut die richtige
Bezeichnung.
Nur Nerds können mehr als 2 oder 3 Distributionen aus dem Kopf aufsagen
Nano schrieb:> Die bestehende Dateinamenserweiterung wird nämlich nicht überschrieben,> wie die man page behauptet, sondern lediglich um den angegebenen SUFFIX> String erweitert.
Die man page sagt nicht, dass die Dateinamenserweitung ersetzt würde,
sondern der übliche Suffix für Backups ("the usual backup suffix").
Nano schrieb:> Hm, okay, dann frage ich mal anders.> Gibt es Shells (bash, zsh, csh usw.) für Linux oder Unix mit der das im> Zusammenhang mit allein dem cp Befehl geht?
Dann müsste bei dieser Shell cp ein eingebautes Kommando mit
Sonderbehandlung sein. Gerade das soll aber vermieden werden.
Nano schrieb:> Müsste man dann aber nicht cp darum erweitern, dass es auch mehrere> Destination-Parameter akzeptiert?>> Die Expandierung der Wildcards würde so ja weiterhin die Shell> erledigen.
Nein. Wenn es mehrere Destination-Parameter gäbe, dann wüsste cp ja auch
gar nicht, wo die Quellen aufhören und die Ziele anfangen sollen.
Außerdem werden von der Shell ja nur Namen von Dateien aufgelöst, die
auch existieren (pattern matching). Wenn das Ziel noch nicht existiert,
müsste die Shell stattdessen aber diese Namen ja auf irgendeinem Weg
"erfinden" und dazu wiederum den Zusammenhang mit den Quellparametern
kennen. So müsste die Shell also genau wissen, was cp macht und wie es
die Parameter versteht.
Donnerblitz schrieb:> oder sowas..ist nicht euer Ernst, oder?
Deswegen ist’s bei Distributionen für Leute, die sich nicht damit
befassen mögen, in der Regel ein Alias. Für alle Anderen wär’s absolut
nicht anwenderfreundlich, wenn bei jeder popeligen Aktion »Sind Sie
sicher? [j/N]« → »Sind Sie wirklich sicher? [j/N]« → »Also wollen Sie
das nun tatsächlich tun? Bitte schreiben Sie in Großbuchstaben „ja“ oder
„nein“« runtergerödelt werden müsste.
Donnerblitz schrieb:> Nur Nerds können mehr als 2 oder 3 Distributionen aus dem Kopf aufsagen
… alle Anderen lesen ’ne Zeitschrift oder gehen auf eine Seite, in deren
Zielgruppe sie sich befinden, und wissen dann, was sie nehmen können.
Oder sie fragen einfach jemanden in ihrem Bekanntenkreis – der kann
ihnen dann auch gleich bei den ersten Schritten helfen. Nicht zuletzt
gibt es immer noch LUGs, die auch solche Leute gerne unterstützen.
Man kann sich auch was hinkonstruieren, um auf Biegen und Brechen zu
zeigen, dass Linuxsysteme per se nicht anwenderfreundlich wären
(schonmal was von einem System namens „Android“ gehört, btw.? Oder etwas
namens „ChromeOS“?). Richtig ernst wird einen bei diesem verzweifelten
Versuch allerdings keiner mehr nehmen. Egal, ob er sich nun herbert oder
Donnerblitz nennt.
Aber ist hier eigentlich auch OT. On-Topic war die bahnbrechende, völlig
atemberaubende, alles in den Schatten stellende Feststellung, dass das
›copy‹ von DOS anders als das unter unixartigen Systemen verbreitete
›cp‹ arbeitet. Ein Programm funktioniert anders, als ein anderes
Programm – welche Sensation!
Jack V. schrieb:> wenn bei jeder popeligen Aktion »Sind Sie> sicher? [j/N]« → »Sind Sie wirklich sicher? [j/N]« → »Also wollen Sie> das nun tatsächlich tun?
Ernst gemeint Abfragen bauen mittendrin eine inverse Frage ein, um
geübte Durchklicker in die Irre zu führen. ;-)
Hmmm schrieb:> Eine Schleife dürfte schon die eleganteste Lösung sein
Neben Elementen der Shell-Programmierung kann es sich auch lohnen, das
"find" Kommando näher zu kennen. Zumal es recht sinnvoll sein kann, den
Job nicht gleich auf Deibel komm raus live auszuführen, sondern damit
ein Script zu erstellen, das man vorher vorsichtshalber gegenprüft.
(prx) A. K. schrieb:> Ernst gemeint Abfragen bauen mittendrin eine inverse Frage ein, um> geübte Durchklicker in die Irre zu führen. ;-)
Alle Dateien nicht löschen [j/N]?
Nicht alle Dateien nicht löschen [J/n]?
Schimpfe! Rant!
Nano schrieb:> Gut, so ne Suche mit grep wird man wahrscheinlich wesentlich häufiger> benötigen als obiges cp Beispiel und da ist dann zusätzlich eingesparte> Zeit schon ein Vorteil der den Aufwand für die neue Version> rechtfertigt, aber vielleicht macht das auch mal jemand mit cp und mv.> Ich hoffe es mal.
So, du hoffst.
Das schöne an der Linux-Welt und seiner quelloffenen Software ist doch
daß Du es auch selbst machen könntest, wenn Du nur wolltest.
WAIT!
"jemand" hat dieses Problem schon für (auch) dich schon erledigt! Nennt
sich aber dann nicht mehr "cp (weil ja schliesslich nicht nur kopiert
wird), sondern "rename" mit all seinen vielen verschiedenen Versionen
und Derivaten.
Nano schrieb:> Unter meinem Linux ist rename nicht einmal standardmäßig installiert.
Und irgendein Programm nachzuinstallieren ist dir zu viel Aufwand? Ist
dir also geschenkt noch zu teuer?
Eine traurige Einstellung, aber Du bist damit nicht allein, deswegen hat
M$ ja schliesslich einen riesigen kommerziellen Erfolg. Viele Menschen
Denken so wie Du. Traurig, aber wahr: dieser "jemand" hat kein Geld
bekommen, ja nocht nicht einmal seinen Namen im Produktnamen oder in der
Versionsnummer verewigt... in der M$-Welt bekommt so ein "jemand" für
seine Tools richtig Schotter, da beschwert sich keiner wenns nicht so
läuft wie es soll, "dann ist das halt so". Verkehrte Welt.
Will keinem ans Bein Pinkeln, aber das musste raus :-(
Donnerblitz schrieb:> Genau diese "Vorteile" von Linux sorgen halt auch dafür, weshalb es im> Desktop MArkt nicht ankommt.> Für MSDOS bruachst du keinen dicken Schinken um es umfangreich bentuzen> zu können.
Es steht dir frei ein Linux mit nur BusyBox zu haben: da ist der Umfang
auch nur so wenig wie Du es verarbeiten magst ohne überfordert zu
werden.
> Es gibt ein überschaubares Verzeichnis namens DOS, mit dessen Befehlen> bereits alles wichtige zu erledigen ist, vieles selbsterklärend,> notfalls nutzt man halt mal den /H Parameter wenn etwas nicht klar ist.> Auch sind die Dateinamen halbwegs eindeutig.> Bei Linux?
s. BusyBox.
> Braucht es einen dicken Wälzer um überhaupt mal eine Übersicht der> vielen Dateien zu erhalten, wozu die eigentlich dienen wie diese> angewendet werden können etc.
Wenn jedes einzelne Tool seine eigene Variante mit eigenen Erweiterungen
von '*' + '?' Implementiert, wird es für Anwender schwieriger sich zu
merken was wo gilt und was wo nicht gilt. Unabhängig von der Dicke des
Wälzers.
> Welcher normale Anwender will sich das antun?
Intelligente und lernfähige/-willige Anwender welche Grenzen von zu kurz
gedachte Konzepte erkennen und auf konsistentere, langlebigere, zur
Modularität taugende Konzepte umsteigen; sie sind dazu bereit das auf
Holzwege
leicht erlernte simple Einsteigerwissen zu vergessen und dafür besseres
Wissen aufzunehmen.
(DOS: ca.1982...1995 vs. UNIX: ca.1972...202x-und-kein-Ende-in-Sicht )
> Das tun nur Leute denen Computern Spaß macht, die sich gerne damit> beschäftigen, die es als Hobby sehen.
Du könntest auch bei CP/M bleiben: da musst Du dich nicht mit so
Anforderungshohe Konzepte wie Unterverzeichnisse rumschlagen.
> Der Normale Anwender will damit lediglich seine Aufgaben erledigen und> das Teil dann wieder abschalten.
Deine Kalibrierung von "Normale Anwender" scheint leergelaufen zu sein,
schütte doch eine Dose Justierung nach.
> Daher ist das ein gutes Beispiel von vielen anderen, weshalb Linux auf> dem Consumer Markt kein Bein auf den Boden bekommt im Desktop Bereich> Beim handy bekommt man davon nichts mit, da Google es geschickt verpackt> hat.> Solange also Google keine eigene Distribution auf den Markt wirft oder> Apple, wird es sich nicht durchsetzen und weiter bei 1-2% Markanteil> rumdümpeln eher sogar weiter zurückgehen wie es momentan aussieht
Bleib Du ruhig in deiner begrenzten Consumer-Komfortzone; Konsum
bedeutet ja auch dass Zubehör, Erweiterungen und "das Nächste Ding"
bequem gegen Geld zu haben ist. Die Anbieter werden sich garantiert
bemühen dir sowas zu verkaufen, selbstverständlich erst nachdem mit der
vorgestrigen und der gestrigen Ware definitiv keine Konsumenten mehr
abzuschröpfen sind. Der Markt Regelt schliesslich.
Zu Apple, Google und auch Microsoft Weise ich nur auf folgendes hin.
Apple hat vor gut 20J das klassische MacOS hinter sich gelassen und mit
OSX auf unixoiden (BSD) Kern + Konzepte gesetzt (wobei Apple bereits
über weitere 10J davor schon A/UX im Angebot hatte, ab 68030, für Kunden
mit Normalem Grips...)
Damals (vor 20J) gab es noch kein Android von G. (und vor 30J noch kein
Google)
Mittlerweile gibt es WSL2 von Microsoft...
Irgendwas muss an den Grundkonzepte von Unics/BSD/Linux & co. doch dran
sein dass sie immer wieder und immernoch "neu übernommen" werden, obwohl
sie "kein Geld abwerfen"...
NB: man könnte die Überlegenheit des Zehnersystems mit arabischen
Ziffern infrage stellen, ggü z.B Römischen Zahlen. Oder metrischen
Gewinden. Oder die Rundheit von Rädern...
Michi schrieb:> Naja, die Möglichkeiten mit den Wildcards bei dem DOS Befehl sind ja> auch sehr stark beschränkt. Es könnten ja zig andere Varianten gewünscht> sein, wenn es um das gleichzeitige Kopieren und umbenennen von Dateien> geht.>> Man könnte Dateien nach bestimmten Mustern in Unterverzeichnisse> verteilen wollen,
Dafür würdest du den Befehl ja nochmal mit anderem Unterverzeichnis
eingeben.
> man könnte prüfen wollen, ob die Zieldatei bereits> existiert
Das macht weder cp und mv unter Linux, noch copy und ren unter DOS und
das weiß man auch, weil das schon immer so war.
> und dann einen Zähler einbauen, (z.b. .bak1 .bak2 .bak3,> etc.),
Ja, könnte man. Dafür hätte man eine andere Form von Wildcard einführen
können. Wie wäre es mit # gefolgt von der zu startenden Zahl?
Für das Ausklammern hätte man # dann halt nicht mehr benutzen dürfen
> man könnte Datumsstempel einsetzen wollen, ...
Das gehört nun wirklich in den Bereich von umfangreichen Skripten
> Ausgerechnet eine bestimmte davon in einen copy-Befehl zu integrieren,> halte ich für Unsinn.
Obiges mit dem Umbenennen mehrere Dateien beim Kopieren ist jetzt nicht
wirklich außergewöhnlich. Das passt schon noch in die Grundfähigkeiten
eines Copy Befehls. Denn mit Einzeldateien geht das ja auch.
> Viel besser wäre, man eignet sich etwas> Grundwissen über diverse Standardwerkzeuge wie grep, sed, awk und find> an und kann dann hinterher wirklich alles machen anstatt von Fall zu> Fall nach irgendeinem Parameter oder Ersatz für einen DOS Befehl zu> suchen.
Für komplexere Sachen gibt es bei DOS die Batchdateien.
Donnerblitz schrieb:> notfalls nutzt man halt mal den /H Parameter wenn etwas nicht klar ist.
Der Parameter heißt unter DOS "/?", nicht "/H".
> Daher ist das ein gutes Beispiel von vielen anderen, weshalb Linux auf> dem Consumer Markt kein Bein auf den Boden bekommt im Desktop Bereich
Das glaube ich jetzt weniger, denn die Kommandozeile wird von Laien
schon lange nicht mehr benutzt. Die haben dafür ja ihre Dateimanger mit
Mausbedienung.
foobar schrieb:>> copy *.tx2 ..\b\*.txt>> Dafür gibt es mmv/mcp/mln/mad:> mcp "*.tx2" "../b/#1.txt"
Ja, das ist ein extra Paket, sofern überhaupt im Repository, das
normalerweise nicht vorinstalliert ist.
Es gehört weder zum POSIX Standard, noch kann man davon ausgehen, dass
es üblicherweise vorhanden ist.
Sollte man also mal ein Skript erstellen (z.b. für eine Installation aus
einem tar.gz Paket), dann kann man sich darauf nicht verlassen.
Insofern ist das nur eine Behelfslösung.
Donnerblitz schrieb:> oder sowas..ist nicht euer Ernst, oder?>> WARNING top> The renaming has no safeguards by default or without any one of> the options --no-overwrite, --interactive or --no-act. If the> user has permission to rewrite file names, the command will> perform the action without any questions. For example, the result> can be quite drastic when the command is run as root in the /lib> directory. Always make a backup before running the command,> unless you truly know what you are doing.
DOS hat in dem Bereich auch keine Absicherung.
Du kannst mit RENAME bwz. REN und COPY alles im Zielverzeichnis
überschreiben ohne das du gefragt wirst und musst bzw. solltest daher
vorher nachgucken.
Beim Löschen von Dateien mit ERASE oder DEL ist es übrigens genauso.
Willst du hier gefragt werden, dann musst du den Parameter /P zusätzlich
verwenden.
Gefragt wirst du ohne dieses Parameter nur bei der Ausnahme, wenn du mit
DEL *.* alles löschen willst, diese Abfrage kann allerdings in DOS auch
nicht unterbunden werden, was sie für Skripte ungeeignet macht.
Erst in Windows NT gab es dafür den Parameter /Q um eine Abfrage dann zu
unterbinden.
Rolf M. schrieb:> Nano schrieb:>> Die bestehende Dateinamenserweiterung wird nämlich nicht überschrieben,>> wie die man page behauptet, sondern lediglich um den angegebenen SUFFIX>> String erweitert.>> Die man page sagt nicht, dass die Dateinamenserweitung ersetzt würde,> sondern der übliche Suffix für Backups ("the usual backup suffix").
Dann ist das trotzdem unglücklich ausgedrückt, denn ein Backup bzw. eine
Sicherungskopie kann auch eine einfache Kopie der Datei in ihrer
ursprünglichen Namensform sein.
Wenn damit nur Archivdateien gemeint sind, dann sollten die konkret
benannt werden.
Außerdem ist es unüblich, eine normale Datei in eine Archivdatei (z.b.
tar.gz) umzubenennen, ohne dass es ein Archiv ist. Wer macht so etwas?
Wollte man ein Archiv haben, dann würde man die entsprechend
Archivprogramme wie tar und Packprogramme verwenden.
> Nano schrieb:>> Müsste man dann aber nicht cp darum erweitern, dass es auch mehrere>> Destination-Parameter akzeptiert?>>>> Die Expandierung der Wildcards würde so ja weiterhin die Shell>> erledigen.>> Nein. Wenn es mehrere Destination-Parameter gäbe, dann wüsste cp ja auch> gar nicht, wo die Quellen aufhören und die Ziele anfangen sollen.
Warum sollte es das nicht wissen?
Bei einer von der Shell übergebenen Liste von Destinationdateien wird
einfach die nächste Datei aus der Sourcedateiliste genommen.
Jack V. schrieb:> Aber ist hier eigentlich auch OT. On-Topic war die bahnbrechende, völlig> atemberaubende, alles in den Schatten stellende Feststellung, dass das> ›copy‹ von DOS anders als das unter unixartigen Systemen verbreitete> ›cp‹ arbeitet. Ein Programm funktioniert anders, als ein anderes> Programm – welche Sensation!
Es ist ein einfacher Copy Befehl und er kann faktisch mehr.
Warum er mehr kann, wurde oben begründet, das ändert aber nichts an der
Feststellung.
2aggressive schrieb:>
> Das schöne an der Linux-Welt und seiner quelloffenen Software ist doch> daß Du es auch selbst machen könntest, wenn Du nur wolltest.
Danke, jetzt weiß ich, dass du dieses Feature noch viel mehr willst und
benötigst als ich.
> WAIT!> "jemand" hat dieses Problem schon für (auch) dich schon erledigt! Nennt> sich aber dann nicht mehr "cp (weil ja schliesslich nicht nur kopiert> wird), sondern "rename" mit all seinen vielen verschiedenen Versionen> und Derivaten.
Falsch. Rename löscht die Quelle, was bei einem Kopieren ja nicht
gewünscht wäre.
Du hättest mcp sagen müssen, hast du aber nicht. Und cp wird damit immer
noch nicht zu mcp, was ja dein Wunsch ist.
> Nano schrieb:>> Unter meinem Linux ist rename nicht einmal standardmäßig installiert.> Und irgendein Programm nachzuinstallieren ist dir zu viel Aufwand? Ist> dir also geschenkt noch zu teuer?
Vielleicht wollte man genau das ohne for Schleife mal für ein Skript
nutzen und das Skript an Dritte verteilen. Schonmal daran gedacht?
> Eine traurige Einstellung, aber Du bist damit nicht allein, ...> Viele Menschen Denken so wie Du. Traurig, aber wahr: ...
Durch deinen persönlichen Angriff kriegst du das von dir gewünschte
Feature auch nicht in cp rein.
> Will keinem ans Bein Pinkeln, aber das musste raus :-(
Du hast einfach Komplexe, weil jemand den Sandhaufen eines anderen
kritisiert hast, den du als deinen betrachtest.
Leider ein oft gesehen Phänomen in der Linux Community, weil es Leuten
wie dir an Offenheit fehlt auch mal die eigenen Standpunkte zu
hinterfragen.
Glücklicherweise zeigen dieses Verhalten in den meisten Fällen nur die
Nichtentwickler, die selbst nicht entwickeln können und im Kern steckt
als Ursache der Grund dahinter, weil sie dieses Feature selber wollen.
Durch einen Angriff der Person, anstatt auf die Sache einzugehen, wird
dann versucht die Person zum Entwickeln zu bringen, in der Hoffnung,
dass diese Zielperson das kann, weil Typen wie du das selber nicht
können.
man cp
--backup[=CONTROL]
make a backup of each existing destination file
-S, --suffix=SUFFIX
override the usual backup suffix
Kann man nicht falsch verstehen.
> man könnte prüfen wollen, ob die Zieldatei bereits existiert> Das macht weder cp und mv unter Linux, noch copy und ren unter DOS und> das weiß man auch, weil das schon immer so war.
Nö, das weiß man nicht. Und mit dem ›das war schon immer so‹
-i, --interactive
prompt before overwrite (overrides a previous -n option)
Kritik anbringen ist vollkommen OK. Sie sollte allerdings fundiert sein
und die Fakten überprüft.
Nebenbei, viele der in Gebrauch befindlichen Shells stellen einen
bequemen Alias Mechanismus zur Verfügung. Wenn man etwas häufig braucht,
baut man es sich in Minuten selbst und nutzt es fortan bis in alle
Ewigkeit. (Die kleinen Helferlein könnten zB. heißen: find, xargs, sed.
(Alles Standardwerkzeuge))
Aber Obacht, es könnte passieren das man - ohne es zu wollen -
feststellt wie leistungsfähig das alles ist.
Nano schrieb:>> Die man page sagt nicht, dass die Dateinamenserweitung ersetzt würde,>> sondern der übliche Suffix für Backups ("the usual backup suffix").>> Dann ist das trotzdem unglücklich ausgedrückt, denn ein Backup bzw. eine> Sicherungskopie kann auch eine einfache Kopie der Datei in ihrer> ursprünglichen Namensform sein.
Das verbietet ja auch keiner. Nur möchte man z.B. manchmal vor der
Bearbeitung einer Datei den bisherigen Stand sich merken, um notfalls
dahin zurück kehren zu können. Viele Programme machen das auch im
Hintergrund automatisch. Da wird dann z.B. eine Datei mit gleichem
Namen, aber angehängtem ~ (der Default für den Backup-Suffix) draus.
Unter Windows scheint ".BAK" als Suffix dafür häufiger vorzukommen.
Und genau um diese Art geht es beim "usual backup suffix", was man in
der Man-Page auch alles nachlesen kann.
> Wenn damit nur Archivdateien gemeint sind, dann sollten die konkret> benannt werden.> Außerdem ist es unüblich, eine normale Datei in eine Archivdatei (z.b.> tar.gz) umzubenennen, ohne dass es ein Archiv ist. Wer macht so etwas?
Keiner. Deshalb frage ich mich, wie du da überhaupt drauf kommst.
> Wollte man ein Archiv haben, dann würde man die entsprechend> Archivprogramme wie tar und Packprogramme verwenden.
Wer steckt eine einzelne Datei in ein tar-File?
>> Nein. Wenn es mehrere Destination-Parameter gäbe, dann wüsste cp ja auch>> gar nicht, wo die Quellen aufhören und die Ziele anfangen sollen.>> Warum sollte es das nicht wissen?
1
cp a b c d e f g
Was davon ist Quelle, was Ziel? Bei cp ist der letzte der Einträge immer
das Ziel. Da es auch immer nur genau ein Ziel gibt, ist das auch klar
und eindeutig. Du erwartest jetzt, dass cp nun auf magische Weise
erkennt, dass du das jetzt anders gemeint hast und es stattdessen
mehrere Ziele geben soll.
> Bei einer von der Shell übergebenen Liste von Destinationdateien wird> einfach die nächste Datei aus der Sourcedateiliste genommen.
Es gibt nicht die "Liste von Destinationsdateien" und die
"Sourcedateienliste", die an cp übergeben werden. cp bekommt einfach
eine Reihe einzelner Namen übergeben, und das war's.
Rolf M. schrieb:> Unter Windows scheint ".BAK" als Suffix dafür häufiger vorzukommen.
Windows NT war ja über den Chefentwickler von DEC VMS inspiriert - aber
diese Feature von VMS wurde interessanterweise nicht übernommen:
automatische Versionierung von Files, mit sowas wie nix.txt;3 nix.txt;4
als automatisch vorgehaltene Vorversionen. Dann muss das nicht jedes
Programm selbst erledigen.
https://en.wikipedia.org/wiki/Versioning_file_system
Norbert schrieb:>> man könnte prüfen wollen, ob die Zieldatei bereits existiert>> Das macht weder cp und mv unter Linux, noch copy und ren unter DOS und>> das weiß man auch, weil das schon immer so war.> Nö, das weiß man nicht. Und mit dem ›das war schon immer so‹
Man sollte es wissen, wenn man einen Computer benutzt.
Jeder früher DOS benutzt hat, konnte das auch durch schmerzhafte
Erfahrung auch einfach lernen.
> -i, --interactive> prompt before overwrite (overrides a previous -n option)
Das ändert an meiner Aussage überhaupt gar nichts, denn -i ist ein extra
Parameter, den man extra angeben muss. Es geht hier aber um die
defaultvorgehensweise von cp und COPY ohne extra Parameter.
> Kritik anbringen ist vollkommen OK. Sie sollte allerdings fundiert sein> und die Fakten überprüft.
Man sollte sie vor allem auch verstehen, dann könnte man sich viel
Schreibarbeit sparen.
Wo stand etwas von ›Default‹?
Wo stand etwas von ›ohne Flags‹?
> Das macht weder cp und mv unter Linux, noch copy und ren unter DOS
Dir ist schon klar das du damit beide Systeme meinst?
Dann sollten deine Aussagen auch für beide gültig sein.
> Man sollte sie vor allem auch verstehen, dann könnte man sich viel> Schreibarbeit sparen.
Korrekt. Und man würde sich logische Fehlschlüsse sparen!
Rolf M. schrieb:>> Wenn damit nur Archivdateien gemeint sind, dann sollten die konkret>> benannt werden.>> Außerdem ist es unüblich, eine normale Datei in eine Archivdatei (z.b.>> tar.gz) umzubenennen, ohne dass es ein Archiv ist. Wer macht so etwas?>> Keiner. Deshalb frage ich mich, wie du da überhaupt drauf kommst.
Wenn man ein Backup macht, dann nutzt man aus Platzgründen dafür oft die
üblichen Tools wie tar, sowie die entsprechenden Kompressionsalgorithmen
oder die Kompressionsprogramme an sich.
>> Wollte man ein Archiv haben, dann würde man die entsprechend>> Archivprogramme wie tar und Packprogramme verwenden.>> Wer steckt eine einzelne Datei in ein tar-File?
Du hast mich falsch verstanden.
Bei Backups sichert man in der Regel mehrere Dateien.
Wenn du einen Ordner mit Office Dokumenten hast, dann möchtest du in
deinem Backup ja nicht nur ein einzelnes bestimmtes Office Dokument
haben, sondern in der Regel alle.
Und da ist tar gefolgt von einem Kompressionsalgorithmus ein übliches
Tool.
Vor allem wenn man im Kontext von "Backup Dateiendungen" spricht.
>>> Nein. Wenn es mehrere Destination-Parameter gäbe, dann wüsste cp ja auch>>> gar nicht, wo die Quellen aufhören und die Ziele anfangen sollen.>>>> Warum sollte es das nicht wissen?>>
1
> cp a b c d e f g
2
>
Falscher Befehl.
Geb ihn richtig an, so wie oben.
Also
1
cp *.tx1 /media/backup/*.txt
Jetzt wäre es klar, sofern es umgesetzt werden würde.
Nano schrieb:> Das macht weder cp und mv unter Linux, noch copy und ren unter DOS und> das weiß man auch, weil das schon immer so war.
...weil das schon immer so... äh, ja. Vielleicht sollten wir uns an
dieser Stelle auch noch einmal daran erinnern, daß das Konzept der
Dateinamenerweiterungen "schon immer" ein inhärentes Konzept von DOS war
und es bis heute unter Windows noch ist, während das unter UNIXoiden
"schon immer" von vielen Anwendern und Anwendungen benutzt wird, aber
eben kein Kernbestandteil des Systems ist. Deswegen kann DOS' "copy"
viel einfacher auf Dateinamenerweiterungen operieren als cp(1), für den
die Dateinamenerweiterung ganz normal zum Dateinamens gehört.
Norbert schrieb:> Wo stand etwas von ›Default‹?> Wo stand etwas von ›ohne Flags‹?
Das geht alles aus dem Kontext von Donnerblitz ursprünglichen Kommentar
hervor.
Der Kontext besagt Einfachheit bei Default.
Also einfach mal mitdenken wie er es gemeint hat und sich dann in seine
Sichtweise einverstandenen, dann fällt das sofort auf.
Die Zugabe von zusätzlicher Komplexität, also weiterer Parameter an die
man als Nutzer denken müsste, die man nicht vergessen dürfte usw. sind
keine Einfachheit, um die es Donnerblitz hier ging.
>> Das macht weder cp und mv unter Linux, noch copy und ren unter DOS> Dir ist schon klar das du damit beide Systeme meinst?> Dann sollten deine Aussagen auch für beide gültig sein.
Ich habe das oben bereits alles richtig geschrieben.
>> Man sollte sie vor allem auch verstehen, dann könnte man sich viel>> Schreibarbeit sparen.>> Korrekt. Und man würde sich logische Fehlschlüsse sparen!
Dann fasse dich mal den Kopf.
Nano schrieb:> Also einfach mal mitdenken wie er es gemeint hat und sich dann in seine> Sichtweise einverstandenen,
Sorry, ich meinte natürlich hineinversetzen.
Ein T. schrieb:> daß das Konzept der> Dateinamenerweiterungen "schon immer" ein inhärentes Konzept von DOS war> und es bis heute unter Windows noch ist
Auf API-Ebene gibts schon einen erheblichen Unterschied zwischen MSDOS
und moderneren Wegen, mit Files zu arbeiten. Im DOS API wird ein
Filename in alter CP/M Tradition als "MAIN C " in name[8],ext[3]
dargestellt. Spätere APIs und damit auch Win32 lösten sich mit "FILE.C"
längst davon, bereits die Darstellung in Programmen und der Shell von
DOS.
Inwieweit solche Filetypen bzw Extensions ein Teil des Konzepts von
Betriebssystemen auf Anwendungsebene sind, in Shells und Explorern, ist
davon längst völlig unabhängig.
NB: Ende der 60er brachte IBM das Mainframe Betriebssystem CMS, das zu
den Inspirationsquellen von CP/M zählt. Darin ist die Extension ein
zweiter Name wie in DOS. Files werden darin durchweg über separate
Strings identifiziert, wie "FILE" und "C". Aber nicht nur intern,
sondern auch auf Shell-Ebene (Stand Anfang der 80er).
Ein T. schrieb:> Vielleicht sollten wir uns an> dieser Stelle auch noch einmal daran erinnern, daß das Konzept der> Dateinamenerweiterungen "schon immer" ein inhärentes Konzept von DOS war> und es bis heute unter Windows noch ist, während das unter UNIXoiden> "schon immer" von vielen Anwendern und Anwendungen benutzt wird, aber> eben kein Kernbestandteil des Systems ist.
Man muss eigentlich froh sein, dass das Konzept der
Dateinamenserweiterungen von den Nutzern auch unter UNIXoiden Systemen
weiter benutzt wird.
Denn es wäre schon sehr umständlich, wenn man in einem Verzeichnis das
mit hunderten verschiedenen Dateiformaten belegt ist und die man in ihre
eigene Unterordner zwecks einer besseren Organisation verschieben
wollte, mit dem Tool "file" Ordnung schaffen müsste, nur um zu sehen, um
was für einen Dateityp es sich handelt.
Nano schrieb:>>> cp a b c d e f g>>>> Falscher Befehl.
Nein.
> Geb ihn richtig an, so wie oben.
Der Punkt ist, dass cp die Namen immer in dieser Form bekommt. Wenn du
also keine Antwort auf meine Frage hast, kann das so nicht
funktionieren, wie du es willst.
> Also> cp *.tx1 /media/backup/*.txt>> Jetzt wäre es klar, sofern es umgesetzt werden würde.
Ja, dir. Aber cp nicht, denn das bekommt seine Parameter in der von mir
angegebenen Form übergeben. Die Transformation von dem, was du
geschrieben hast macht die Shell, wie schon mehrfach gesagt wurde.
Sagen wir mal, du hast folgende Dateien in einem Verzeichnis:
1
a.txt
2
b.png
3
c.txt
Wenn du jetzt schreibst:
1
cp *.txt mydir
Dann macht die Shell daraus erst mal:
1
cp a.txt c.txt mydir
und führt das dann aus. Es passiert also exakt das gleiche, also ob du
diese Zeile eingegeben hättest.
Wenn du jetzt schreiben würdest:
1
cp *.txt *.xyz
Dann würde die Shell daraus erstmal machen:
1
cp a.txt b.txt *.xyz
Das *.txt wird als Suchpattern verwendet, und alle Dateien, die ihm
entsprechen, werden als einzelne Parameter an cp übergeben. Das *.xyz
wird selbstverständlich auf die selbe Art behandelt. Da aber keine Datei
existiert, die diesem Pattern entspricht, wird es so wie es ist an cp
übergeben. Das heißt jetzt, dass cp als Ziel nach einem Verzeichnis
sucht, das *.xyz heißt.
Wenn die Shell das nun so machen würde, wie du dir wünschst, müsste sie
wissen, dass das *.xyz eine andere Bedeutung hat als das *.txt und
komplett anders behandelt werden muss. Außerdem müsste sie wissen, dass
die beiden in einem bestimmten Zusammnhang zu einander stehen (für jeden
Namen, der zu *.txt der ersten Wildcard gefunden wurde, erzeuge einen
neuen Namen, bei dem das .txt durch .xyz ersetzt wird. Und das soll aber
natürlich nur für cp so sein. Also muss die Shell sehr genau darüber
bescheid wissen, wie cp funktionert und eine Sonderregel extra dafür
umsetzen. Das sind aber getrennte Tools, die eigentlich völlig
unabhängig von einander sind.
(prx) A. K. schrieb:> Inwieweit solche Filetypen bzw Extensions ein Teil des Konzepts von> Betriebssystemen auf Anwendungsebene sind, in Shells und Explorern, ist> davon längst völlig unabhängig.
Wenn eine Datei nicht auf .exe oder .scr oder .bat endet, kann ich sie
nicht ausführen.
> NB: Ende der 60er brachte IBM das Mainframe Betriebssystem CMS, das zu> den Inspirationsquellen von CP/M zählt. Darin ist die Extension ein> zweiter Name wie in DOS. Files werden darin durchweg über separate> Strings identifiziert, wie "FILE" und "C". Aber nicht nur intern,> sondern auch auf Shell-Ebene (Stand Anfang der 80er).
Es wäre sinnvoll, ein eigenes Attribut für den Dateityp zu haben. MacOS
macht das auch so. Da sind die Namensendungen nur Deko.
Unter Linux haben viele Tools noch ein etwas ausgeklügelteres Vorgehen,
indem sie zuerst versuchen, die Datei am Inhalt (z.B. einem Header am
Dateianfang) zu erkennen.
Donnerblitz schrieb:> Genau diese "Vorteile" von Linux sorgen halt auch dafür, weshalb> es im> Desktop MArkt nicht ankommt.
Ernsthaft? Ist das getrolle oder echte Blödheit?
Wer von den Windowsusern kennt denn cmd.com?
cmd.com hat garantiert nichts mit der Verbreitung von Windows, Linux
oder DOS zu tun.
Nano schrieb:> Denn es wäre schon sehr umständlich, wenn man in einem Verzeichnis das> mit hunderten verschiedenen Dateiformaten belegt ist und die man in ihre> eigene Unterordner zwecks einer besseren Organisation verschieben> wollte, mit dem Tool "file" Ordnung schaffen müsste, nur um zu sehen, um> was für einen Dateityp es sich handelt.
Mit Extended Attributes ging OS/2 einen etwas anderen Weg. Bei dieser
Idee steht getrennt von der primitiven Fileextension aus der CP/M
Vergangenheit neben allerlei anderem Kram wirklich eine Assoziation zum
Programm drin, das damit umgehen kann. Ob das File "main.c", "main.prx"
oder bloss "main" heisst - egal.
Da allerdings - anders als bei "main.c" - der Anwender diese Assoziation
nicht so ohne Weiteres zu sehen bekommt, entsteht ein ähnliches
Sicherheitsproblem wie bei Microsofts Gewohnheit, Extensions im Explorer
nicht anzuzeigen. Man hat keine Ahnung, was man auslöst, wenn man auf
ein File aus unzuverlässiger Quelle draufklickt. Wenn da bloss "main"
steht, und nur in Listendarstellung dahinter der Typ, kanns auch ein
"main.exe" sein. Sehr beliebt als "rechnung.pdf.exe".
NB: Wahrscheinlich davon inspiriert gibt es in Windows bis heute im NTFS
die Alternate Data Streams. So richtig eingeschlagen haben die aber bis
heute nicht und in ReFS sind sie verschwunden.
Rolf M. schrieb:> Wenn eine Datei nicht auf .exe oder .scr oder .bat endet, kann ich sie> nicht ausführen.
Gilt das auch für den Win32 API, oder bloss in Shells und Explorer?
Rolf M. schrieb:> Wenn eine Datei nicht auf .exe oder .scr oder .bat endet, kann ich sie> nicht ausführen.
Versuch macht kluch: Kopiere ein beliebiges .exe File zu main.c und
tippe im CMD main.c ein. Es startet das kopierte Programm. Die GUI mag
sich um sowas scheren, aber sogar dem CMD ist es schnuppe. Dem Win32 API
sowieso.
diesem "uns" findet sich keine Wohnadresse schrieb:> da ist der Umfang> auch nur so wenig wie Du es verarbeiten magst ohne überfordert zu> werden.
HEHE
gar nicht weiter gelesen.
Genau diese Einstellung ist der Grund weshalb Linux sogar eher
rückläufig auf dem Desktop ist.
Und offenbar hat es die Community immer noch nicht begriffen und spielt
weiter mit ihrem Linux.
Na denn...viel Spaß
> Das *.txt wird als Suchpattern verwendet, und alle Dateien, die ihm> entsprechen, werden als einzelne Parameter an cp übergeben. Das *.xyz> wird selbstverständlich auf die selbe Art behandelt. Da aber keine Datei> existiert, die diesem Pattern entspricht, wird es so wie es ist an cp> übergeben. Das heißt jetzt, dass cp als Ziel nach einem Verzeichnis> sucht, das *.xyz heißt.
Und ab dem Punkt könnte cp wissen, wenn man es ihm beibrächte, dass es
beim Ziel *.xyz, erkennbar durch das glücklicherweise nun nicht
aufgelöste * dieses durch die vorherigen Dateien der Reihe nach
substituieren muss.
Aus
1
cp a.txt b.txt *.xyz
wird also:
1
cp a.txt a.xyz
2
cp b.txt b.xyz
Wobei man sich das ständige starten des cp Prozesses für jede Datei
natürlich noch sparen könnte, ich habe es jetzt nur ausgeschrieben,
damit klar ist, was damit gemeint ist.
Ist kein * Parameter angegebenen, dann wird versucht .xyz als
Verzeichnis zu erkennen, schlägt dies fehl, weil es nicht existiert,
liefert es
die übliche Fehlermeldung aus. Es würde sich also bei einer Angabe ohne
* nichts ändern.
Ähnlich gesondert behandeln könnte man noch ?.
Wenn es die Shell nicht auflöst, weil es nicht existiert, ist es umso
besser, weil man das so dann für cp benutzen könnte.
> Wenn die Shell das nun so machen würde, wie du dir wünschst, müsste sie> wissen, dass das *.xyz eine andere Bedeutung hat als das *.txt und> komplett anders behandelt werden muss. Außerdem müsste sie wissen, dass> die beiden in einem bestimmten Zusammnhang zu einander stehen (für jeden> Namen, der zu *.txt der ersten Wildcard gefunden wurde, erzeuge einen> neuen Namen, bei dem das .txt durch .xyz ersetzt wird. Und das soll aber> natürlich nur für cp so sein. Also muss die Shell sehr genau darüber> bescheid wissen, wie cp funktionert und eine Sonderregel extra dafür> umsetzen. Das sind aber getrennte Tools, die eigentlich völlig> unabhängig von einander sind.
Deswegen bringt man das besser cp und mv und was es sonst noch so
Kandidaten gibt.
Die Shell muss das Ziel *.xyz nur unverändert an das aufgerufene
Programm übergeben, wenn es dieses nicht auflösen kann.
Es wäre somit machbar, wenn das, was du zur Shell sagst, diese es also,
nach dem diese festgestellt hat, dass das Verzeichnis nicht existiert,
nicht auflöst und es unverändert an das Programm übergibt, wirklich
zutreffen sollte.
> (prx) A. K. schrieb:>> Inwieweit solche Filetypen bzw Extensions ein Teil des Konzepts von>> Betriebssystemen auf Anwendungsebene sind, in Shells und Explorern, ist>> davon längst völlig unabhängig.>> Wenn eine Datei nicht auf .exe oder .scr oder .bat endet, kann ich sie> nicht ausführen.
Ich nehme mal an, du beziehst dich auf Windows.
Windows kann noch .com und .msi ausführen. :p SCNR
>>> NB: Ende der 60er brachte IBM das Mainframe Betriebssystem CMS, das zu>> den Inspirationsquellen von CP/M zählt. Darin ist die Extension ein>> zweiter Name wie in DOS. Files werden darin durchweg über separate>> Strings identifiziert, wie "FILE" und "C". Aber nicht nur intern,>> sondern auch auf Shell-Ebene (Stand Anfang der 80er).>> Es wäre sinnvoll, ein eigenes Attribut für den Dateityp zu haben. MacOS> macht das auch so. Da sind die Namensendungen nur Deko.> Unter Linux haben viele Tools noch ein etwas ausgeklügelteres Vorgehen,> indem sie zuerst versuchen, die Datei am Inhalt (z.B. einem Header am> Dateianfang) zu erkennen.
Das blinde Vertrauen auf Attribute bzw. Metadaten führt bei Windows
dazu,
dass so etwas wie malwareerleben.txt.exe vom Benutzer ausgeführt wird.
Unter Linux machen es die Tools somit eigentlich schon gut, dass sie
versuchen die Datei vor dem Ausführen oder Laden zu erkennen, ob es sich
überhaupt um eine entsprechende Datei handelt.
Falls es wirklich erforderlich sein sollte, kann man den MIME Dateityp
zudem auch in den Extended File Attributen unterbringen.
Nano schrieb:> Ich nehme mal an, du beziehst dich auf Windows.> Windows kann noch .com und .msi ausführen. :p SCNR
Wenn du nicht im Glashaus mit Steinen schmeissen willst, dann zähle
bitte alle Varianten auf. ;-)
(prx) A. K. schrieb:> Nano schrieb:>> Denn es wäre schon sehr umständlich, wenn man in einem Verzeichnis das>> mit hunderten verschiedenen Dateiformaten belegt ist und die man in ihre>> eigene Unterordner zwecks einer besseren Organisation verschieben>> wollte, mit dem Tool "file" Ordnung schaffen müsste, nur um zu sehen, um>> was für einen Dateityp es sich handelt.>> Mit Extended Attributes ging OS/2 einen etwas anderen Weg. Bei dieser> Idee steht getrennt von der primitiven Fileextension aus der CP/M> Vergangenheit neben allerlei anderem Kram wirklich eine Assoziation zum> Programm drin, das damit umgehen kann. Ob das File "main.c", "main.prx"> oder bloss "main" heisst - egal.
Wirklich eine Assoziation zum Programm oder nur eine Assoziation zum
MIME Type?
Letzteres wäre sinnvoll, ersteres nicht, weil man dutzende Programme auf
dem Rechner haben könnte, die damit umgehen können.
Da wird so eine Liste dann sehr lang und das braucht dann viel Platz.
Sollte dieser für extended Attribute dann limitiert sein, dann wäre das
schlecht.
Steht nur der MIME Type drin, dann wird die Assoziation beim Aufrufen
oder Laden über das OS dann hergestellt, dass dann nachguckt, welches
Programm dafür zuständig ist und welches als default Programm dafür
eingetragen ist.
> Da allerdings - anders als bei "main.c" - der Anwender diese Assoziation> nicht so ohne Weiteres zu sehen bekommt, entsteht ein ähnliches> Sicherheitsproblem wie bei Microsofts Gewohnheit, Extensions im Explorer> nicht anzuzeigen. Man hat keine Ahnung, was man auslöst, wenn man auf> ein File aus unzuverlässiger Quelle draufklickt. Wenn da bloss "main"> steht, und nur in Listendarstellung dahinter der Typ, kanns auch ein> "main.exe" sein. Sehr beliebt als "rechnung.pdf.exe".
Ja, da bin ich deiner Meinung.
Nano schrieb:> Und ab dem Punkt könnte cp wissen, wenn man es ihm beibrächte, dass es> beim Ziel *.xyz, erkennbar durch das glücklicherweise nun nicht> aufgelöste * dieses durch die vorherigen Dateien der Reihe nach> substituieren muss.
Das wäre prinzipiell möglich. Da ist nur ein Problem: Falls es doch
bereits eine oder mehrere Dateien gibt, die diesem Pattern entsprechen,
werden diese dann von der Shell aufgelöst. Dann ist das Verhalten
komplett anders und Dateien werden auf die falsche Weise überschrieben.
Das wäre also extrem gefährlich. Und es wäre eben auch eine ganz andere
Art der Nutzung von Wildcards und damit immer noch ein Sonderfall. Ich
würde da einen Kommandozeilenparameter für cp bevorzugen, mit dem man
eine Namenstransformation entsprechend angeben könnte.
>> (prx) A. K. schrieb:>>> Inwieweit solche Filetypen bzw Extensions ein Teil des Konzepts von>>> Betriebssystemen auf Anwendungsebene sind, in Shells und Explorern, ist>>> davon längst völlig unabhängig.>>>> Wenn eine Datei nicht auf .exe oder .scr oder .bat endet, kann ich sie>> nicht ausführen.>> Ich nehme mal an, du beziehst dich auf Windows.
Klar, darum ging es doch.
> Windows kann noch .com und .msi ausführen. :p SCNR
Ja, stimmt, .msi, aber ich dachte, .com sei mal irgendwann bei Windows 7
oder so abgeschafft worden. Aber mag sein, dass das immer noch geht.
> Das blinde Vertrauen auf Attribute bzw. Metadaten führt bei Windows> dazu, dass so etwas wie malwareerleben.txt.exe vom Benutzer ausgeführt> wird.
Das ist ja eher noch ein Resultat daraus, dass Windows keine echten
Attribute/Metadaten dafür hat, sondern Teile des Namens dafür verwendet,
aber diese dann im bestimmten Situationen vor dem Benutzer versteckt.
Trotzdem kennt jeder die Namens-Endungen. Und deshalb ist dann dann
malwareerleben.txt.exe, wo das .exe vor dem Benutzer verheimlicht wird,
so gefährlich. Es suggeriert dem Benutzer einen anderen Dateityp, als
die Datei wirklich hat.
(prx) A. K. schrieb:> Rolf M. schrieb:>> Wenn eine Datei nicht auf .exe oder .scr oder .bat endet, kann ich sie>> nicht ausführen.>> Versuch macht kluch: Kopiere ein beliebiges .exe File zu main.c und> tippe im CMD main.c ein. Es startet das kopierte Programm. Die GUI mag> sich um sowas scheren, aber sogar dem CMD ist es schnuppe. Dem Win32 API> sowieso.
Hmm, stimmt. Wenn ich es aber nur main nenne, ohne Endung, wird es nicht
mehr gefunden. Ich kann auch keine Dateien erzeugen, deren Name mit
einem Punkt enden. Also ein "copy main main." resultiert in der
Fehlermeldung, dass die Datei nicht auf sich selbst kopiert werden kann.
Rolf M. schrieb:> Ich kann auch keine Dateien erzeugen, deren Name mit> einem Punkt enden.
Du musst es nur auf die richtige Art machen. Bei:
\\?\c:\temp\1.
bleibt der . drin.
Pfade in Windows sind eine Sache für sich, da passiert manches unter der
Haube, und der Präfix \\?\ beeinflusst das.
Rolf M. schrieb:> Wenn ich es aber nur main nenne, ohne Endung, wird es nicht> mehr gefunden.
O Wunder. Willst du jedesmal XCOPY.EXE ausschreiben?
Im Win32 API kann man auch Programme ohne Endung starten. Es ist hier
CMD, das einige üblichen Endungen durchprobiert, wenn keine dasteht.
Rolf M. schrieb:> Nano schrieb:>> Und ab dem Punkt könnte cp wissen, wenn man es ihm beibrächte, dass es>> beim Ziel *.xyz, erkennbar durch das glücklicherweise nun nicht>> aufgelöste * dieses durch die vorherigen Dateien der Reihe nach>> substituieren muss.>> Das wäre prinzipiell möglich. Da ist nur ein Problem: Falls es doch> bereits eine oder mehrere Dateien gibt, die diesem Pattern entsprechen,> werden diese dann von der Shell aufgelöst. Dann ist das Verhalten> komplett anders und Dateien werden auf die falsche Weise überschrieben.> Das wäre also extrem gefährlich.
Das Verhalten wäre dann anders, aber es würden keine Dateien
überschrieben werden, denn die Shell würde aus folgendem:
1
cp *.tx2 *.txt
das *.txt durch die letzte gefundene *.txt Datei substitutieren und cp
würde dann keinen * übergeben bekommen, sondern eine Dateinamen, was
dazu führt, dass cp die klassische Fehlermeldung liefert, da das
angegebene Ziel kein Verzeichnis ist:
1
ls *.tx2 *.txt
2
eins.tx2 zwei.tx2 drei.tx2 yy.txt xx.txt
3
cp *.tx2 *.txt
4
cp: das angegebene Ziel 'xx.txt' ist kein Verzeichnis
Es würden dann schonmal keine Dateien überschrieben werden.
Allerdings könnte man so dann die Dateien natürlich auch nicht kopieren
und umbenennen, sofern nur eine *.txt im Zielverzeichnis vorhanden wäre,
selbst wenn sie einen anderen Namen hätte.
Insofern wäre das inkonsistent ja, das wäre das Problem, aber zumindest
überschrieben werden würde nichts.
> Und es wäre eben auch eine ganz andere> Art der Nutzung von Wildcards und damit immer noch ein Sonderfall. Ich> würde da einen Kommandozeilenparameter für cp bevorzugen, mit dem man> eine Namenstransformation entsprechend angeben könnte.
Ja, so könnte man das natürlich auch lösen.
Und wird man dann wohl auch so lösen müssen.
>> Windows kann noch .com und .msi ausführen. :p SCNR>> Ja, stimmt, .msi, aber ich dachte, .com sei mal irgendwann bei Windows 7> oder so abgeschafft worden. Aber mag sein, dass das immer noch geht.
Das sollte eigentlich immer noch gehen.
Abgeschafft wurde eigentlich nur die Unterstützung von 16 Bit
Anwendungen für die 64 Bit Versionen von Windows Vista und aufwärts.
Und viele historische *.com Dateien sind 16 Bit Anwendungen. *.com
selbst dürfte aber nicht abgeschafft worden sein.
Und wie A.K. richtig anmerkte, gibt es noch weitere. Die ganzen
PowerShell Skripte habe ich bspw. auch noch vergessen.
>> Das blinde Vertrauen auf Attribute bzw. Metadaten führt bei Windows>> dazu, dass so etwas wie malwareerleben.txt.exe vom Benutzer ausgeführt>> wird.>> Das ist ja eher noch ein Resultat daraus, dass Windows keine echten> Attribute/Metadaten dafür hat, sondern Teile des Namens dafür verwendet,> aber diese dann im bestimmten Situationen vor dem Benutzer versteckt.> Trotzdem kennt jeder die Namens-Endungen. Und deshalb ist dann dann> malwareerleben.txt.exe, wo das .exe vor dem Benutzer verheimlicht wird,> so gefährlich. Es suggeriert dem Benutzer einen anderen Dateityp, als> die Datei wirklich hat.
Genau das geht aber auch, wenn der Dateityp nur im Attribut bzw. den
Metadaten stehen würde.
Dann kann die Datei immer noch:
readme.txt
heißen und im Attribut steht dann Executable.
Nano schrieb:> Das Verhalten wäre dann anders, aber es würden keine Dateien> überschrieben werden, denn die Shell würde aus folgendem:> cp *.tx2 *.txt> das *.txt durch die letzte gefundene *.txt Datei substitutieren
…die letzte*n gefundene*n…
Aber stimmt schon. Sofern es nicht gerade ein Verzeichnis gibt, dessen
Name in .txt endet, würde cp dann mit einem Fehler abbrechen.
Allerdings ist noch die Frage, woher cp weiß, was substituiert werden
soll. Ein Konzept von Dateinamenserweiterungen oder eine Sonderbedeutung
des Punktes kennt cp nicht.
> Allerdings könnte man so dann die Dateien natürlich auch nicht kopieren> und umbenennen, sofern nur eine *.txt im Zielverzeichnis vorhanden wäre,> selbst wenn sie einen anderen Namen hätte.> Insofern wäre das inkonsistent ja, das wäre das Problem, aber zumindest> überschrieben werden würde nichts.> Und wie A.K. richtig anmerkte, gibt es noch weitere. Die ganzen> PowerShell Skripte habe ich bspw. auch noch vergessen.
Gibt's eigentlich .pif noch?
Nano schrieb:> *.com gibt's noch
Diese Files heissen allerdings nur aus Kompatibilitätsgründen so und
sind eigentlich EXEs, sonst würde file auch keinen PE-Header finden.
[hat nun nix mit cp vs. copy zu tun, aber mit intuitiver Bedienung von
SWSysteme inkl. CMD.COM ]
Bin grad an diesem Laptop mit W10 auf Arbeit tätig und wollte
nachschauen welcher Key fürs WLAN eingestellt ist.
Habe es alleine auf dem GUI-Weg via Einstellung ... Netzwerk ... WLAN
versucht und nach 15' immer noch nicht gefunden :-/
Also via Suchmaschine "WLAN Passwort Anzeigen" gelandet bei
heise.de/tipps-tricks/Windows-10-WLAN-Passwort-auslesen-3994172.html
(vertrauenswürdig, sollten es wissen)
Bereits beim 2.Bild zeigt sich das W10 sich hier mir anders präsentiert
als auf deren Anleitung: da wo sie den RosaPfeil n.li. zeigend gemalt
haben, ist an meinem Bildchirm der zu clickende Eintrag "Netzwerk und
Freigabecenter" gar nicht da. FULL STOP. kein Weiterkommen. :-(
OK, weiter runter zur Anleitung f. Kommandozeile (ist mir eh lieber)
cmd mit AdminRechte geöffnet (an letzterem ist wohl der o.g. GUI-Weg
gescheitert) und angefangen zu tippen.
In diesem Thread geht es ja auch darum, wenn auch genauer um
Wildcards...
1
c:>netshwlansho[TAB][TAB]
ERNüCHTERUNG!! keine automatische Vervollständigung, also doch schon:
aber nur für Dateinamen welche im Kontext von netsh überhaupt keinen
Sinn machen! :-<
Keines der folgenden Schlüsselwörter geniesst autom.
Vervollständigung...
1
c:>netshwlanshowprofileMY_WLANkey=clear
-------
Unter einem ordentlichen Linux mit bash/dash (vulgo: Desktop-Linux)
bekommt man z.B. bei ip show super Spickunterstützung und muss lange
nie soviele Buchstaben tippen wie der Befehl letztlich umfasst.
NB: auch beim Befehl find (kommt in diesem Thread vor) weiss die Bash
dass als erste(s) Argument(e) NUR VERZEICHNISSE hingehören und
entsprechen bringt die autom. Vervollständigung mit Taste [TAB][TAB]
keine Dateinamen als Vorschlag! :-)
Bitte zurück zur Spur, danke.
Wie laesst sich CMD.COM nun erweitern, dass autom. Vervollständigung
auch bei netsh richtig kommt?
Genau: gar nicht.
Warum dieses Letzte Beispiel? Weil die autom. Vervollständigung der Bash
mit Bash selbst gemcht ist; das ist eine "komplexere Sache" (oben im
Thread als Anwendungfall für Batch-Dateien genannt) welche mit
Batchdateien/CMD.COM eben nicht umsetzbar ist. Tja.
Bitte zutück zu "cp vs. copy" und "wer soll Wildcards auflösen"; eine
"Aufgabenstellung" welche unsere IT-Vorfahren bereits in den 70'er für
uns richtig gelöst haben, bevor (MS-)DOS ff. es zur Mode machte richtige
Lösungen links liegen zu lassen.
Hmmm schrieb:> Nano schrieb:>> *.com gibt's noch>> Diese Files heissen allerdings nur aus Kompatibilitätsgründen so und> sind eigentlich EXEs, sonst würde file auch keinen PE-Header finden.
Ja, das ist richtig.
der Spur abgekommen schrieb:> ERNüCHTERUNG!! keine automatische Vervollständigung, also doch schon:> aber nur für Dateinamen welche im Kontext von netsh überhaupt keinen> Sinn machen! :-<
Nunja, bei der Übergabe von Parametern kann das unter Linux auch nicht
jedes Programm.
Wenn man da bspw. einen Dateipfad angeben und durchtabben will, dann
geht das oft auch nicht. Mit einem Trick kann man das ausführbare
Programm am Anfang durch ls ersetzen, dann geht das Tabben und am Ende
ändert man ls wieder in das ausführbare Programm um.
Nano schrieb:> 2aggressive schrieb:>>> Das schöne an der Linux-Welt und seiner quelloffenen Software ist doch>> daß Du es auch selbst machen könntest, wenn Du nur wolltest.>> Danke
Gerne erwähnt.
>, jetzt weiß ich, dass du dieses Feature noch viel mehr willst und> benötigst als ich.
Da hast du mich missverstanden.
Meine Meinung dazu wurde in vorigen Posts erwähnt, begründet und
erklärt;
cp hat nur eine_ _einzige_ _Aufgabe :=Kopieren
>> WAIT!>> "jemand" hat dieses Problem schon für (auch) dich schon erledigt! Nennt>> sich aber dann nicht mehr "cp (weil ja schliesslich nicht nur kopiert>> wird), sondern "rename" mit all seinen vielen verschiedenen Versionen>> und Derivaten.> Falsch. Rename löscht die Quelle, was bei einem Kopieren ja nicht> gewünscht wäre.
Ach komm, cp und rename bekommt man als Einzeiler hin. Das dein
Gehirnapparat beim mitdenken abgeschaltet hat liegt daran das ich DICH
angetörnt habe. Das wollte ich nicht! Ich bitte um Entschuldigung wenn
das RANT so bei Dir so ankam; einwandfrei mein Fehler dies hier in
deinem Faden zu tun! Es sollte nicht gegen DICH gehen, sondern "nur" ein
allgemeiner Rant sein. War wohl nicht deutlich genug erkennbar :-(
> Du hättest mcp sagen müssen, hast du aber nicht. Und cp wird damit immer> noch nicht zu mcp, was ja dein Wunsch ist.>>> Nano schrieb:>>> Unter meinem Linux ist rename nicht einmal standardmäßig installiert.>> Und irgendein Programm nachzuinstallieren ist dir zu viel Aufwand? Ist>> dir also geschenkt noch zu teuer?
Da hatte ich noch gedacht Du hättest den Sinn hinter der Idee "EIN Tool=
EINE Aufgabe" endlich nachgeturnt. Meine Fehlerkenntnis:= falscher
Faden.
Hast Du nicht, und das steht dir selbstverständlich frei. Wir beide
denken halt beim programmieren grundverschieden.
Deshalb nochmal die Bitte mich zu Entschuldigen; ich hätte meinen Rant
selbstzensierend löschen sollen. Das posten hat in deinem Faden zu
deinem sinnlosen Beissreflex beigetragen.
> Vielleicht wollte man genau das ohne for Schleife mal für ein Skript> nutzen und das Skript an Dritte verteilen. Schonmal daran gedacht?
Ja:
Selbst/sogar ein von Dir als einfachsten Standard (den es in der
Linuxwelt so nicht gibt) angedachtes "cp" macht nicht immer das was Du
erwartest!
Bin mit "cp -a" selbst schon steinige Irrwege gehen müssen, es gibt im
"wilden Westen" Versionen von "cp" welche dabei nur Symlinks anlegen.
SCNR:
Es ist mein Sandkasten! :P
2aggressive schrieb:>> Vielleicht wollte man genau das ohne for Schleife mal für ein Skript>> nutzen und das Skript an Dritte verteilen. Schonmal daran gedacht?
Warum jemand in einem Script nicht so eine einfach Kontrollstruktur
verwenden sollte erschließt sich mir zwar nicht (deswegen schreibt man
doch normalerweise Scripte …), aber das hier:
> Ja:> Selbst/sogar ein von Dir als einfachsten Standard (den es in der> Linuxwelt so nicht gibt) angedachtes "cp" macht nicht immer das was Du> erwartest!
liegt dann eher an den eigenen Erwartungen. POSIX existiert
(https://pubs.opengroup.org/onlinepubs/007904875/utilities/cp.html) und
auf mehr sollte man sich nicht verlassen, ohne die Implementierung für
den konkreten Anwendungsfall zu prüfen. Ja, ich arbeite auch eigentlich
nur mit GNU-Userland, Glashaus, Steine, …
> Bin mit "cp -a" selbst schon steinige Irrwege gehen müssen, es gibt im> "wilden Westen" Versionen von "cp" welche dabei nur Symlinks anlegen.
Ich weiß schon, warum ich für wirklich identische Kopien von Dir-Trees
rsync bevorzuge. Auch das POSIX-konforme zurücksetzen der SUID/SGID-Bits
kann unschöne Auswirkungen haben.
Rolf M. schrieb:> (prx) A. K. schrieb:>> Inwieweit solche Filetypen bzw Extensions ein Teil des Konzepts von>> Betriebssystemen auf Anwendungsebene sind, in Shells und Explorern, ist>> davon längst völlig unabhängig.>> Wenn eine Datei nicht auf .exe oder .scr oder .bat endet, kann ich sie> nicht ausführen.
Ich hab' ja keine Ahnung von Windows, aber IIRC ging früher auch .com.
> Es wäre sinnvoll, ein eigenes Attribut für den Dateityp zu haben. MacOS> macht das auch so. Da sind die Namensendungen nur Deko.> Unter Linux haben viele Tools noch ein etwas ausgeklügelteres Vorgehen,> indem sie zuerst versuchen, die Datei am Inhalt (z.B. einem Header am> Dateianfang) zu erkennen.
Richtig -- und wer erinnert sich nicht ungerne an die alten Zeiten, als
man viele Benutzer von Microsoft-Produkten täuschen konnte, indem man
ihnen Dateianhänge wie "name.pdf .scr" zuschicken konnte, sie
den Trick mit den Leerzeichen nicht gesehen und die Datei dann einfach
stumpf ausgeführt haben... Da hatte und hat die Vorgehensweise unter
UNIXioden mit dem Dateiattribut zur Markierung ausführbarer Dateien
schon eine gewisse Schutzwirkung.
2aggressive schrieb:>>, jetzt weiß ich, dass du dieses Feature noch viel mehr willst und>> benötigst als ich.>Da hast du mich missverstanden.
Das glaube ich nicht. Ich habe da schon richtig getroffen.
> Deshalb nochmal die Bitte mich zu Entschuldigen; ich hätte meinen Rant> selbstzensierend löschen sollen.
So ist es, du hast in der Sache ohnehin nichts beigetragen. Dein Rant
bestand aus einem einzigen Ad Hominem mit dem Wunsch diese Funktion zu
bekommen und so ein Ad Hominem war noch nie nützlich.
Gut das du jetzt einsichtig bist.
Ralf D. schrieb:> 2aggressive schrieb:>>> Vielleicht wollte man genau das ohne for Schleife mal für ein Skript>>> nutzen und das Skript an Dritte verteilen. Schonmal daran gedacht?>
Das habe nicht ich geschrieben, ich hatte nur (nachdem Post) den Versuch
gestartet genau diese Folgeprobleme anzusprechen.
> Warum jemand in einem Script nicht so eine einfach Kontrollstruktur> verwenden sollte erschließt sich mir zwar nicht (deswegen schreibt man> doch normalerweise Scripte …), aber das hier:
Nicht einfach, aber: Ja.
>> Ja:>> Selbst/sogar ein von Dir als einfachsten Standard (den es in der>> Linuxwelt so nicht gibt) angedachtes "cp" macht nicht immer das was Du>> erwartest!>> liegt dann eher an den eigenen Erwartungen. POSIX existiert
Nein, Ja.
Das waren/sind aber nicht meine Erwartungen, Du zietierst nicht mich!
Ausserdem ist Posix eine andere Parallelwelt. Genau das (als Lösung)
treibt die Leute zu Apple. Kann ich nachvollziehen, reicht mir aber
nicht um das Geld bezahlen zu wollen.
> (https://pubs.opengroup.org/onlinepubs/007904875/utilities/cp.html) und> auf mehr sollte man sich nicht verlassen, ohne die Implementierung für> den konkreten Anwendungsfall zu prüfen. Ja, ich arbeite auch eigentlich> nur mit GNU-Userland, Glashaus, Steine, …
Glashaus, Steine, das sollte meiner Meinung nach, unbd noch viel
wichtiger: Nanos (TO) Meinung nach hier kein "Werfen und Treten"
werden.
Ausserdem falsche Baustelle. Selbts die UX-Dokumentation (Linux sogar
extrem) hängt den Schreibern/der Software hinterher.
>>> Bin mit "cp -a" selbst schon steinige Irrwege gehen müssen, es gibt im>> "wilden Westen" Versionen von "cp" welche dabei nur Symlinks anlegen.>> Ich weiß schon, warum ich für wirklich identische Kopien von Dir-Trees> rsync bevorzuge.
Da kann ich nicht "positiv" mitreden, rsync ist sicherlich gut und fein
Programmiert, aber für mich nicht.. Für wirklich "identische Kopien
von Dir-Trees" nutze ich inzwischen nur noch erprobte Versioenen von cp.
"Ein gebranntes Kind scheut das Feuer"; rsync kann dies niemals leisten.
Nano schrieb:> 2aggressive schrieb:>>>, jetzt weiß ich, dass du dieses Feature noch viel mehr willst und>>> benötigst als ich.>>Da hast du mich missverstanden.>> Das glaube ich nicht.
Echt jetzt?
HALLEJUJA! Dann gehe doch zum glauben in eine Kirche deiner wahl.
> Ich habe da schon richtig getroffen.
LOL, wer hat die allererste Version von "rename" geschrieben?
Hint: Geschätzt im Jahre 191 vor Christus, damals mangels Assembler
noch in Opcodes aka Mashinecode. Ein Dateisystem musste ich mir vorher
selber zusammenschreiben.
Im letzteren neige ich zum Übertreiben.
Weiter im Text:
>> Deshalb nochmal die Bitte mich zu Entschuldigen; ich hätte meinen Rant>> selbstzensierend löschen sollen.>> So ist es, du hast in der Sache ohnehin nichts beigetragen.
Ja.
Richtig, war als solches offenbar gekennzeichnet.
> Dein Rant> bestand aus einem einzigen Ad Hominem mit dem Wunsch diese Funktion zu> bekommen und so ein Ad Hominem war noch nie nützlich.
Weder noch hoch_3.
> Gut das du jetzt einsichtig bist.
Sehe ich anders.
michael_ schrieb:> Wir haben das Jahr 2022!> Und unter DOS gab es noch XCOPY.
Naund.
Der Copy-Befehl ist immer noch der schnellste MERGE-Befehl. Besonders
für normale Text-Dateien o. Video.
copy *.vob film.mpg
Und schon schon sind alle VOB's der DVD in einen MPG-Datei. ;)
Falls mal ein Fehler entsteht korrigiert das der Player eh automatisch.
"DOS"-Befehle sind mir heute wichtiger den je. Ich habe kein Bock 50
Dienste dauernd am laufen zu haben. Also werden gewisse Prg. einfach
über eine Batch-Datei gestartet.
Schlaumaier schrieb:> michael_ schrieb:>> Wir haben das Jahr 2022!>> Und unter DOS gab es noch XCOPY.>> Naund.>> Der Copy-Befehl ist immer noch der schnellste MERGE-Befehl. Besonders> für normale Text-Dateien o. Video.>> copy *.vob film.mpg
Da muss man aber noch ein /b dazu schreiben, zumindest unter dem oben
angesprochenen DOS.
> Und schon schon sind alle VOB's der DVD in einen MPG-Datei. ;)
Dafür ist unter Linux cat gedacht (was übrigens für conCATenate steht).
2aggressive schrieb:> Da kann ich nicht "positiv" mitreden, rsync ist sicherlich gut und fein> Programmiert, aber für mich nicht.. Für wirklich "identische Kopien> von Dir-Trees" nutze ich inzwischen nur noch erprobte Versioenen von cp.
Früher nahm man gerne mal ein tar c | tar x dafür. Das -a bei cp für
Archivierung kam auch erst später dazu und ist im übrigen auch nicht
Teil der POSIX-Spezifikation.
2aggressive schrieb:> Ralf D. schrieb:>> 2aggressive schrieb:>>>> Vielleicht wollte man genau das ohne for Schleife mal für ein Skript>>>> nutzen und das Skript an Dritte verteilen. Schonmal daran gedacht?>>> Das habe nicht ich geschrieben, ich hatte nur (nachdem Post) den Versuch> gestartet genau diese Folgeprobleme anzusprechen.
Beim prtiellen Zitat kam der Originalautor nicht als Attribution mit
rüber - war kein Versuch, dir das unterzuschieben, sollte nur den
Kontext herstellen.
>> Warum jemand in einem Script nicht so eine einfach Kontrollstruktur>> verwenden sollte erschließt sich mir zwar nicht (deswegen schreibt man>> doch normalerweise Scripte …), aber das hier:> Nicht einfach, aber: Ja.
Ach komm, eine FOR-Schleife ist ein ziemlich einfache Kontrollstruktur.
>>> Ja:>>> Selbst/sogar ein von Dir als einfachsten Standard (den es in der>>> Linuxwelt so nicht gibt) angedachtes "cp" macht nicht immer das was Du>>> erwartest!>>>> liegt dann eher an den eigenen Erwartungen. POSIX existiert> Nein, Ja.> Das waren/sind aber nicht meine Erwartungen, Du zietierst nicht mich!
Jein. Ich zitiere da deine Aussage, dass es an einer Diskrepanz zwischen
Erwartung und Funktionalität liegt, und da geht es mir darum, dass IMHO
das Problem in der Erwartungshaltung (nämlich mehr als POXI-Standard)
liegt und nicht in der vom Programm bereitgestellten Funktionalität.
> Ausserdem ist Posix eine andere Parallelwelt. Genau das (als Lösung)> treibt die Leute zu Apple. Kann ich nachvollziehen, reicht mir aber> nicht um das Geld bezahlen zu wollen.
Standards definieren eben ein Minimum an Funktionalität. Für bequeme
Nutzung will manmehr. Aber abseits von Standards muss einem eben bewußt
sein, dass diese Features bei jedem System anders aussehen (können).
>> (https://pubs.opengroup.org/onlinepubs/007904875/utilities/cp.html) und>> auf mehr sollte man sich nicht verlassen, ohne die Implementierung für>> den konkreten Anwendungsfall zu prüfen. Ja, ich arbeite auch eigentlich>> nur mit GNU-Userland, Glashaus, Steine, …> Glashaus, Steine, das sollte meiner Meinung nach, unbd noch viel> wichtiger: Nanos (TO) Meinung nach hier kein "Werfen und Treten"> werden.
Ich meinte damit dass ich meine Scripte auch stark auf GNU-Userland
abstelle und nicht auf POSIX. Nicht portabel, aber ich bin mir dessen
wenigstens bewußt (und schreibe deshalb z.B. eben auch ein #!/bin/zsh
oder #!/bin/bash hin statt zu erwarten dass die /bin/sh eine Bash ist).
Ich bin es, der da ein wenig mit Steinen das eigene Glashaus
malträtiert. ;-)
> Ausserdem falsche Baustelle. Selbts die UX-Dokumentation (Linux sogar> extrem) hängt den Schreibern/der Software hinterher.
Mängel in Doku, speziell bei nicht-kommerziellen Projekten, sind noch
ein ganz anderes Problem, ACK. Ich weiß schon, warum ich selbst keine
Doku schreibe – das überlasse ich lieber den Leuten, denen ich die
Bentuzung erkläre, die verstehen besser, was der noch-nicht-einweihte an
Informationen benötigt, um die Software bedienen zu können.
>>> Bin mit "cp -a" selbst schon steinige Irrwege gehen müssen, es gibt im>>> "wilden Westen" Versionen von "cp" welche dabei nur Symlinks anlegen.>>>> Ich weiß schon, warum ich für wirklich identische Kopien von Dir-Trees>> rsync bevorzuge.> Da kann ich nicht "positiv" mitreden, rsync ist sicherlich gut und fein> Programmiert, aber für mich nicht.. Für wirklich "identische Kopien> von Dir-Trees" nutze ich inzwischen nur noch erprobte Versioenen von cp.> "Ein gebranntes Kind scheut das Feuer"; rsync kann dies niemals leisten.
Hüstel. Hatte ich das mit den durch cp absichtlich zurückgesetzten
SUID/GUID-Flags nicht erwähnt? Ein POSIX-konformes cp kann dir nicht
unter allen Umständen eine identische Kopie produzieren. Probier mal
aus, nicht dass dich das irgendwann mal überraschend in den Hintern
beißt, nur weil du bisher derartige Files nicht kopieren musstest.
Rolf M. schrieb:> Da muss man aber noch ein /b dazu schreiben, zumindest unter dem oben> angesprochenen DOS.
Stimmt ;) Habe ich vergessen. sorry
Aber dafür kann man bei COPY auch externe Geräte eingeben.
Einer der ersten Befehle die ich mal in einen Unterricht gelernt habe,
vor sehr sehr langen Zeit war :
copy con: batschi.bat
Dann hat man den Text der Batch-Datei einfach eingetippt. und Mit STRG-C
wurde das ganze abgebrochen.
Benutze ich zwar seit Jahren nicht mehr, aber ich kann ihn wenigstens
noch ;)
Und ich finde es gut das MS die alten DOS-Befehle noch unterstützt und
sogar ein paar neue dazu macht. Wobei mir von den "neuen" der NET Befehl
mein Liebling ist. ROUTE + PING sind aber auch nicht schlecht um
Netzwerkprobleme zu finden.
Schlaumaier schrieb:> Aber dafür kann man bei COPY auch externe Geräte eingeben.
Kann man unter linux auch.
z.B. eine Festplatt mit einem image überschreiben: cp image.img /dev/sdX
Das "copy con: batschi.bat" wäre unter linux "cp /dev/stdin
batschi.bat". Abbrechen kann man mit ctrl+c, für EOF / Eingabeende
sollte man aber ctrl+d nehmen.
Ich nehme für die Sachen zwar lieber dd und cat, manchmal auch mal pv.
Schlaumaier schrieb:> Dann hat man den Text der Batch-Datei einfach eingetippt. und Mit STRG-C> wurde das ganze abgebrochen.
Bist Du sicher, dass das nicht CTRL-Z war, um das Ganze zu beenden?
CTRL-C hätte das zwar auch abgebrochen, aber die Datei nicht
gespeichert, wimre.
Percy N. schrieb:> Bist Du sicher, dass das nicht CTRL-Z war, um das Ganze zu beenden?> CTRL-C hätte das zwar auch abgebrochen, aber die Datei nicht> gespeichert, wimre.
Oh man, mein gedächtnis wird es alt. STRG-C brach ab, STRG-Z schrieb die
Datei.
Bin halt zu viel Total-Commander verwöhnt. Shift-f4 ist mir lieber. ;)
Percy N. schrieb:> Schlaumaier schrieb:>> Dann hat man den Text der Batch-Datei einfach eingetippt. und Mit STRG-C>> wurde das ganze abgebrochen.>> Bist Du sicher, dass das nicht CTRL-Z war, um das Ganze zu beenden?
Ctrl+z ist unter Windows dazu da, ein EOF an die Konsole zu senden.
Unter Linux tut man das mit Ctrl+d.
Rolf M. schrieb:> Ctrl+z ist unter Windows dazu da, ein EOF an die Konsole zu senden.> Unter Linux tut man das mit Ctrl+d.
Na dann ist ja alles klar: Dieser gnadenlose Vorteil wird Linux auf dem
Desktop enorm voranbringen. Ist praktisch unausweichlich, das damit
Windows Nische wird.
Rolf M. schrieb:> Ctrl+z ist unter Windows dazu da, ein EOF an die Konsole zu senden.
Und in der GUI bedeutet es UNDO. Kein Wunder, dass sich niemand die
Kürzel merken mag.
Percy N. schrieb:> Und in der GUI bedeutet es UNDO. Kein Wunder, dass sich niemand die> Kürzel merken mag.
Och, da sich unter Windows doch sehr viele GUI-Anwendungen an die
Konventionen halten (as far applicable), merkt man sich einige Shortcuts
schon.
Unter Linux sorgt allein der Wildwuchs der GUIs hingegen dafür, dass
kein Mensch sich was merken kann. Weil: auf dem nächsten System gilt das
alles nicht mehr.
Blödsinn. Ctrl-C/X/V/Z/Y/P tun genau das gleiche, wie unter windows.
Redo (Ctrl-Y) funktioniert sogar noch konsistenter, als unter Windows.
Dort geht manchmal nur Ctrl+Shift+Z, manchmal was komplett anderes. Und
wehe man will in Win mal in O356 etwas aus dem e-mail adresse / contakt
popover Fenster kopieren, da ist das dann plötzlich Ctrl+p statt c oder
so...
c-hater schrieb:> DPA schrieb:>>> Blödsinn. Ctrl-C/X/V/Z/Y/P tun genau das gleiche, wie unter windows.>> Immer? Nö, das ganz sicher nicht.
Das Gute bei Windows ist, man muss sich im Grunde genommen nur ACDC
merken.
c-hater schrieb:> DPA schrieb:>>> Blödsinn. Ctrl-C/X/V/Z/Y/P tun genau das gleiche, wie unter windows.>> Immer? Nö, das ganz sicher nicht.
Abgesehen von terminals und emacs (was ja auch ein halbes tui ist) doch.
Mir ist keine GUI Anwendung bekannt, die copy,cut,paste,undo,redo,print
mit anderen Tastenkombinationen handhaben würde.
c-hater schrieb:> Och, da sich unter Windows doch sehr viele GUI-Anwendungen an die> Konventionen halten (as far applicable), merkt man sich einige Shortcuts> schon.
Das hilft aber nichts, wenn man an die alten ASCII-Steuerzeichen gewöhnt
ist, die in der Mikro-Welt mindestens von CP/M bis zu allen DOSen
konsistent verwendet wurden, nur weil BillyBoy plötzlich auf die Idee
gekommen ist, es sei zweckmäßig, seinen eigenen, völlig inkompatiblen
Hausstandard zu definieren und den arglosen Benutzer damit zu überfallen
- wobei dann in der Win-Shell, aka Eingabeaufforderung, zumindest
teilweise wieder die guten alten ASCII-Ctls galten, so ist zB die
Nummer "copy con: muell.txt" text ctl-z auch unter Win 10 noch
möglich, ctl-c bedeutet immer noch CAN ...
Ralf D. schrieb:> Hüstel. Hatte ... ...SUID/GUID-Flags... ...Probier mal> aus, nicht dass dich das irgendwann mal überraschend in den Hintern> beißt, nur weil du bisher derartige Files nicht kopieren musstest.
Danke für den warnenden Hinweis, der gehört hier sicherlich auch mit
rein, auch wenn ein altes DOS/FAT noch keine Rechteverwaltung kannte.
Ontop: ein kritisches Auge beim gegentesten der erstellten Backups
erpart unangenehme Überraschungen. Ein nicht getestetes
Backup(-verfahren) ist im Ernstfall ansonsten ein nicht brauchbares
Backup/Archiv.
Da war doch mal was? AFAIR: uraltes DOS hat per default sogar einen
verify, also einen gegenlesenden Vergleich der geschriebenen Daten
durchgeführt. Das hat zwar Zeit gekostet, entlarvte aber kaputte
Disketten (+dreckige Magnetköpfe); damit sind wir eigentlich wieder voll
ontopic.
Donnerblitz schrieb:> Daher ist das ein gutes Beispiel von vielen anderen, weshalb Linux auf> dem Consumer Markt kein Bein auf den Boden bekommt im Desktop Bereich.
Open Source Politik bedeutet eben keine Bevormundung. oder Kosten
Oder gar kein Kommerz oder gar Antikommerz wie hier:
https://www.computerbase.de/2020-11/tromjaro-linux-manjaro-derivat/Donnerblitz schrieb:> Jepp, und das ist wieder so ein gutes Beispiel, das zeigt das zu viel> Vielfallt mehr schadet als nutzt.
Unsinn, es gibt viele ältere stabile Distros wie Kanotix die gepflegt
werden und um die is es nur leise, weil sie problemlos laufen.
> Nur Nerds können mehr als 2 oder 3 Distributionen aus dem Kopf aufsagen
Sagt ein O816-Winufant. Nimm Deine Pillen und gute Besserung!
Im Geschäft gibts bald einen neuen Laptop (haben leider alle Windows).
Also kopiere ich jetzt erst mal alle Daten weg, auf eine lokal
angeschlossene USB-3 Festplatte, die mit NTFS formatiert ist.
Ich mache das faul über die GUI. Erster versuch, hat erstmal ewig lang
die Files gezählt & nichts kopiert. Und irgendwann war das Fenster
plötzlich einfach so weg. Einfach abgeschmiert.
Also nur mal die Dokumente statt den gesamten Benutzerordner kopiert.
Klar, da sind viele kleine Dateien drinn, aber <10 KB/s, ja KILOBYTE pro
Sekunde, ernsthaft? Klar, das sind HDD, aber nur damit lassen sich
derart scheiss geschwindigkeiten nicht erklären. WTF!
🐧 DPA 🐧 schrieb:> Erster versuch, hat erstmal ewig lang> die Files gezählt & nichts kopiert. Und irgendwann war das Fenster> plötzlich einfach so weg. Einfach abgeschmiert.
Früher war das so, da hatte man vorher defragmentiert. Das konnte auch
Ewigkeiten dauern.
Besonders lange brauchte z.B. cygwin, 4gb, 2-3 Stunden.
Schlaumaier schrieb:> Aber dafür kann man bei COPY auch externe Geräte eingeben.>> Einer der ersten Befehle die ich mal in einen Unterricht gelernt habe,> vor sehr sehr langen Zeit war :>> copy con: batschi.bat
Ich fand
1
copy myfile.txt prn
ganz praktisch, um etwas auszudrucken. Ich hab auch später mal unter
Windows mit dem Editor eine Datei als prn abgespeichert, um sie zu
drucken (weil grad kein Druckertreiber installiert war), und das ging
auch. Als ich das später nochmal versucht habe, ging es nicht mehr, weil
Windows es verweigerte, da prn ein reservierter Name sei. Das war etwas
nervig, denn genau deshalb hatte ich den Namen ja gewählt…
Rolf M. schrieb:> Als ich das später nochmal versucht habe, ging es nicht mehr, weil> Windows es verweigerte, da prn ein reservierter Name sei.
Was ich noch ziemlich idiotisch finde, per UNC Pfad kann man Dateien mit
solchen Namen anlegen. Aber will man im Explorer die Datei oder den
Ordner in dem sie ist, kopieren, verschieben oder löschen, bringt der
Explorer das nicht auf die reihe. Auf die UNC Version des Pfads kann man
im Explorer auch nicht wechseln. Dass der Datei Manager von Windows
nicht einmal mit gültigen, unter Windows angelegten Dateien klar kommt,
finde ich also schon sehr schwach.
🐧 DPA 🐧 schrieb:> Was ich noch ziemlich idiotisch finde, per UNC Pfad kann man Dateien mit> solchen Namen anlegen.
Per \\?\... geht es, aber damit wird Windows mitgeteilt, dass es den
Pfad nehmen soll, wie er ist, und keine Normalisierung vornehmen soll.
Das ist eine Altlast, die bis zu CP/M zurückreicht.
http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch1.htm#Section_1.6.4
Ja, schon klar. Aber man sollte doch meinen, die Explorer Entwickler
sollten auch langsam mal mitbekommen haben, dass auf die Dateien über
\\?\... zugegriffen werden muss.
🐧 DPA 🐧 schrieb:> Ja, schon klar. Aber man sollte doch meinen, die Explorer Entwickler> sollten auch langsam mal mitbekommen haben, dass auf die Dateien über> \\?\... zugegriffen werden muss.
Damit er sich anders verhält als der Filesystem-API und die Leute erst
recht verwirrt??? Nope, API, CMD und GUI sollten sich schon
einigermassen gleich verhalten.
(prx) A. K. schrieb:> 🐧 DPA 🐧 schrieb:>> Ja, schon klar. Aber man sollte doch meinen, die Explorer Entwickler>> sollten auch langsam mal mitbekommen haben, dass auf die Dateien über>> \\?\... zugegriffen werden muss.>> Damit er sich anders verhält als der Filesystem-API und die Leute erst> recht verwirrt??? Nope, API, CMD und GUI sollten sich schon> einigermassen gleich verhalten.
Wenn man im Explorer im Pfad oben \\?\ davor setzt, nimmt er das bereits
einfach wieder raus.
Und ich glaube kaum, dass jemand, der einen Ordner zu kopieren versucht,
stattdessen von und nach Druckern, COM Ports, und was es sonst noch so
gibt, zu lesen & schreiben versucht. Aus UI sicht sieht man eine Datei,
die versucht man zu kopieren. Und da soll es jetzt weniger verwirrend
sein, wenn plötzlich ne Meldung kommt, ne 1KB nul.txt sei zu gross fürs
Dateisystem?
Umgekehrt: Könntest Du per GUI ein File prn.txt erzeugen, aber
anschliessend nicht im Programm verwenden, wäre die Verwirrung gross.
Man müsste diese Altlasten schon überall rauswerfen. Aber damit
schlachtet man die heilige Kuh "Kompatibilität" und ganz sicher gibts
irgendwo Leute, die dann wie ein Rohrspatz schimpfen.
Es gibt eben ein gewisses "Grundwissen Windows".
Es kann aber nun mal solche Dateien geben. Der Explorer verbietet es
bereits, neue Dateien mit dem Namen anzulegen.
Aber bei bestehenden Dateien, wenn ich mit der über das GUI irgend was
machen will, ist ja wohl unmissverständlich, dass ich die Datei kopieren
verschieben umbenennen / öffnen, etc. will, und nicht z.B. den COM
Port. Denn was da in dem Ordner liegt ist ja nicht der COM Port, sondern
eine Datei namens COM. die spezielle COM Datei kann nie in einem
Directory Listing auftauchen, aber eine Datei COM schon. Aus UI Sicht
gibt es keine Ambiguität, und keine Rückwärtskompatiblitätsprobleme. Das
ist ja ein UI, und keine manuelle Eingabe eines Pfades oder Dateinamens,
wo man das eventuell absichtlich gemacht haben könnte (Der Fall wurde ja
im UI bereits von MS verboten).
Wobei, man könnte auch argumentieren, der Fehler ist, dass die Datei
überhaupt aufgelistet wird. Wenn wir wirklich Konsistenz wollten, und
unter nicht-\\? Pfaden COM usw. sich nicht auf eine normale so benannte
Datei beziehen kann, dann darf mir eine solche, die ja dort gar nicht
existiert, sondern nur unter \\? liegt, auch nicht angezeigt werden.
So oder so, die momentane Umsetzung ist unlogisch, ich würde sogar
soweit gehen zu sagen, falsch.
Thread beobachten
Seitenaufteilung abschalten