Zwei Fragen zu Kommandozeile - 80 Spalten Beschränkung, Copy Ersatz

(DE) System, Installation, Konfiguration, Hardware, Treiber, Netzwerk, Virtualisierung, etc.
(EN) System, Installation, Configuration, Hardware, Drivers, Network, Virtualisation, etc.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Zwei Fragen zu Kommandozeile - 80 Spalten Beschränkung, Copy Ersatz

Beitrag von Martin Vieregg »

Gibt es eine Möglichkeit, die 80 Spalten Beschränkung der Kommandozeile, die auch bei 4os2 noch gültig ist, aufzuheben?

Ich suche nach einem Ersatz für den copy oder xcopy Befehl mit einer Fortschrittsanzeige. Ist jemandem ein Tool bekannt?
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Mehr als 81 Spalten sind möglich wenn weniger als 100 Zeilen angezeigt werden sollen. Es ist keine Spaltenbegrenzung, sondern eine Speichergrenze erreicht bei mode 81,100. Was ja gerade noch kleiner als 8k sind ;). Z.B. mode 150,50 geht sicherlich auch.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Das Ganze ist von mehreren Faktoren abhängig. Die konstante Puffergrößenbeschränkung von 8192 Zeichen wurde bereits erwähnt. Zusätzlich muß auch noch der verwendete Treiber für den Bildschirmadapter mitspielen. In diesem Zusammenhang hat auch noch die gewählte Schriftgröße einen nicht unerheblichen Einfluß. Unter dem PM sind daher 51 Zeilen bei 160 Spalten oder 50 Zeilen bei 162 Spalten noch sinnvoll praktisch zu verwenden, was für die Aufteilung von 4 Sitzungen in einem Fenster noch genügen sollte.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Martin Vieregg hat geschrieben: Fr 22. Jun 2018, 11:37 Ich suche nach einem Ersatz für den copy oder xcopy Befehl mit einer Fortschrittsanzeige. Ist jemandem ein Tool bekannt?
Bei einem Verzeichnisbaum mit vielen kleinen Dateien würde ich die klassische Variante bevorzugen:

Code: Alles auswählen

dir /bf <Quelle> | cpio -pdm <Ziel>
Für erweiterte Attribute kann man natürlich noch eautil dazwischen klemmen oder jedes herkömmliche Archivierungsprogramm mit entsprechender Unterstützung verwenden.

Soll die Fortschrittsanzeige auf der Konsole erfolgen (z.B. Pipe Viewer) oder grafisch?
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Wenn man eine große Datei auf ein langsames Speichermedium spielt, dann hat man keine Ahnung, wie lange es noch dauert, weil sich dann einfach gar nichts rührt, sowohl bei copy als auch bei xcopy.

Hat niemand die Kommandozeile neu geschrieben? Das wäre ein PM-Programm, das Programme mit stdio ausführt.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Take Command ist so etwas für 4OS2.

Für viele Zwecke sind das zwar brauchbare Lösungen. Nur mit der Kompatibilität gibt's immer wieder Probleme. Bei einer PM-Version braucht man an Kompatibilität gar nicht zu denken. Deshalb lässt sich CMD leider nicht systemweit ersetzen.

Annähernd kompatibel kann ein PM-Programm nur sein, wenn die VIO-Funktionen unterstützt werden würden. Dafür fehlt die Bibliothek.
Andreas Schnellbacher
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Mein ME Editor zeigt stdout aus der Kommandozeile an:

Code: Alles auswählen

dir /s | me in
Theoretisch könnte man das Ausführen von Programmen einbauen, wobei cmd.exe im Hintergrund gestartet würde (für jeden Befehl wieder neu). Aber richtig toll wäre das nicht, weil man dann einen cmd-Befehl nicht unterbrechen könnte. Ich glaube nicht, dass man eine Kommunikation vom me nach cmd herstellen könnte. Nur Abschießen des Prozesses wäre denkbar sowie die vorübergehende Unterbrechung des stdout Stroms.

