Entries tagged 'author:steeph' (Page 39)

SBWG - steeph's bash website generator Entry Permalink (edited 2021-12-05) Authors: steeph (370) Categories: Bash (31) Code (31) Computer (78) Linux (35) Projects (41) SBWG (18) Scripts (28) Software (52) Languages used: en (255) Topics: Projects → Code → Bash Scripts → SBWG (16) Projects → Web Sites (6) edit

So in this entry I kind of just want to introduce SBWG a bit. Even though it's not the first time I post about the project here (it's Dec 2021 now) I realised there is no explanation on what I'm making and the page on the tag cat:SBWG consists pretty much only of updates. This is mainly a personal weblog and not a project web site. So a bit of background should be part of this introduction. To have the entry in the right place and order, I dated it back to Jan 2020, before I started to post updates about SBWG.

Every now an then I develop or intensify an existing interest in a topic and it becomes my main hobby. I've liked shell scripts ever since I started to use Linux. But I really started to write shell scripts for my own use properly in 2019. I wanted to write better and more rebust scripts. Learning a language or improving language skills works best by actually using the language. SBWG is my project that makes me use Bash to archive many different things that I previously didn't know how to accomplish.

SBWG (steeph's bash website generator) is a bash script that generates static HTML from simple text files. A tool that generates/updates this web site when it's run. Bash surely isn't the right choice of programming language for such a task. But I like Bash and don't really care. I try to make SBWG professional in all other respects. But it is a learning project. So there will probably always be things in the code that could be improved. The more features I implement and the more I learn the more I notice that I could have done better. But I do want to keep implementing new features (My list of ideas is long.) and not just rewriting what already works.

For information about the script, have a look at the project page. The README file in the downloadable package has extensive information about how it can be used.

Older version of this entry (obsolete and not actually interesting):

SBWG (steeph's bash website generator) is a bash script that generates static HTML from simple text files.

This entry does not have current information on SBWG. It was initially intended to hold an up-to-date introduction of SBWG with a download link. But I don't want to edit this blog entry all the time. So this stays obsolete and incomplete and I point you to the correct URL.

Even older version of this entry (obsolete and incomplete):

SBWG (steeph's bash website generator) is a bash script that generates static HTML from simple text files. I wrote it just for fun this website. And it's pronounced sibwig (because why not). It is not professional, not very adaptive to other website structures and does not have many features compared to most other static website generators. But if you know HTML and bash you can certainly adapt it for creating other websites. Or use it as it is, if you happen to want the same website structure as I have. If you want, you can download the latest version that I've published here .

The script creates a HTML structure from whatever text files it finds in the source directories.

The script generates an HTML file from every file in the directories pages/ and entries/, as well as blog-like listings for every tag found in these source files. Page files are generated into the html/ directory. Entry pages are generated into the html/entries/ directory. For every tag found in the entry source pages an additional HTML file is created in the html/tags/ directory. You can add more files to the html/ directory. As long as there is no file with the same name being generated or copied by the script, they won't be affected by the script. This way you can add more CSS files, media files, JavaScript files or anything else you might want to add to the website.

Folder Structure

  • html/ - This is where the script puts the resulting web site.
  • entries/ - Source files for blog posts are placed here. Each file is an entry.
  • galleries/ - Contains images that will be presented in a gellery view or attached to a blog entry.
  • pages/ - Source files for other HTML pages, that are not blog posts, are placed here. (e.g. front page, contact information, ...)
  • files/ - Can be used for downloadable or other files linked to from pages and entries.
  • tags/ - Working directory for generating an HTML file per tag. You may ignore it.
  • head - Header used for every generated HTML file.
  • header - Second part of the header. The script may put tags in between head and header.
  • sidebar - The sidebar that is generated and placed in every HTML file by the script. You may ignore this file.
  • footer - Footer used for every generated HTML file.
  • (More files, such as CSS and image files may be placed here anywhere and copied to their respective locations inside html/.
  • The html directory

    This is where the script puts the resulting web site. It can be used as live webroot/symlink to a webroot or you copy your finished website from there to the webserver.

    The entries directory

    This directory is empty when you start a new website. You fill it with source files for entries/blog posts. An HTML page will be generated from each entry source files, all entries will be included in the all.html blog view and entries with tags will be added to the relevant tag pages. Entry source files start with an HTML comment that resembles a header that typically contains the creation date, a title and tags (categories, topics, langeage). All of these are optional. But the structure (the HTML comment) needs to be there in any case) See below for a detailed description of the source file headers with an example.

    The pages directory

    This directory contains source files for static pages that are not blog posts. An HTML page will be generated from each page source file. You can use it for a front page, contact page, etc. Page source files are similar to entry source files but they contain no tags. See below for a detailed description and an example.

    The galleries directory

    This directory can contain directory of images that will be generated into a gallery view. Each subdirectory will become a gallery. If a subdirectory (gallery) and an entry source file (blog post) have the same name, thumbnails of the images will be attached to the blog entry and a link to the gallery view will be placed at the top of the blog entry. A link to the entry will also be included on the gallery page. A gallery does not need to have a corrosponding entry though. You can simply create galleries by putting JPEG and PNG files into a directory and this directory into the galleries directory. Currently only files ending in .jpeg, .jpg or .png are recognised by the script.

    The files directory

    In this directory you can put files that should be available on the generated website but not be processed by the generator script. The content of this directory will be copied to html/files without any check. You can use this for any files that will be linked in pages and blog entries, image files that are not part of a gallery, JavaScript files, etc.

    The tags directory and the sidebar file

    This directory is used by the script to store information about tags found in entry files during the generation process. It is solely a working directory. Files stored in this directory will be deleted during a complete website generation. You can just ignore (er empty or delete) it. A future version of SBWG will likely switch to a better method of keeping track of the tags used and will not need this directory.

    The sidebar file contains the last generated sidebar of the website. This file will be included in everey generated HTML file to enable navigating the website structure. You can ignore this file.

    The head, header and footer

    The head file contains the head of the HTML page structure. It will be used as the beginning of every generated HTML file When starting a new website it contains the neccessary things to generate a sample website. You can edit it to add meta tags and link or include style sheets.

    The header file closes the HTML head and starts its body. It contains the header that will be included in every generated HTML file. When starting a new website it contains a logo and the name of the website. Feel free to include anything that you want to be on the top of every page of your website, like a menu, etc.

    Having the head and the header files separate enables the script to add tags to the HTML head for individual pages. This is currently only used to add the page's title.

    The footer file contains a footer that will be included at the end of every generated HTML file. Feel free to edit it to include anything that you want at the bottom of every page of your website. It also closes the HTML tag structure.

    The root directory

    More files can be placed at the top of the directory structure. As is the script copies the file style.css from here to the html directory. All other files (not mentioned above) will be ignored unless you edit the script to do something with files tht you have added.

    Source File Format

    Every source file (files in the directories pages/ and entries/) is supposed to start with at least three lines of HTML comment. Example source for a page file:

    <!--
    This Is The Page Title
    -->
    This is the page content. It may consist of HTML or only text.

    The first line can be used as an actual comment and is ignored by the script. The second line is used as the page title/entry title. For entries, any additional lines inside the HTML comments are used as tags/topics (one tag per line). The comment should be closed with a line only containing -->. Everything after that is the actual page/entry content. HTML can be used here and will not be filtered by the script. This may change in the future.

    Example source for an entry file:

    <!--
    Blog Entry Title
    1970-01-01
    lang:en
    cat:Category
    top:Topic 1
    top:Random Topic 2
    top:Topic Three
    top:Some other tag
    top:#hashtagsworktoo
    -->
    <p>This is a blog post.</p>

    Tags

    (tbd)

    Tag Icons

    (tbd)

    Dates

    (tbd)

    Options and Arguments

    If the script is run without arguments it's using what I use regularly, which is options t, e, a, r and p. If arguments are given, the script will only generate the part that was selected with its corrosponding option. The following options exist:

  • -s Copy stylesheet files to the output directory.
  • -f Copy the files directory to the output directory.
  • -g Generate image galleries
  • -t Generate tag pages and the sidebar
  • -p Generate pages from the pages/ directory
  • -e Generate entry pages from the entries/ directory
  • -a Generate the all.html file
  • -r Generate RSS feed
  • -c A complete re-build. All of the above
  • Not all of these options are implemented, yet, but at this point, all except the RSS feed generation works well enough. Keep in mind though that this is all work in progress and I'm only meeting my own needs as I'm not aware of anybody else using this script.

    Options that can be set through variables in the script

    Not all available options can be set through command line arguments (yet?). There are a few variables that are being set at the beginning of the sctipt. Check out the first few lines. The comments above the lines where variables are being set should be sufficiant explanations of those variables. There you can set for example the size of gallery images and thumbnails, the number of blog post per page or the directory where the generated HTML site is placed to.

    Major features still missing

    RSS feed, nice layout and styles

    Comment via email
    I took a picture of trees. Entry created on 2011-10-18 Authors: steeph (370) Categories: Photos (29) Trees (2) edit
    File Attachments (1 file)
    ITAP of trees-IMG_1993b2.JPG (image/jpeg, 1406657 B)
    ITAP of trees-IMG_1993b2.JPG (image/jpeg, 1406657 B)
    Comment via email
    Little Love Entry created on 2009-02-14 Authors: steeph (370) Categories: Hearts (1) Photos (29) edit
    #This entry should have an image attachment.
    File Attachments (1 file)
    little_love-IMG_0286.b2.jpg (image/jpeg, 447003 B)
    little_love-IMG_0286.b2.jpg (image/jpeg, 447003 B)
    Comment via email
    I took a picture of vineyards in the winter. Entry created on 2009-01-16 Authors: steeph (370) Categories: Bad Dürkheim (2) Photos (29) Snow (1) Vineyards (1) edit
    File Attachments (1 file)
    ITAP of vineyards-IMG_9352_b.JPG (image/jpeg, 5399671 B)
    ITAP of vineyards-IMG_9352_b.JPG (image/jpeg, 5399671 B)
    Comment via email
    This SGI Indigo Entry Permalink Authors: steeph (370) Categories: Computers (19) incomplete (22) edit
    Comment via email
    Was ich mir in einer Smartphone-App für Klarträumer wünschen würde Entry Permalink Authors: steeph (367) Categories: #100DaysToOffload (41) Dreams (4) Lucid Dreaming (12) Languages used: de (88) edit

    Angeregt von einem Post im Klartraumforum, der nach Ideen für und Erfahrungen mit Klartraum-Apps für Smartphones fragt habe ich mal meine Ideen für eine Klartraum-App aufgeschreiben. Jedenfalls die Grundideen. Weil es ein langer Text geworden ist schieb' ich den mal auch hier hin.

    Mein persönliches Wunsch-Feature-Set wäre:

    • Rhythm Napping Player
    • RC-Reminder
    • Zentrale Schnittstelle für REM-Erkennung und Aktion
    Funktionen, die mich nicht ansprechen, meiner Meinung nach aber gut in eine solche App passen:
    • Tipps-Feeder für Afänger
    • Traumtagebuch

    Mit Rhythm Napping habe ich persönlich sehr gute Erfolge. Die Funktion wäre relativ simpel: Man wählt ein Audio-Sample aus. Es ist fast egal was. Ein plötzlicher Anfang, wie bei einem Gong, scheint gut zu funktionieren. Es könnten ein paar Sounds dabei sein. Ich würde aber auch meine eigene Datei auswählen können wollen. Die Verzögerung (Einschlafzeit/Zeit bis erwarteten REM) wird in Minuten eingestellt. Der Abstand der Sounds wird in Minuten eingestellt, mit der Option auf "überrasche mich". Dazu sollte auch noch eine Abweichung vom eingestellten Abstand in Minuten eingestellt werden können, vielleicht auch wieder mit einer Überrasch-Option. Damit weicht das Modell von dem des Namensgebers ab. Mir gefällt es so besser. Aber auch eine klassische Folge wäre mir Recht.

    Apps, die einen an irgendetwas erinnern sollen, gibt es zwar viele. Aber die Bedürfnisse von Klarträumern scheinen speziell genug zu sein, dass es dafür eine App braucht, die flexibel genug ist, um auf das individuelle Training angepasst werden zu können. Was mir wichtig wäre, sind Erinnerungen in semi-zufälligen Abständen (keine Häufung, Mindestabstand) mit einstellbarer Anzahl pro Tag und nicht schnell Ruhe gibt, bevor der App gemeldet wurde, ob der RC positiv oder negativ ausfiel (ein Slider mit Zischenwerten wäre nett). Ich habe einige Ideen, wie ein RC-Reminder aufwendiger und vielseitiger designt werden könnte. Aber der Nutzen zusätzlicher Verkomplizierungen ist fragwürdig und müsste untersucht werden. Meine Ideen gehen auch in die Richtung Gedächnistraining.

    Was wirklich fehlt under den Klartraum-Apps ist eine Möglichkeit, zusätzliche Hardware zur REM-Schlaf-Erkennung und zur Abgabe von Signalen zu verwenden. Selbst wenn man ein Bluetooth-EEG und eine über Bluetooth schaltbare Lampe hat, ist es nicht einfach möglich, letztere zu aktivieren, wenn die Daten ersteres auf REM-Schlaf hindeuten. Was ich mir wünsche ist eine Zentrale, die aus unterschiedlichen Daten versucht, REM-Schlaf zu erkennen und dann beliebige Aktoren schalten kann. Ich sehe nicht, dass eine für diesen Zweck entwickelte, offene Schnittstelle viel Verwendung fände. Eher stelle ich mir vor, vorhandene USB-, Netzwerk- und Bluetooth-Geräte für Klarträumer verwendbar zu machen, indem aus den zur Verfügung stehenden Rohdaten so gut wie möglich erraten wird, wann REM-Schlaf eingetreten ist und dann nach vorher eingestellten Regeln zum Beispiel eine Lampe blinken lässt oder eine Audio-Datei abspielt. Es gibt da diese Java-App dieses Amis, die wohl nur für Windows entwickelt wird, aber über die Jahre eine ansehnliche Sammlung von Plug-Ins für die unterschiedlichsten Datenquellen und Aktuatoren bekommen hat. Ob NeuroSky, OpenEEG, Open BCI, ein eigenes Design, irgendein Kopfband eines dieser Kickstarter, ein rein analoges EEG mit Frequency-Shift am Mikrofoneingang, ein Gamer-EEG-Headset, Philips Hue, Neopixel/WS2812B an einem Arduino, ein paar LEDs in einer Schlafmaske mit einem ESP als USB-Interface, die eingebauten Lautsprecher/ein Bluetooth-Headset, der Vibrations-Motor in einer Smart-Watch, … die eigentliche REM-Erkennung muss aktuell jeder selbst schreiben und fine-tunen. Fast niemand macht das und deshalb sind funktionierende Klartraum-Headsets so selten. Viele dieser Schnittstellen ließen sich relativ bis sehr leicht implementieren. Aber alle auf einmal - die Vielfalt - das ist eben ein Projekt, das leicht abschreckt. Eine infividuelle Lösung mit propritärer Hard- und Software-Kombination erscheint da offenbar attraktiver als eine offene Schnittstelle für Bastler. Eine offene Schnittstelle würde unter dem Strich aber mehr Träumern ermöglichen, REM-Erkennung praktisch zu benutzen. (Ich persönlich finde das ein interessantes Thema und könnte immer sehr viel dazu schreiben. Notwendig ist der ganze Aufwand nicht. Wenn man erst mal seinen Schlaf ein bisschen analysiert hat oder für eine Weile rum-experimentiert hat, kann man auch einfach mit einer zeitlichen Verzögerung ab dem Hinlegen arbeiten und oft genug einen geeigneten Moment für das Signal oder die Stimulation erwischen.)

    Es gibt sehr unterschiedliche Klartraum-Kurse und Leitfäden. Die genaue Ausgestaltung ist ja eigentlich nur Geschmackssache, solange man sich mit den eigenen Träumen und Traum-Zielen intensiv beschäftigt und die richtigen Grundlagen vermittelt bekommt. Auch ich habe Ideen, wie ein Anfänger-Training gestaltet werden könnte. Das ließe sich in eine solche App gut integrieren. Einfache Übungsaufgaben, kurze Texte, Gedächtnisübungen, Tipps und Fragen nach dem persönlichen Erleben könnten gut mit RC-Erinnerungen kombiniert und in Alltagstätigkeiten integriert werden. Beispiele für tägliche Aufgaben: "Mache heute jedes Mal einen RC, wenn du durch eine Tür gehst." Zwischendurch Erinnerungen. Am Ende des Tages eine Abfrage, wie gut das geklappt hat. Falls nicht so gut wird die Aufgabe schon bald wieder als tägliche Aufgabe kommen. Auch etwas wie "Trinke diese Woche keinen Alkohol" könnte als Aufgabe kommen. Wenn man eh keinen Alkohol trinkt, gibt man das an und bekommt sofort die nächste Aufgabe. Mir würden so viele kleine und länger andaurnde Aufgaben einfallen, die zu einem individuellen Training zusammengesetzt und je nach Bedarf in ihrer Häufigkeit angepasst werden könnten. Den Zusammenhang vieler Aufgaben hier aufzuschreiben wäre jetzt etwas viel. Ich hoffe die grundlegende Idee habe ich schon rüberbringen können. Die meisten Meldungen wären einfach nur kurze Tipps zu RCs, Denkanstöße, Vorschläge fürs Traumaufschreiben, wie Übungen besser gelingen, Motivation, kreative RC-Anstöße.

    Die Traum-Aufzeichnung braucht die App meinetwegen nicht übernehmen. Die Wünsche und Möglichkeiten in Funktionsumfang und Umsetzung sind riesig und es gibt schon genug Apps, in denen strukturiert oder frei Datensätze eingegeben und archiviert werden können. Es gibt auch schon dutzende Apps, die speziell zum Aufschreiben und Auswerten von Träumen gedacht sind. Die Unterschiede sind gewaltig. Natürlich gibt es auch Gründe, weitere solche Apps zu bauen. Jeder hat halt eigene Vorstellungen, wie eine Traum-Aufzeichnungs-App aussehen sollte. Für mich reicht ein einfacher Audiorekorder oder eine einfache Notiz-App. Eine Auswertung der Inhalte in einer Form, aus der ich einen Nutzen ziehen könnte, habe ich noch nicht gesehen und ich bin mir auch nicht sicher, wie die aussehen müsste.

    Da das sehr unterschiedliche Features sind, die auch unabhängig voneinander funktionieren, könnte sie in fünf einzelne Apps aufgeteilt werden, die aber zusammen arbeiten und ein gemeinsames Interface haben. Zusammenarbeiten würden die Apps zum Beispiel, indem nach dem Start einer Rhythm-Napping-Session keine Aufgaben oder regulären RC-Erinnerungen mehr kommen. Die Schlafphasen-Erkennung kann auch als Wecker z.B. für WBTB fungieren und zum Aufwecken direkt Fragen zum Inhalt des Traums stellen. (Im Schlaflabor-Studien führt das zu besserer Traum-Erinnerung.) Die Länge und Anzahl aufgezeichneter Träume, die Antworten auf Tagesaufgaben und -Abfragen die Zuverlässigkeit der Reaktion auf RC-Erinnerungen können verwendet werden, um das individuelle Training (zukünftige Aufgaben und Fragen) zu beeinflussen. Die Schlafaufzeichnung/REM-Erkennung kann automatisch starten, wenn eine RN-Session gestartet wird. RN und Versuche, Singale in einen Traum zu senden, könnten automatisch in dazugehörenden Traumaufzeichnungen eingetragen werden. Und so weiter.

    Comment via email
    Thoughts on Haiku OS and GTK Entry Permalink Authors: steeph (367) Categories: #100DaysToOffload (41) Computer (77) Haiku (2) Operating Systems (23) Software (52) Thoughts (72) Languages used: en (254) edit

    I'm not sure I really like the fact that GTK has been ported to Haiku. Of course it's great when open source works that well and people put the work in to make something available for more people! For many more people than it has been before, Haiku has become a viable choice as their main desktop OS with Beta 4. Not too many apps are developed for Haiku natively and even the old BeOS apps, if you have one that you would still like to use, don't run on amd64. With GTK more useful apps became available.

    But Haiku is a low-resource and especially low-latency OS with defined goals of keeping this spirit alive. It does still run on 25 year-old and older PCs. The few applications that exist for #Haiku you can trust to be much more careful with using available resources than the average GTK application. I don't believe that Haiku will become as wild as Linux. The OS still is much smaller and will stay that way. But if more and more #GTK applications will become the standard solution for tasks, there will be less gaps to fill and less gaps will be filled by new, small, low-latency GUI applications.

    I'm not saying I don't like this development. I'm sure I'm going to make use of it. But I'm not sure I like it, too.

    Edit: There is a blog post with a very interesting discussion in the comments about this: Haiku isn’t a BeOS successor anymore by Thom Holwerda

    Comment via email
    Movies That Suddenly Change Genre After A While Entry Permalink Authors: steeph (370) Categories: Films (22) incomplete (22) Languages used: en (255) edit

    I think that there should be more films that change genre in the middle of their story.

    There are hardly any examples for movies that start out with one genre but suffenly change their tone entirely unexpectedly. At least once I would like to see a film that tells a family drama, then suddenly turns into a science fiction piece when somebody discovers a door into a parallel universe or something. Being John Malkovich comes close in a way. And that is part of why I like its weirdness. But it doesn't change it's mood, story telling style or subject matter at all at the time it gets weird.

    There is a difference between a movie that changes its genre in the middle and a movie you watch expecting a different genre from what it's actually in. But that can work to give you the same confusing surprise. For example when I watched Victoria (2015) for the first time without knowing anything about it, I expected a mellow love story between a big-city boy and a foreigner new in the city and country. Everything was pointing towards this being the story of the film. And it is. But it's embedded in a crime story with more action than I saw coming. This dichotomy shaped my viewing experience very much, making it a trip where enything could happen and many extreme and unexpected things did happen.

    I'll try to make a list of film that are actually split into two different genres. I don't know yet if I will find more than one.

    • Mickibo and Me (2005) - The lighthearted, childlike look at the political and social situation in of the young central characters' surrounding are what makes this story so nice to watch. Even as an adult who knows what's going on, it's easy to dismiss the anguish portrayed and focus on the adventue that the two kids are having. In the end the harsh reality comes too close to the story telling lead character to ignore it anymore. While I'd clearly classify the whole movie as a comedy, the sudden shift in tone for the tragic ending hits all the more and made me cry vewyond the closing credits.
    Comment via email
    Go To Navigation Page
    Show/Hide Navigation
    Mastodon