Grundlegende, erste Hinweise.
Hinweise zu bsh32.
Die bsh (oder bsh32) braucht gar nicht installiert zu werden!
Wer bsh.exe hat, muß diese nur aufrufen -sonst nichts- und bekommt ein Prompt.

Ich sage das, weil die geheimnisvolle 'Installation' der bsh vereinzelt als schier unüberwindlich geschildert wurde.
In Wirklichkeit ist die Angelegenheit total einfach - einfacher geht's kaum:

  • Dokumentationsbetrachter manw.exe:

    • Nur aufrufen - mehr nicht!
  • bsh.exe oder bsh32.exe:

    • Nur aufrufen - mehr nicht!
    Wo ist das Problem?!
  • bsh###.zip:

    • Nur den Entpacker aufrufen - sonst nichts!
    (Die .zip-Datei sollte dabei in einem dafür gewünschten Verzeichnis stehen.)
  • Außer den Hinweisen hier, die weiteren im bsh-Kasten ansehen.
  • Die bsh ist ein Kommandointerpreter, wie command.com oder cmd.exe von NT.

    • Unterschied:  die bsh kann viel mehr, hat viel mehr, und ist erheblich schneller.
    Wer den Dateinamen 'command.com' nicht kennt oder diese Programmart (Shell) nicht kennt,
    sollte die Finger von der bsh lassen - oder sich zuvor in die Shell-Thematik etwas einarbeiten.
    Zusätzliche Einrichtungen - falls gewünscht:
  • Das Dokumentations-System (man.exe, pg.exe, upat.exe)

    • hat mit der bsh.exe nichts zu tun, sondern ist vollkommen unabhängig!
    Wer es nutzen will, muß eine Umgebungsvariable  MANFILES=c:\verzeichnis
    anlegen, mit demjenigen Verzeichnis als Inhalt, wo die Doku-Dateien sich befinden.
    Das kann beispielsweise  c:\bsh\man  sein.
    Das Kommando  man.exe  muß nämlich wissen, wo die Doku-Dateien sind.
  • Benutzer von Unix-bsh können die Manual-doc/*-Dateien aus bshXXX.zip verwenden

    • und sie in eine geeignete Rubrik in  /usr/man/*  packen.
    Die vorhandenen DOS-Zeilenvorschübe dürften hier wohl kein Thema sein ...
  • Wer die diversen Kommandos von überall her in Kurzform aufrufen können möchte, muß entweder

    • die Kommandos in ein System-Verzeichnis (c:\dos;c:\windows;c:\winnt\system32;...) kopieren
    oder am besten den Inhalt der Umgebungs-Variablen  PATH oder Path  erweitern
    mit beispielsweise  ;c:\bsh\bin  , denn dort sollten die .exe-Dateien idealerweise sein und bleiben.
  • Wer  pg.exe  oder den internen Kommandozeilen-Editor der bsh (-E / set -E) nutzen möchte,

    • muß den Bildschirm-Treiber  ansi.sys  laden.
    Die folgende Zeile ist beispielsweise für WinNT:
    device=c:\winnt\system32\ansi.sys
    und kann in  c:\winnt\system32\config.nt  hinzugefügt werden.
    Achtung:  die Verzeichnisnamen können individuell anders lauten!
  • bsh32  hat allerdings einen internen ansi-Treiber.
    • Bekanntgewordene Anwender-Probleme:
  • Beendet wird die bsh durch  ^Z (Ctrl+Z), ^Break  oder  exit-Kommando.

    • Beim Schließen des Fensters bekommt bsh32 ein Signal (SIGBREAK) von Windows und beendet ebenfalls.
    Dies funktioniert unter Win-NT einwandfrei.
    Unter Win95/98 nur teilweise.  Die bsh32 hat dort dabei keine Gelegenheit, ihre temporären Dateien
    im TEMP=Verzeichnis zu löschen, weil sie kein SIGBREAK bekommt, sondern nur 'SIGKILL'.
  • Die bsh benutzt den Inhalt einer vorhandenen Umgebungs-Variablen  TEMP=L:\verzeichnis ,

    • um in diesem Verzeichnis ihre temporären Dateien anzulegen.
    Wenn dieses Verzeichnis nicht existiert, gibt es eine Fehlermeldung:
    bsh: Dateiöffnen fehlgeschlagen: 'L:\verzeichnis\bsh_tmpf.100'
    Es kann auch  BSHTEMP=...  angelegt werden, die dann vorrangig benutzt würde.
  • Interne Kommandos der bsh können natürlich nur innerhalb einer laufenden

    • bsh erreicht werden.
    Ganz genau so ist es mit den internen Kommandos von command.com und cmd.exe .
  • Ein Alias (alias-Kommando) ist innerhalb von Dateien und Shell-Funktionen  lokal !

    • Das global-Kommando zuvor verhindert das.  global  ist dort selbst lokal !
    Das liegt daran, daß die bsh als einzige Shell auch lokale Namen verarbeiten kann.
    Lokale Namen sind privat und von außen 'unsichtbar'.
  • Kommando-Beschreibungen erhält man durch Eingabe von  'man kommando'.

    • Das ist auch nicht viel anders als  'help kommando'  oder  'kommando /?'.
    Es sind natürlich viele interne Kommandos innerhalb von  'bsh(K)' (man K bsh)  versammelt.
    Das ist erkennbar in manw.exe und an den Dateien in ...\bsh\man .
    Der von 'man' verwendete Pager pg.exe kann viel:  beispielsweise Suchen mit Unix-Wildcards (/muster)
    und Weitersuchen mit 'N'.  Deshalb ist auch eine extra Datei für jedes Kommando nicht notwendig.
    bsh32.exe

    Diejenigen Zeichen, die Worte voneinander trennen, sind in der Variablen IFS gespeichert.
    Standardmäßig sind dies:  Leerzeichen,Tab,Wagenrücklauf,Zeilenvorschub:  " \t\r\n".

    In der bsh32 wurden die ersten beiden Zeichen miteinander ausgetauscht,
    um den Umgang mit langen Dateinamen, die ja Leerzeichen enthalten dürfen, zu erleichtern.

    bsh-intern wird manchmal nur das erste Zeichen in IFS benutzt, manchmal alle.

    Es gibt Fälle, da muß das Leerzeichen aus IFS vorübergehend entfernt werden: 

    ifs="$IFS"             # IFS="\t \r\n"
IFS="$( echo %t )"     # IFS="\t\r\n"
...
IFS="$ifs"             # IFS="\t \r\n"
    Das ist stellenweise leider unvermeidbar, wenn Leerzeichen in Dateinamen enthalten sein können!
    (Siehe nächsten Tabellen-Kasten.)
    Aus diesem Grund gibt es auf keinem Unix-System (angelieferte) Dateinamen mit Leerzeichen!
    Obwohl unter Unix fast alle 256 Zeichen erlaubt sind! - Ausnahme: nur '/' und '\0'.
    Mit Leerzeichen in Dateinamen handelt man sich letztlich nur Probleme und Unbequemlichkeiten ein;
    beispielsweise sind im Internet keine Leerzeichen erlaubt...
    Dateinamen mit Lücken darin sehen in Auflistungen auch optisch total bescheuert aus;
    der Unterstrich  _  ist ein viel besseres Trennmittel!

    Signale funktionieren bei bsh32 wesentlich besser als bei bsh.
    Mit ^C und ^Break kann man sicher abbrechen, mit Aufräumen zuvor.
    Nur unter Unix geht das noch besser.
    ^C wirkt eventuell verzögert, ^Break wirkt sofort.
    ^C und ^Z führen bei  bsh32 -P  nicht zum Abbruch.

    Windows (NT):
    bsh32 kann genauso eingerichtet werden wie die vorhandene DOS-Box mit cmd.exe
    oder command.com.
    Es kann ein Link hergestellt und konfiguriert werden,
    und die Dateiendung .bsh kann bsh32.exe zugeordnet werden.
    (Ein bsh-Icon ist in manw.exe enthalten.)
    In der normalen DOS-Box kann bsh ebenfalls -als SubShell- gestartet werden.

    NT-Desktop

    Die folgende Grafik stammt noch aus der Zeit als in bsh32.exe der interne Kommandozeilen-Editor
    noch nicht funktionierte, der in bsh.exe aber doch:

    Kommandozeilen-Editor

    Wie man sieht, habe ich hier bsh32.exe aufgerufen, und dann als SubShell
    bsh.exe (16Bit) aufgerufen.
    Es ist erkennbar, daß jede Ausgabe der bsh.exe (jedes 16Bit-Programmes) schwarz/weiß ist,
    und auch mit bsh.exe funktioniert der Kommandozeilen-Editor einwandfrei!

    Windows NT erzeugt also automatisch eine jeweils andere Umgebung und Verknüpfung.
    Das Menü 'Eigenschaften' sieht bei 16Bit- und 32Bit-Programmen auch unterschiedlich aus.
    Bei 32Bit kann man z.B. einen NT-internen 'doskey' (Befehlspuffer) einstellen, bei 16Bit nicht.
    Bei bsh32 hat man also eine doskey-Funktion, ohne 'set -E'.

    Bei Aufruf von command.com sind darin die Ausgaben schwarz/weiß,
    beispielsweise wenn man 'set' aufruft.
    Jedoch bei 'dir' ist das Listing farbig und stammt offensichtlich vom cmd.exe-internen 'dir'!,
    obwohl man ja innerhalb von command.com steht!
    Allerdings bei Aufruf von  command.com /c dir  innerhalb von command.com
    gibt es ein schwarz/weiß-Listing des alten DOS-dir ohne lange Dateinamen!?
    Das ist schon etwas seltsam...
    (doskey kann zwar so (kommando-zugeordnet) konfiguriert werden, jedoch ist doskey
     offenbar nicht aktiv innerhalb von command.com.)

    bsh32 hat viele Vorteile gegenüber bsh.
    Beispielsweise darf die Kommandozeile etwa 256000 Byte lang sein, mit etwa 16000 Argumenten,
    und die Shell-Variablen können insgesamt etwa 32000 Byte fassen !!!
    bsh:  4000 Byte / 1020 Args / 5100 Byte
    DOS:  127 Byte / - / -
     
    Trennzeichen bei der Wortbildung

    Die bsh bewertet die Zeichen in IFS als Trennzeichen, um aus beliebigen Zeichenketten Worte zu bilden.
    Ob es sich dabei um Dateinamen oder andere Worte handelt, weiß die Shell nicht.

    Annahme:
    Im aktuellen Verzeichnis sind drei Dateien:

    aaaaaa
    bbb   BBB
    cccccc


    Die Schleife

    for datei  in  *
    do  echo "--$datei--";  done
    ergibt:
    --aaaaaa--
    --bbb   BBB--
    --cccccc--
    Das ist korrekt, weil der Wildcard-Mechanismus selbst IFS nicht benutzt.

    Auch folgendes ist korrekt:

    dateien=*
    echo  --$dateien--
    --aaaaaa bbb BBB cccccc--
    echo "--$dateien--"
    --aaaaaa        bbb   BBB        cccccc--
    Bei der Zuweisung wurden also die drei Argumente durch TABs getrennt:
    aaaaaa\tbbb   BBB\tcccccc


    Ein eleganter Trick: 

    namen='aaa  bbb,ccc    ddd,eee'
    for n  in  $(ifs="$IFS";IFS=,)  $namen  $(IFS="$ifs")
do
   echo "--$n--"
done
    --aaa  bbb--
--ccc    ddd--
--eee--
    Hier wurden Zuweisungen in Kommando-Substitutionen gepackt, die als Argument keine Wirkung
    haben, weil Zuweisungen nichts ausgeben, und weil ohne Maskierung "...".
    Die vorübergehende Änderung von IFS wirkt hier nur auf  '$namen' .

    Ein Problem gibt es aber hier:

    for d  in  $dateien
    do  echo "--$d--";  done
    --aaaaaa--
    --bbb--
    --BBB--
    --cccccc--
    Hier wird der Ausdruck '$dateien' (da er unmaskiert ist/sein muß) gemäß dem Inhalt von IFS
    in Worte zerteilt.
    Dies Problem kann aber auf vielfältige Weise gelöst werden:
    1. Indem IFS geändert wird, wie oben gezeigt.
    2. Ein Konzept mit  readl zeile  verwenden.
    3. readl datei  statt  read datei  verwenden.

      4. Die Parser-Fähigkeit von read kann nur verwendet werden
      durch Anpassung von IFS und ggf. Eingabe von TABs als Trenner.
    4. In Variablen alle Leerzeichen zeitweise durch einen Platzhalter ersetzen,

      5. mit dem Kommando  conv .
      Platzhalter=$( echo %01%c )
      Die bsh verarbeitet alle Platzhalter von dezimal 1 bis 255.
    5. Alle Leerzeichen zeitweise durch einen Platzhalter ersetzen,

      6. mit dem Kommando  tr .
    6. Auch den Script-Sprachen-Lehrgang im bsh-Kasten beachten...
    Eine generelle Weglassung des Leerzeichens als Trennzeichen von vornherein
    wäre zu problematisch,
    denn Dateinamen sind ja nur eine Wortart von vielen!
    Unter Unix funktioniert -natürlich- der unveränderte Kommandozeilen-Editor der bsh
    auch unter X-Windows in der UNIX-Box:
    Das unten zu sehende spezielle Prompt kann nur angewandt werden, wenn eine Funktion
    für Escape-Sequenzen im Ausgabetreiber vorhanden ist - für Win32-Programme fehlt dies im Console-System!

    Unix-Box

    Das ist auch ein Kennzeichen dafür, daß ich seit etwa 1995 einen gewissen Groll gegen Microsoft hege.
    Die grafischen Oberflächen von Microsoft sind detaillierter und im Detail perfekt(er) ausgestaltet,
    jedoch unter Unix sind die Konzepte besser, klarer, offener, größer, souveräner, - nicht so verwuselt.

    Ich hatte mir nämlich nach MS-DOS 6.22 ein MS-DOS32 1.0 gewünscht, und ...

    Zur Hauptseite