Das TakeCommand habe ich mir angesehen, das ist gar nicht schlecht. Leider wird es nicht mehr supportet. Wenn man ganz oft Return drückt, stürzt es ab. Den Autor gibt es noch http://jpsoft.com, der schreibt sein Programm aber nur noch für Windows.
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Den Autor gibt es noch http://jpsoft.com, der schreibt sein Programm aber nur noch für Windows.
Und die geben den Quellcode für die OS/2 TakeCommander Erweiterung nicht her. Zumindest hat meine Anfrage nichts gebracht. In den 4os2 sourcen finden sich Hinweise auf das PM Frontend. Der code dazu fehlt aber.

Ich hab auch schon mal angefangen einen PM Überbau zu bauen mit stdin/stdout duplizieren. Irgendwann hatte ich aber keine Zeit mehr dafür. Auch weil es die 100% Kompatibilität mit einem PM Programm nicht geben kann. Und selbst 4os2 wird ja oft wegen Kompatibilitätsproblemen abgelehnt, obwohl dass ja nun doch schon ganz ganz nah an cmd.exe ist. Auch ist ein PM edit window mit variabler Größe, Font support, color coding, copy/paste nicht so schnell programmiert. Die slickedit sourcen wären da toll.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

>Auch ist ein PM edit window mit variabler Größe, Font support, color coding, copy/paste nicht so schnell programmiert.

Wie gesagt ich bin ja der Autor des ME Editors, der hat das alles ja schon. Ich könnte das Absenden von cmd-Befehlen schon einbauen, das wäre gar nicht so schwierig. Es ist nur die Frage, ob das im Alltag wirklich nützlich wäre. ME ist objektorientiert, ich könnte einen Objekt-Nachfolger als Kommandozeilenersatz programmieren. Allerdings habe ich aktuell kaum Zeit für so etwas. Was meint ihr, würde sich so etwas lohnen? Es wäre auch die Frage, ob man es mehr als Editor mit eingebauter Kommandozeile oder als Kommandozeilenersatz ansieht, es also bzgl. look-and-feel mehr ein Editor oder ein Kommandozeilenfenster sein soll.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Martin Vieregg hat geschrieben: Mi 27. Jun 2018, 22:33 Was meint ihr, würde sich so etwas lohnen?
Wenn man ME nutzt, dann eventuell.

Ich nutze NEPMD und hab damit die EPM-Shell als voreingestelltes Command-Prompt-Objekt für die XWP-Kontextmenü-Erweiterung eingestellt. Brauchbar wurde das erst, nachdem ich die ANSI-Sequenzen aus der CMD-Ausgabe ausgefiltert hatte. Besonders das Highlighting macht sich gut, neben allen Editor-Vorteilen natürlich. Commandline Completion hab ich auch eingebaut. Eine Befehlshistorie gibt's auch.

Bei vielen Sachen ist das nicht ausreichend kompatibel, so dass ich immer darauf eingestellt bin, einen Befehl in einem CMD-Fenster zu wiederholen. Dieses Programmobjekt hat übrigens die Parameter: /k "mode co80,70 & cls & "%*"" Häufig warten Programme nach einer Ausgabe auf eine zusätzliche Eingabe. Da kann man dann blind tippen oder es geht gar nicht weiter. Aber SVN mach ich vollständig mit EPM, nachdem ich statt tedit den EPM als Editor eingetragen hab: In %HOME%\.subversion\config: editor-cmd = epm /m

Noch ein Nachteil mit EPM: Wenn man von der umgeleiteten CMD-Befehlszeile aus ein Programm aufruft, das selbst einen Prompt hat (z.B. 4os2, bash oder rexxtry), dann wird mit dem Schließen des EPM-Fensters nur eine Ebene geschlossen. Das verwaiste CMD.EXE hängt dann mit 100 % CPU-Last.

