Aus mit tree erstellter Datei nur den Dateinamen (mit Endung) und die Dateigröße extrahieren

Hallo

Quote from hyle

Mit Python würde ich das vermutlich über find() und split() erledigen.

Anstatt `find` würde ich `in` verwenden. Weil ich denke dass das sonst so ein gefummel werden kann. Mit `in` bekomme ich mal meine gewünschte Zeile und kann die dann gemütlich formatieren und muss nicht auf einen Indexbereich zugreifen, der vielleicht etwas unverständlich ist. (Zumindest so wie ich mir das gerade vorstelle.

from icecream import ic

FILE = """
├── [       4096]  Music
│   └── [       4096]  1
│       └── [       4096]  2
│           └── [       4096]  3
│               └── [       4096]  Ministry
│                   └── [       4096]  Houses Of The Mole [MYNCD023]
│                       ├── [    5042857]  01-No W.mp3
│                       ├── [    7240212]  02-Waiting.mp3
│                       ├── [    6089950]  03-Worthless.mp3
│                       ├── [    7285550]  04-Wrong.mp3
│                       ├── [    5595921]  05-Warp City.mp3
│                       ├── [    6463257]  06-WTV.mp3
│                       ├── [    7740841]  07-World.mp3
│                       ├── [    7190622]  08-WKYJ.mp3
│                       ├── [   12208242]  09-Worm.mp3
│                       ├── [    7059500]  10-Psalm.mp3
│                       └── [    3841604]  11-Walrus.mp3
├── [       4096]  Pictures
├── [       4096]  Public
"""


def main():
    search_results = [line.split("] ") for line in FILE.splitlines() if "mp3" in line]
    format_results = [
        (
            "".join(character for character in result[0] if character.isdigit()),
            result[1].strip(" "),
        )
        for result in search_results
    ]
    ic(format_results)


if __name__ == "__main__":
    main()

Ergibt:

ic| format_results: [('5042857', '01-No W.mp3'),
                     ('7240212', '02-Waiting.mp3'),
                     ('6089950', '03-Worthless.mp3'),
                     ('7285550', '04-Wrong.mp3'),
                     ('5595921', '05-Warp City.mp3'),
                     ('6463257', '06-WTV.mp3'),
                     ('7740841', '07-World.mp3'),
                     ('7190622', '08-WKYJ.mp3'),
                     ('12208242', '09-Worm.mp3'),
                     ('7059500', '10-Psalm.mp3'),
                     ('3841604', '11-Walrus.mp3')]

Finde ich recht übersichtlich.

Grüße

Dennis

hyle Verzeichnisse kann man an der Grösse vermuten aber eben nicht *zuverlässig* erkennen. Es kann ja auch Dateien geben die genau 4 KiB gross sind.

L$ = "│                   └── [       4096]  Houses Of The Mole [MYNCD023]"

i = INSTR(L$, "[")         ' Position des ersten "[".
j = INSTR(i + 1, L$, "]")  ' Position des ersten "]" nach dem ersten "[".
k = INSTR(j + 1, L$, "[")  ' Position des "[" nach dem ersten "]".

PRINT L$
PRINT TAB(i); "^"; TAB(j); "^"; TAB(k); "^"
PRINT TAB(i); "i"; TAB(j); "j"; TAB(k); "k"

PRINT "Dateigrösse (inklusive Klammern): "; MID$(L$, i, j - i + 1)
' Alles ab drei Zeichen nach dem ersten "]" = Dateiname.
PRINT "Dateiname >"; MID$(L$, j + 3); "<"

Ausgabe:

│                   └── [       4096]  Houses Of The Mole [MYNCD023]
                        ^           ^                     ^
                        i           j                     k
Dateigrösse (inklusive Klammern): [       4096]
Dateiname >Houses Of The Mole [MYNCD023]<

hyle Zum besseren Verständnis des BASIC-Beispiels wollte ich die BASIC-Anweisungen/-Funktionen mal in Python umsetzen und zeigen, aber bei Deinem Benutzernamen dachte ich Hy wäre als Programmiersprache vielleicht passender. 🤡

Hy ist ein Lisp-Dialekt der in Python programmiert ist und auf der Python-Bytecode-VM läuft und deshalb Python-Module verwenden kann.

Ich finde es interessant wie nah die Hauptfunktion noch am BASIC-Code dran ist.

#!/usr/bin/env hy
(import hyrule *
        collections [namedtuple]
        blessed [Terminal])
(require hyrule *)

(setv TAB (namedtuple "Tab" "column")
      TERMINAL (Terminal))


(defn PRINT [#* items]
  (for [item items]
    (when (isinstance item TAB)
      (setv [row column] (.get-location TERMINAL)
            new-column (dec (. item column))
            item (if (< column new-column)
                   (.move-x TERMINAL new-column)
                   "")))
    (print item :end ""))
  (print))


(defn INSTR [start-or-string string-or-substring [substring-or-none None]]
  (inc (if (is substring-or-none None)
         (.find start-or-string string-or-substring)
         (.find string-or-substring substring-or-none (dec start-or-string)))))


(defn MID$ [string start-index [length None]]
  (cut string
       (dec start-index)
       (if (is length None)
         None
         (+ (dec start-index) length))))


(defmain []
  (setv L$ "│                   └── [       4096]  Houses Of The Mole [MYNCD023]"
        i (INSTR L$ "[")          ; Position des ersten "[".
        j (INSTR (+ i 1) L$ "]")  ; Position des ersten "]" nach dem ersten "[".
        k (INSTR (+ j 1) L$ "[")) ; Position des "[" nach dem ersten "]".
  
  (PRINT L$)
  (PRINT (TAB i) "^" (TAB j) "^" (TAB k) "^")
  (PRINT (TAB i) "i" (TAB j) "j" (TAB k) "k")
  (PRINT "Dateigrösse (inklusive Klammern): " (MID$ L$ i (+ (- j i) 1)))
  ; Alles ab drei Zeichen nach dem ersten "]" = Dateiname.
  (PRINT "Dateiname >" (MID$ L$ (+ j 3)) "<"))

Quote from __blackjack__

aber bei Deinem Benutzernamen dachte ich Hy wäre als Programmiersprache vielleicht passender. 🤡

hyrule gefällt mir gut!

Den Code sehe ich mir später am Moni mal im Ganzen an.

Okay, irgendwie sind dynamische, interpretierte Programmiersprachen ja voll überdimensionierte „bloat”-Software. Im Grunde nervt auch bei C schon diese massive Speicherverschwendung bei Code und Daten. Eigentlich braucht man ja nur den Kernel, und ein paar Bytes Code, ohne irgendwelche zusätzlichen Bibliotheken. AsSeMbLeR!!!

Und da es auf dem Raspi laufen muss ARM Assembler. Der Thumb-Befehlssatz, damit es klein bleibt. 😇

Das Programm liest von der Standardeingabe und schreibt auf die Standardausgabe.

        .global _start

        .thumb_func
_start:

@ Register r6 holds the address of the next free byte in the buffer for the file
@ size digits.

line_loop:

skip_to_opening_bracket_loop:
        bl      get_char
        cmp     r0, #'['
        bne     skip_to_opening_bracket_loop

skip_to_digits_loop:
        bl      get_char
        cmp     r0, #' '
        beq     skip_to_digits_loop
    
        ldr     r6, =buffer
        b       store_digit
read_to_closing_bracket_loop:
        bl      get_char
        cmp     r0, #']'
        beq     read_to_closing_bracket_loop_exit
store_digit:
        strb    r0, [r6]
        add     r6, #1
        b       read_to_closing_bracket_loop
read_to_closing_bracket_loop_exit:

        bl      get_char  @ Skip two characters (spaces) after "]".
        bl      get_char
    
copy_filename_loop:
        bl      get_char
        cmp     r0, #'\n'    
        beq     copy_filename_loop_exit
        
        ldr     r1, =character
        mov     r2, #1
        bl      print
        
        b     copy_filename_loop
copy_filename_loop_exit:

        adr     r1, pre_size_text
        mov     r2, #pre_size_text_length
        bl      print
        
        ldr     r1, =buffer
        sub     r2, r6, r1
        bl      print

        adr     r1, post_size_text
        mov     r2, #post_size_text_length
        bl      print

        b       line_loop

@--------------------------------------
exit:    
        mov     r7, #1
        mov     r0, #0
        svc     0

@--------------------------------------
get_char:
        mov     r7, #3
        mov     r0, #0
        ldr     r1, =character
        mov     r2, #1
        svc     0
        
        cmp     r0, #0
        beq     exit
        
        ldr     r0, =character
        ldrb    r0, [r0]
        
        bx      lr

@--------------------------------------
print:
        mov     r7, #4
        mov     r0, #1
        svc     0
        bx      lr

@--------------------------------------
.align 2
pre_size_text:
        .ascii " ["
        .equ pre_size_text_length, . - pre_size_text

.align 2
post_size_text:
        .ascii "]\n"
        .equ post_size_text_length, . - post_size_text

@--------------------------------------
.bss

character:          @ Last read character.
        .space 1

buffer:             @ Buffer for the digits of the file size.
        .space 15

Übersetzt und ”gestripped” ein Binary mit gerade mal 512 Bytes:

$ as test.s -o test.o && ld test.o -o test && strip test
$ ls -l test
-rwxr-xr-x 1 osmc osmc 512 Mar 26 23:56 test
$ ldd test
  not a dynamic executable

Hallo __blackjack__ ,

was muss ich denn tun, damit ich den Code laufen lassen kann? Einen Compailer braucht man ja noch um das in Bitcode zu übersetzen.(?)

Ist die nächste nähere Möglichkeit direkt auf die Register zuzugreifen, den Bitcode selbst zu schreiben?

Grüße

Dennis

Dennis89 Die Übersetzung von Assembler in ein ausführbares Programm steht doch unten im Beitrag #25. as ist der GNU Assembler, der übersetzt das in eine *.o-Datei, die dann mit dem Linker ld in ein ausführbares Programm umgewandelt wird. Beide Programme kommt automatisch auf's System wenn man GCC installiert. Ich habe das alles test.* (test.s → test.o → test) genannt. Also ausführbar mit, beispielsweise tree -s /etc | ./test. Getestet auf OSMC (32-Bit ARM Linux).

strip entfernt unnötige Informationen (Debugger-Information, Symboltabelle) aus der ausführbaren Programmdatei. Das ist nicht notwendig, aber ich wollte ja was gegen diese furchtbare Ressourcenverschwendung machen. 😉

Die nächst-masochistische Option wäre dann die Bytes für den Maschinencode von Hand zu schreiben und da von Hand die nötigen Informationen für das ELF-Dateiformat drumherum zu basteln. Das ist bei ARM aber sehr nervig weil dort sehr viel mit relativen Adressen gearbeitet wird, wie man am Disassembly-Listing sehen kann. Wo ”früher” bei 8-Bit-Heimrechnern (6502, Z80, …) jeder Sprung zu einer Unterroutine wie get_char mit den gleichen Bytes kodiert wird, ist das bei x86 16-Bit-Code und ARM relativ zur Adresse des aktuell ausgeführten Maschinenbefehls/dem Wert des pc-Registers. Das heisst jeder Aufruf ist mit leicht unterschiedlichen Bytes kodiert und man muss jedes mal ausrechnen wie weit die Zieladresse von der aktuellen Adresse entfernt ist und das in die entsprechende Bytefolge umrechnen. Aber auch Konstanten wie Adressen von Daten werden relativ zum pc-Register adressiert. Vorteil ist natürlich das man dadurch weniger feste Adressen im Maschinencode hat, wo man noch zusätzlich Tabellen zum verschieben für den Lader des Betriebssystems für die ”EXE” ausrechnen und anlegen muss.

Das folgende Listing enthält grob gesprochen drei Spalten. Die erste Spalte enthält die Adresse (hexadezimal) wo der Code im Speicher liegt, die zweite Spalte die Bytes als 16-Bit Werte (hexadezimal) die an der Adresse im Speicher liegen, und der Rest ist der disassemblierte Maschinenbefehl (oder Pseudo-Opcode) der durch die Bytes kodiert wird. Die zweite Spalte ist das was man manuell erstellen/”ausrechnen” müsste.

$ objdump -d test

test:     file format elf32-littlearm


Disassembly of section .text:

00010074 <_start>:
   10074:	f000 f82c 	bl	100d0 <get_char>
   10078:	285b      	cmp	r0, #91	; 0x5b
   1007a:	d1fb      	bne.n	10074 <_start>

0001007c <skip_to_digits_loop>:
   1007c:	f000 f828 	bl	100d0 <get_char>
   10080:	2820      	cmp	r0, #32
   10082:	d0fb      	beq.n	1007c <skip_to_digits_loop>
   10084:	4e1b      	ldr	r6, [pc, #108]	; (100f4 <constants+0x2>)
   10086:	e003      	b.n	10090 <store_digit>

00010088 <read_to_closing_bracket_loop>:
   10088:	f000 f822 	bl	100d0 <get_char>
   1008c:	285d      	cmp	r0, #93	; 0x5d
   1008e:	d002      	beq.n	10096 <read_to_closing_bracket_loop_exit>

00010090 <store_digit>:
   10090:	7030      	strb	r0, [r6, #0]
   10092:	3601      	adds	r6, #1
   10094:	e7f8      	b.n	10088 <read_to_closing_bracket_loop>

00010096 <read_to_closing_bracket_loop_exit>:
   10096:	f000 f81b 	bl	100d0 <get_char>
   1009a:	f000 f819 	bl	100d0 <get_char>

0001009e <copy_filename_loop>:
   1009e:	f000 f817 	bl	100d0 <get_char>
   100a2:	280a      	cmp	r0, #10
   100a4:	d004      	beq.n	100b0 <copy_filename_loop_exit>
   100a6:	4914      	ldr	r1, [pc, #80]	; (100f8 <constants+0x6>)
   100a8:	2201      	movs	r2, #1
   100aa:	f000 f81b 	bl	100e4 <print>
   100ae:	e7f6      	b.n	1009e <copy_filename_loop>

000100b0 <copy_filename_loop_exit>:
   100b0:	a10e      	add	r1, pc, #56	; (adr r1, 100ec <pre_size_text>)
   100b2:	2202      	movs	r2, #2
   100b4:	f000 f816 	bl	100e4 <print>
   100b8:	490e      	ldr	r1, [pc, #56]	; (100f4 <constants+0x2>)
   100ba:	1a72      	subs	r2, r6, r1
   100bc:	f000 f812 	bl	100e4 <print>
   100c0:	a10b      	add	r1, pc, #44	; (adr r1, 100f0 <post_size_text>)
   100c2:	2202      	movs	r2, #2
   100c4:	f000 f80e 	bl	100e4 <print>
   100c8:	e7d4      	b.n	10074 <_start>

000100ca <exit>:
   100ca:	2701      	movs	r7, #1
   100cc:	2000      	movs	r0, #0
   100ce:	df00      	svc	0

000100d0 <get_char>:
   100d0:	2703      	movs	r7, #3
   100d2:	2000      	movs	r0, #0
   100d4:	4908      	ldr	r1, [pc, #32]	; (100f8 <constants+0x6>)
   100d6:	2201      	movs	r2, #1
   100d8:	df00      	svc	0
   100da:	2800      	cmp	r0, #0
   100dc:	d0f5      	beq.n	100ca <exit>
   100de:	4806      	ldr	r0, [pc, #24]	; (100f8 <constants+0x6>)
   100e0:	7800      	ldrb	r0, [r0, #0]
   100e2:	4770      	bx	lr

000100e4 <print>:
   100e4:	2704      	movs	r7, #4
   100e6:	2001      	movs	r0, #1
   100e8:	df00      	svc	0
   100ea:	4770      	bx	lr

000100ec <pre_size_text>:
   100ec:	5b20      	.short	0x5b20
   100ee:	46c0      	nop			; (mov r8, r8)

000100f0 <post_size_text>:
   100f0:	0a5d      	.short	0x0a5d

000100f2 <constants>:
   100f2:	0000      	.short	0x0000
   100f4:	000200fd 	.word	0x000200fd
   100f8:	000200fc 	.word	0x000200fc

Und dann müsste man das Ergebnis noch in die Struktur einer ELF-Datei verpacken, die auch diverse Offsetwerte in die Datei enthält, die man ausrechnen muss. Die Zeiten wo man einfach ein Speicherabbild von Code und Daten ausführt, wie bei 8-Bit-Heimrechnern oder auch noch DOS *.COM, sind ja vorbei. Damals gab es noch etwas zwischen (Makro-)Assembler und alle Bytes manuell ermitteln: Programme mit denen man einzelne Assembler-Befehle interaktiv an Speicheradressen übersetzen kann. DOS bringt so etwas direkt mit: debug.com. Einige 8-Bit-Rechner haben so ein Programm ab Werk im ROM, bei anderen muss man das laden oder als ROM nachrüsten.

Danke für die Erklärungen.

Habe das nicht erkannt, dass das unter #25 die Übersetzung des Codes ist. Auch wenn es da steht, dachte ich mir nur "Hm 💁"

Das ist jetzt weit vom eigentlichen Thema weg, aber ist das bei allen Sprachen die einen Compailer benötigen so, dass der Code direkt in Maschinencode übersetzt wird und direkt auf die Speicheradressen zugreift? Also ohne dass das Betriebssystem einen Einfluss auf die Programmausführung hat?

Bei Python ist ja noch der Interpreter dazwischen und da wird alles zur Laufzeit übersetzt und die letztendliche Ausführung wird noch vom Betriebssystem beeinflusst. Wie ist das bei C oder Rust? Ist der compilierte Code von der Nähe zur Hardware vergleichbar mit deinem Assembler-Code?

Von meiner Vorstellung her schon, man schreibt ja mit den genannten Sprachen auch Firmeware. Aber wie läuft das wenn man den Code unter einem Betriebssystem aussführt?

Grüße

Dennis

Compiler für nativ compilierte Sprachen, also wo Binärcode raus kommt, der direkt vom Prozessor ausgeführt wird, erzeugen manchmal direkt den Maschinencode aber manchmal auch erst Assembler-Quelltext als Zwischenformat.

Das Betriebssystem gibt nach dem Laden üblicherweise die Kontrolle an den Maschinencode ab. Wobei bei modernen Betriebssystemen die Multitasking können, das System die Kontrolle auch regelmässig wieder weg nimmt um seine Arbeit zu erledigen. ”Früher”, beispielsweise beim Amiga und den ersten Windows-Versionen mussten die Programme die Kontrolle selbst regelmässig abgeben. Da konnten Programme, die das nicht gemacht haben, das System aufhängen bzw. die ganze Rechenzeit für sich selbst beanspruchen.

Was beim laden eines nativen Programms passiert, variiert stark zwischen Systemen und Dateiformaten.

In den simpelsten Fällen wird die Datei einfach 1:1 an eine feste Adresse in den Speicher geladen und dann zu einer festen Adresse gesprungen. Zum Beispiel bei CP/M und bis zu einem gewissen Grad bei DOS und .COM-Dateien.

Wenn der Lader das Programm an eine unbekannte/unvorhersehbare Adresse laden können muss, zum Beispiel um mehr als ein Programm im Speicher zu haben, sind in der Programmdatei Tabellen enthalten welche Adressen im Speicher relativ zur Ladeadresse angepasst werden müssen. Beispiel dafür sind DOS .EXE-Dateien.

Nächste Stufe sind Programme wo nicht mehr in jedem Programm alles enthalten ist was benötigt wird: dynamsiche Bibliotheken: Da sind in der Programmdatei auch noch Tabellen enthalten mit Symbolen und an welchen Adressen im Programm die verwendet werden, und die Namen von den Bibliotheken die benötigt werden. Der Lader lädt dann die Bibliotheken, sofern noch nicht um Speicher, und das Programm, und geht dann die Stellen im Programm durch wo Adressen aus Bibliotheken benutzt werden und setzt dort die passenden Werte ein. Da wären wir dann bei Windows & Linux.

Das mit dem anpassen der Adressen im Code an die Adresse wo das Programm in den Speicher geladen wurde, kann teilweise wegfallen wenn die Hardware Adressvirtualisierung unterstützt. Dann kann man alle Programme für eine feste Startadresse übersetzen als wenn sie jeweils den ganzen Speicher für sich alleine hätten.

Vielen Dank für die ausführliche Erklärung.

Ich habe jetzt kein Anwendungsbeispiel dafür, aber wenn ich das richtig verstehe, hat bei den heute üblichen Betriebssystem, das Betriebssystem selbst immer das letzte Wort, wann etwas ausgeführt wird? Egal ob Interpreter-Sprache oder compilierte Sprache? Die Interpreter-Sprache ist nur etwas langsamer, weil zur Laufzeit der Interpreter noch mit im Boot ist?

Bei Mikrokkontroller gibt es ja `FreeRTOS` und wenn ich an einem Computer etwas echtzeitfähiges erreichen will, benötige ich ein anderes Betriebssystem wie Windows oder Linux?

Ich versuche zum einen nur detaillierter den Unterschied zwischen Compailer- und Interpreter-Sprache zu verstehen, was die theoretische Geschwindigkeit angeht. Wenn beides mal das Betriebssystem das letzte Wort hat, dann würde das für mich bedeuten, dass "nur" der Interpreter dafür verantwortlich ist, dass Interpreter-Sprachen langsamer sind als Compailer-Sprachen.

Grüße

Dennis

Das Betriebssystem sollte im Idealfall das letzte Wort haben, denn dessen Aufgabe ist es ja die Ressourcen des Systems zu verwalten. CPUs/CPU-Zeit ist ja eine der Ressourcen die es verwaltet und den Prozessen zuteilt.

Für Linux gibt es RTLinux für Echtzeitfähigkeit.

Das interpretierte Sprachen langsamer abgearbeitet werden hat mit dem Betriebssystem nicht wirklich etwas zu tun. Das ist ja auch unter primitiven Systemen wie DOS oder sogar Mikrokontrollern ohne Betriebssystem genau so. C-Programme sind dort auch schneller als MicroPython-Programme, eben weil in einem Fall der Prozessor das Programm abarbeitet und im anderen Fall der Prozessor den Interpreter abarbeitet der das Programm interpretiert. Und dann spielt da natürlich auch noch rein, dass bei C der Compiler die Datentypen kennt wenn beispielsweise a + b übersetzt wird und dafür den direkt passenden Maschinencode generiert werden kann, während das bei Python erst zur Laufzeit festgestellt wird welcher Code für das + letztendlich ausgeführt werden muss.

Vielen Dank!

Das mit den Datentypen festlegen ist mir bei `Rust` auch schon ab und zu auf die Füße gefallen, weil es doch ungewohnt ist, wenn man nur Python kennt. Ich war auch erst "überrascht" dass wenn ich eine leere Liste will, das ich die Anzahl der Elemente die mal in die Liste kommen und den Datentyp der Elemente gleich festlegen muss. Mittlerweile konnte ich dass dann verstehen.

Ich finde es macht einen großen Unterschied, ob man die Syntax einer Sprache lernt oder ob man versteht, was denn im Hintergrund noch alles passiert. Wobei mir bewusst ist, dass das komplexer ist, aber wenigstens hat man mal eine grobe Vorstellung.

Grüße

Dennis