Forum: PC Hard- und Software Was copy von DOS besser kann als cp von Linux


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Nano (Gast)


Lesenswert?

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.

von michael_ (Gast)


Lesenswert?

Wir haben das Jahr 2022!
Und unter DOS gab es noch XCOPY.

von Nano (Gast)


Lesenswert?

Korrektur:

Das
1
mk b

bei dem DOS Befehel muss natürlich
1
md b
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

von Hmmm (Gast)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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?

von Hmmm (Gast)


Lesenswert?

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

von Hermann K. (r2d2)


Lesenswert?

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?

von Nano (Gast)


Lesenswert?

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.

von DPA (Gast)


Lesenswert?


von Nano (Gast)


Lesenswert?

Nano schrieb:
> Danke für deine Erklärung.

Das bezog sich auf das Posting von  Hmmm (Gast)

Danke auch an Hermann K..

von Nano (Gast)


Lesenswert?

DPA schrieb:
> Geht doch:
> https://www.man7.org/linux/man-pages/man1/rename.1.html

Unter meinem Linux ist rename nicht einmal standardmäßig installiert.
Mit mv habe ich es getestet, das ist überall dabei und damit geht es 
jedenfalls nicht.

von Hmmm (Gast)


Lesenswert?

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

von DPA (Gast)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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.

von Hmmm (Gast)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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:
1
find ./ -name "*.txt" -exec grep -i 'suchbegriff' /dev/null {} \;

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.

von Jan (Gast)


Lesenswert?

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.

von Michi (Gast)


Lesenswert?

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.

von Donnerblitz (Gast)


Lesenswert?

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

von Donnerblitz (Gast)


Lesenswert?

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

von Donnerblitz (Gast)


Lesenswert?

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

von foobar (Gast)


Lesenswert?

> copy *.tx2 ..\b\*.txt

Dafür gibt es mmv/mcp/mln/mad:
  mcp "*.tx2" "../b/#1.txt"

von Jack V. (jackv)


Lesenswert?

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.

: Bearbeitet durch User
von Donnerblitz (Gast)


Lesenswert?

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.

von Donnerblitz (Gast)


Lesenswert?

"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

von Rolf M. (rmagnus)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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!

von (prx) A. K. (prx)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Norbert (Gast)


Lesenswert?

(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]?

von 2aggressive (Gast)


Lesenswert?

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

von diesem "uns" findet sich keine Wohnadresse (Gast)


Lesenswert?

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

von Nano (Gast)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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.

von Norbert (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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

: Bearbeitet durch User
von Nano (Gast)


Lesenswert?

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.

von Norbert (Gast)


Lesenswert?

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!

von Nano (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

Nano schrieb:
> Also einfach mal mitdenken wie er es gemeint hat und sich dann in seine
> Sichtweise einverstandenen,

Sorry, ich meinte natürlich hineinversetzen.

von (prx) A. K. (prx)


Lesenswert?

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

: Bearbeitet durch User
von Nano (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

: Bearbeitet durch User
von Jens B. (dasjens)


Lesenswert?

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.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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?

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Donnerblitz (Gast)


Lesenswert?

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ß

von Nano (Gast)


Lesenswert?

Rolf M. schrieb:
> Wenn du jetzt schreiben würdest:
>
1
> cp *.txt *.xyz
2
>
> Dann würde die Shell daraus erstmal machen:
>
1
> cp a.txt b.txt *.xyz
2
>
> 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.

von (prx) A. K. (prx)


Lesenswert?

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

von Nano (Gast)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Nano (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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?

von Nano (Gast)


Lesenswert?

Wegen *.com habe ich jetzt gerade mal in meiner Windows 10 Installation 
nachgeschaut.
*.com gibt's noch:

Beispiel:
1
$ find -iname *.com
2
....
3
./Windows/SysWOW64/mode.com
4
./Windows/SysWOW64/more.com
5
./Windows/SysWOW64/tree.com
6
./Windows/SysWOW64/chcp.com
7
./Windows/SysWOW64/format.com
8
....
9
$ file Windows/SysWOW64/tree.com 
10
Windows/SysWOW64/tree.com: PE32 executable (console) Intel 80386, for MS Windows

Bei *.pif wurde leider nichts entsprechendes gefunden:
1
$ find -iname *.pif
2
$

von Hmmm (Gast)


Lesenswert?

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.

von der Spur abgekommen (Gast)


Lesenswert?

[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:> netsh wlan sho[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:> netsh wlan show profile MY_WLAN key=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.

von Nano (Gast)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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.

von 2aggressive (Gast)


Lesenswert?

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

von Ralf D. (doeblitz)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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.

von 2aggressive (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

: Bearbeitet durch User
von Ralf D. (doeblitz)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

Rolf M. schrieb:
> Früher nahm man gerne mal ein tar c | tar x dafür.

Oder find . | cpio -p...

von Schlaumaier (Gast)


Lesenswert?

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.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von Percy N. (vox_bovi)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von Percy N. (vox_bovi)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von DPA (Gast)


Lesenswert?

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

von DPA (Gast)


Lesenswert?

(btw, ich meine den popover dialog in outlook 365: 
https://www.nickshertzer.com/wp-content/uploads/2019/02/Outlook-Email.jpg)

von c-hater (Gast)


Lesenswert?

DPA schrieb:

> Blödsinn. Ctrl-C/X/V/Z/Y/P tun genau das gleiche, wie unter windows.

Immer? Nö, das ganz sicher nicht.

von Norbert (Gast)


Lesenswert?

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.

von DPA (Gast)


Lesenswert?

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.

von Percy N. (vox_bovi)


Lesenswert?

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

von 2aggressive (Gast)


Lesenswert?

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.

von Linuxarzt (Gast)


Lesenswert?

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!

von Linuxarzt (Gast)


Lesenswert?

Jens B. schrieb:
> Ernsthaft? Ist das getrolle oder echte Blödheit?

Die Defizite des DAU sind leider echt ;)

von 🐧 DPA 🐧 (Gast)


Angehängte Dateien:

Lesenswert?

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!

von rbx (Gast)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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…

von 🐧 DPA 🐧 (Gast)


Angehängte Dateien:

Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

🐧 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

: Bearbeitet durch User
von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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

: Bearbeitet durch User
von 🐧 DPA 🐧 (Gast)


Lesenswert?

(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?

von (prx) A. K. (prx)


Lesenswert?

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

: Bearbeitet durch User
von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.