Take Command fand ich damals, als ich das getestet hatte, übrigens um einiges kompatibler als die EPM-Shell.
Zuletzt geändert von aschn am Do 28. Jun 2018, 18:58, insgesamt 2-mal geändert.
Andreas Schnellbacher
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Ich habe mich nun dem Thema Kopieren angenommen und die mir fehlenden Funktionen in mein DO Kommandozeilenprogramm eingebaut:

DO für OS/2 Archivdatei
DO für Windows (32 bit) Archivdatei

DO.EXE ist ein Sammelsurium-Programm fehlender Kommandozeilenbefehle bzw. ersetzt Kommandozeilenbefehle, die unter OS/2 nicht richtig funktionieren oder funktionierten (z. B. 4 GB Dateigrenze). Seit der zuletzt veröffentlichten Version 1.46 habe ich immer wieder etwas dazuprogrammiert. Neu ist nun

- DO SHOWCLONE, KILLCLONE: das Auffinden und Löschen von Clone Dateien
- DO EVERY: zeitbedingtes Ausführen von Batchdateien, z. B. alle 3 Tage
- DO RENAME

und eben

- DO COPY
in verschiedenen Varianten. DO COPY zeigt die kopierten Dateien an, DO PCOPY zeigt nur einen Fortschrittsbalken.
Es arbeitet mit großen Speicherblöcken, ist deshalb relativ schnell. Außerdem sammelt es einmal alle Dateien und ist dann deutlich schneller als XCOPY, vor allem bei mehrfacher Ausführung von XCOPY (copy *.txt /s, xcopy *.doc /s usw.)

Ich habe gegoogelt und keine Möglichkeit gefunden, Dateien größer 4GB auf FAT32-Partitionen zu spielen. Das geht jetzt auch ganz einfach. Dazu werden die Dateien in kleinere Einzeldateien zerlegt und können dann mit einem Befehl für alle Unterverzeichnisse dann wieder zusammengesetzt werden.

Die aktuelle Version 1.99 ist als Beta-Version zu verstehen. Bitte Fehler unbedingt melden. Danke.

Mit DO kann man mit kurzen Befehlen viel Schaden anrichten. Wie in der Doku geschrieben, bitte vorher mit
DO LIST
oder
DO DCOPY (dummy-copy)
die Dateienauswahl erst einmal testen.

Bei DO werden standardmäßig die Unterverzeichnisse mit bearbeitet. Zum Ausschließen muss man extra einen Punkt vor die Befehle setzen.
Die Syntax weicht deutlich von xcopy oder dir ab, also Doku bitte genau lesen. (Die ist nur englisch, ist das ein Problem?)
ehemaliger
Beiträge: 102
Registriert: Mi 22. Nov 2017, 23:46

Beitrag von ehemaliger »

Martin Vieregg hat geschrieben: Sa 25. Aug 2018, 00:20Ich habe gegoogelt und keine Möglichkeit gefunden, Dateien größer 4GB auf FAT32-Partitionen zu spielen.
Natürlich nicht. Denn diese Grenze ist durch die Struktur des Dateisystems vorgegeben. Ich weiß nicht wie das heutzutage ist, aber früher nutzte die OS/2-Implementierung von FAT32 das 16bit IFS-API, wodurch sich eine Begrenzung der maximalen Dateigröße auf 2GB ergibt. Durch einen Bug war es jedoch möglich, größere Dateien zu erzeugen. Die bereiteten u.U. Ärger, da bestimmte Operationen (DosQueryFileInfo/DosSetFilePtr/DosSetFileSize) dann unvermittelt fehlschlugen oder falsche Ergebnisse lieferten.
Zuletzt geändert von ehemaliger am Sa 25. Aug 2018, 08:01, insgesamt 1-mal geändert.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

