Unter Linux kann man Man-Pages in html umwandeln und im Browser öffnen:
man --html=firefox ls
Dies wandelt die Man-Page für ls in html um und speichert dies in einer temporären Datei. Anschließend wird dann firefox mit entsprechendem Parameter aufgerufen.
Damit dies funktioniert muss groff installiert sein, was beispielsweise unter Ubuntu standardmäßig nicht installiert ist.
Was für eine Sprache ist dieser seltsam aussehender Code? Sieht aus wie C, aber irgendwas ist da falsch.
%:include <stdio.h>
int main(int argc, char **argv)
<%
char str<::> = "World";
printf("Hello %s!\n", str);
return 0;
%>
Es handelt sich dabei tatsächlich um standardkonformes C.
Die libc-Streams, repräsentiert durch FILE-Pointer, können nicht nur mit fopen erzeugt werden. Eine ganze Reihe an Funktionen erstellt ebenfalls diese Streams, die dann auch mit den stdio-Funktionen wie z.B. fprintf genutzt werden können.
FILE *fdopen(int fd, const char *mode);
Mit fdopen erstellt man aus einem Unix-Filedescriptor ein FILE. Diese Funktion steht unter jedem POSIX-kompatiblen Betriebsystem zur Verfügung.
FILE *fmemopen(void *buf, size_t size, const char *mode);
Diese Funktion erstellt aus einem Buffer ein Stream. Der Buffer hat eine feste Größe, und gelangt der Stream an dessen Ende, wird nicht weiter geschrieben. Diese Funktion wurde durch die glibc eingeführt. Sie ist mitlerweile zwar im Posix-Standard, aber noch nicht überall verfügbar.
FILE *open_memstream(char **bufp, size_t *sizep);
Wie bei fmemopen erhält man mit dieser Funktion einen Stream für den Zugriff auf einen Buffer, allerdings wird dieser dynamisch mit malloc erstellt. Wenn nötig wird der Buffer auch automatisch vergrößert. Auch diese Funktion ist mitlerweile Posix-Standardisiert.
Beispiel:
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv) {
char *buf;
size_t len;
FILE *f = open_memstream(&buf, &len);
fprintf(f, "test\n");
fprintf(f, "%d\n", 5);
fprintf(f, "%s\n", "hello world");
fclose(f);
printf("%s", buf);
free(buf);
return 0;
}
FILE *
funopen(void *cookie, int (*readfn)(void *, char *, int),
int (*writefn)(void *, const char *, int),
off_t (*seekfn)(void *, off_t, int), int (*closefn)(void *));
Die BSDs haben die sehr mächtige Funktion funopen, die einen Stream anhand eigener I/O-Funktionen erstellt. Die I/O-Operationen, die durch die libc-Funktionen, wie z.B. fgetc, fputc, fprintf, usw., erzeugt werden, werden dann an die eigenen I/O-Funktionen, die man funopen übergeben hat, weitergeleitet. So kann man für praktisch alles was man sich vorstellen kann ein FILE*-kompatibles Interfaces erstellen.
Diese Funktion ist nur unter den BSD-Betriebsystemen verfügbar. NetBSD hat sogar die noch mächtigere Funktion funopen2.
FILE *fopencookie(void *cookie, const char *mode,
cookie_io_functions_t io_funcs);
Die glibc folgt dem BSD-Vorbild, leider waren sie natürlich nicht in der Lage, das bereits bestehende Interface zu übernehmen. Trotzdem macht fopencookie genau das gleiche wie funopen. Man erzeugt einen Stream mit eigenen I/O-Funktionen. Der Unterschied ist hier, dass die Funktionspointer nicht einzelnd übergeben werden, sondern es wird eine Struct, die die Pointer enthält, übergeben.
Beispielcode ohne großartige Erklärung.
In dem Programm wird die Ausgabe von stdout durch ein Log-Prefix in jeder Zeile ergänzt.
Kommentare
dev | Artikel: Datei ver- und entschlüsseln mit openssl - kompatibel mit dav
Andreas | Artikel: Datenanalyse in der Shell Teil 1: Basis-Tools
Einfach und cool!
Danke Andreas
Rudi | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Peter | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Damit wird Nedit durch XNedit ersetzt.
Danke!
Olaf | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Anti-Aliasing hängt von der Schriftart ab. Mit einem bitmap font sollte die Schrift klassisch wie in nedit aussehen.
Einfach unter Preferences -> Default Settings -> Text Fonts nach einer passenden Schriftart suchen.
Peter | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Mettigel | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Ich hatte gedacht, dass der GX-415 im s920 deutlich mehr Dampf hat als der Raspi4.
Mein Thinclient verbraucht mit 16 GB RAM ~11 W idle, das ist das Dreifache vom RP4. Das muss man dem kleinen echt lassen... Sparsam ist er.
Olaf | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Ergebnisse von der Ultra 80 wären natürlich interessant, insbesondere im Vergleich mit dem rpi1.