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
Posts: 191
Joined: Tue 19. Aug 2014, 09:30

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

Post by Martin Vieregg » Fri 22. Jun 2018, 11:37

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.
Posts: 418
Joined: Tue 24. Dec 2013, 16:40

Post by Andi B. » Fri 22. Jun 2018, 11:42

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.

User avatar
ak120
Posts: 906
Joined: Thu 8. May 2014, 12:50
Location: Demmin

Post by ak120 » Fri 22. Jun 2018, 12:28

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.

User avatar
ak120
Posts: 906
Joined: Thu 8. May 2014, 12:50
Location: Demmin

Post by ak120 » Fri 22. Jun 2018, 13:14

Martin Vieregg wrote:
Fri 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: Select all

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
Posts: 191
Joined: Tue 19. Aug 2014, 09:30

Post by Martin Vieregg » Mon 25. Jun 2018, 11:47

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.

aschn
Posts: 692
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Mon 25. Jun 2018, 12:04

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
Posts: 191
Joined: Tue 19. Aug 2014, 09:30

Post by Martin Vieregg » Wed 27. Jun 2018, 09:27

Mein ME Editor zeigt stdout aus der Kommandozeile an:

Code: Select all

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.
Posts: 418
Joined: Tue 24. Dec 2013, 16:40

Post by Andi B. » Wed 27. Jun 2018, 10:49

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
Posts: 191
Joined: Tue 19. Aug 2014, 09:30

Post by Martin Vieregg » Wed 27. Jun 2018, 22:33

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

aschn
Posts: 692
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Thu 28. Jun 2018, 09:04

Martin Vieregg wrote:
Wed 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.
Last edited by aschn on Thu 28. Jun 2018, 18:58, edited 2 times in total.
Andreas Schnellbacher

Martin Vieregg
Posts: 191
Joined: Tue 19. Aug 2014, 09:30

Post by Martin Vieregg » Sat 25. Aug 2018, 00:20

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
Posts: 39
Joined: Wed 22. Nov 2017, 23:46

Post by ehemaliger » Sat 25. Aug 2018, 07:58

Martin Vieregg wrote:
Sat 25. Aug 2018, 00:20
Ich 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.
Last edited by ehemaliger on Sat 25. Aug 2018, 08:01, edited 1 time in total.

Martin Vieregg
Posts: 191
Joined: Tue 19. Aug 2014, 09:30

Post by Martin Vieregg » Sat 25. Aug 2018, 11:26

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.
Posts: 418
Joined: Tue 24. Dec 2013, 16:40

Post by Andi B. » Sun 26. Aug 2018, 13:47

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
Posts: 191
Joined: Tue 19. Aug 2014, 09:30

Post by Martin Vieregg » Wed 12. Sep 2018, 23:18

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
Posts: 191
Joined: Tue 19. Aug 2014, 09:30

Post by Martin Vieregg » Mon 8. Oct 2018, 21:35

Inzwischen hat mich ein Natives speaker aufgeklärt, dass "doo" nicht passend ist...
Ich freue mich über Namensvorschläge.

aschn
Posts: 692
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Mon 8. Oct 2018, 22:27

Nenn es doch "DU" (Do Utility). Damit sollte auch die Beziehung zum ehemaligen "DO" herstellbar sein.
Andreas Schnellbacher

User avatar
efbe
Posts: 46
Joined: Thu 11. Sep 2014, 19:33
Location: Dortmund

Post by efbe » Tue 9. Oct 2018, 09:49

aschn wrote:
Mon 8. Oct 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

User avatar
ak120
Posts: 906
Joined: Thu 8. May 2014, 12:50
Location: Demmin

Post by ak120 » Tue 9. Oct 2018, 14:40

Martin Vieregg wrote:
Mon 8. Oct 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.

aschn
Posts: 692
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Wed 10. Oct 2018, 00:28

Dann würde auch noch DOU passsen. Was DOE bedeuten soll, ist mir unklar.
Andreas Schnellbacher

User avatar
Frank Wochatz
Posts: 874
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz » Wed 10. Oct 2018, 10:24

Wie wärs mit "machmal" ;)

Martin Vieregg
Posts: 191
Joined: Tue 19. Aug 2014, 09:30

Post by Martin Vieregg » Fri 9. Nov 2018, 08:36

es soll englisch sein. Klingt ein bißchen nach "manchmal" .... und so schlecht ist es jetzt auch nicht programmiert.
Last edited by Martin Vieregg on Fri 9. Nov 2018, 08:37, edited 1 time in total.

Martin Vieregg
Posts: 191
Joined: Tue 19. Aug 2014, 09:30

Post by Martin Vieregg » Mon 12. Nov 2018, 22:49

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
Posts: 19
Joined: Mon 6. Jan 2014, 12:00

Post by dargndorp » Tue 13. Nov 2018, 17:48

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
Posts: 191
Joined: Tue 19. Aug 2014, 09:30

Post by Martin Vieregg » Mon 3. Dec 2018, 22:13

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