natürlich nicht. Denn diese Grenze ist durch die Struktur des Dateisystems vorgegeben
das weiß ich natürlich auch. Ich meine natürlich ein Tool, das größere Dateien in kleinere zerlegt, man dann die kleineren auf einen USB-Stick spielen kann und dann am Zielsystem, das dann nicht mit FAT32 formatiert, ist, wieder zusammenbaut. Genau das macht das DO Tool.
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Dateien in kleiner 2GB Häppchen zerlegen mache ich immer mit rar. Wahrscheinlich deshalb, weil ich vor ca. 15-20 Jahren keine bessere Möglichkeit gefunden habe. Und das Zerlegen und Zusammenfügen geht unter jedem mir wichtigen OS.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Ich habe mein DO Kommandozeilenprogramm nun auch für Linux und MacOS fertig:

DO für OS/2 Archivdatei
DO für Windows (32 bit) Archivdatei
DO für Linux 64 bit Archivdatei
DO für MacOS X Archivdatei

Die anderen Archive haben sich nicht geändert. Wer am ersten Tag des Hochladens das Programm schon runtergeladen hat und sich das Programm beim Eingeben von DO mit "DO 1.99" ohne "a" dahinter meldet, bitte aktualisieren.

Ich plane bei der 2.00 Version dann das Programm in "DOO" umzubenennen, weil bei Unix der Befehl "DO" schon belegt ist.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Inzwischen hat mich ein Natives speaker aufgeklärt, dass "doo" nicht passend ist...
Ich freue mich über Namensvorschläge.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Nenn es doch "DU" (Do Utility). Damit sollte auch die Beziehung zum ehemaligen "DO" herstellbar sein.
Andreas Schnellbacher
Benutzeravatar
efbe
Beiträge: 69
Registriert: Do 11. Sep 2014, 19:33
Wohnort: Dortmund

Beitrag von efbe »

aschn hat geschrieben: Mo 8. Okt 2018, 22:27 Nenn es doch "DU" (Do Utility). Damit sollte auch die Beziehung zum ehemaligen "DO" herstellbar sein.
Gleicher Konflikt, da du (disk utility) standardmäßig unter linux installiert ist.
CU/2
Frank
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Martin Vieregg hat geschrieben: Mo 8. Okt 2018, 21:35 Inzwischen hat mich ein Natives speaker aufgeklärt, dass "doo" nicht passend ist...
Ich freue mich über Namensvorschläge.
"doe" sollte weniger fäkal assoziiert werden.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Dann würde auch noch DOU passsen. Was DOE bedeuten soll, ist mir unklar.
Andreas Schnellbacher
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

es soll englisch sein. Klingt ein bißchen nach "manchmal" .... und so schlecht ist es jetzt auch nicht programmiert.
Zuletzt geändert von Martin Vieregg am Fr 9. Nov 2018, 08:37, insgesamt 1-mal geändert.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Einen wirklich guten neuen Namen habe ich, auch im englischen Forum, nicht erhalten.

Es gibt den Konflikt ja nur bei Unix. Also könnte man es einfach groß schreiben.
dargndorp
Beiträge: 20
Registriert: Mo 6. Jan 2014, 12:00

Beitrag von dargndorp »

Wie wär's mit dew'? Also Englisch für Morgentau. Ist kurz, die Aussprache bleibt gleich wie englisch 'do', zudem ist das Wort ist ein kleines bißchen evokativ.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Ich bin jetzt bei DO geblieben. Unter Linux/Mac wird DO groß geschrieben.

Ich habe in den letzten Monaten noch viel Feinschliff gemacht. Neu ist neben der schon erwähnten Copy-Funktion (mit Fortschrittsbalken und Splitt-Funktion bei FAT32-Laufwerken bei großen Dateien) noch ein sortieres Listen von Dateien über Unterverzeichnisse hinweg (alphabetisch, Datum, Dateigröße). Es gab bei Spezialfällen auch noch Abstürze, die sollten jetzt behoben sein.

http://www.hypermake.de/deutsch/do.html
Antworten