GEMini Atari

home *** CD-ROM | disk | FTP | other *** search

/ GEMini Atari / GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso / files / language / lambdoc / atari.man next >

Wrap

Text File | 1989-03-15 | 35.2 KB | 801 lines

************************************************************************** [LAMBDA].1.38a.ATARI.ST [890309][\man\atari.man]: ATARI.ST Technical Notes ************************************************************************** -------------------------------------------------------------------------- [LAMBDA.TN.000].ATARI.ST.[1.37][890226] BOOTing LAMBDA, SHELL alternatives -------------------------------------------------------------------------- 0 CURRENT VERSION: LAMBDA.ATARI.ST [1.39a][890311][CC: SOZOBON <1.01: 1988>][LIBC: dLibs 1.2] 1 INTRODUCTION. LAMBDA is a lambda-calculus/combinatory-logic interpreter and combinatory- code generator. The present version [ATARI.ST][1.3X] of LAMBDA has a built- in line-editor [EDIT: derived from Ken Thompson's ED] and an internal shell [META], incorporating a minimal number of TOS-supported commands/functions. General information about ["type-free"] lambda-calculi and combinators can be recovered from the bibliography listed in the LAMBDA REFERENCE MANUAL [see: \man\lambda.man]. Roughly speaking, lambda-calculus is a theoretical tool/formalism equivalent to a Turing machine, as regards its definability power. In practice, lambda- calculus techniques have been also used, during the last ten years, in compiler-design for several functional programming languages, in automated reasoning [design of proof-assistants and proof-checkers] and in expert systems [proof-pattern recognition]. In a sense, the lambda-calculus is at the root of the modern computability theory and of our computing engines, whether ALGOLoidal or not [= merely FUNCtional]. As a mere theoretical tool, it has also a certain MUSEAL value, whence the idea to put it in the same environment with another master-piece of computer art: Ken Thompson's ED [the root of the UN*X-like editors and pattern-matching tools]. 1 CONTENTS. The present archive contains the last ATARI.ST version of the binary, general LAMBDA-documentation [default in: \man\lambda.man], a list of system-specific features [LAMBDA.ATARI.ST: Technical Notes; default edited in: \man\atari.man], applying to this implementation and, optionally, a public domain Bourne-like SHELL [if present, either \bin\gsh.prg or else ARChived in: \etc\pd_shell]. NOTE: MACintosh [MFS], MSDOS, UN*X [BSD] as well as UN*X-like [e. g. MINIX] variants of the present implementation are also available. 2 THE PUBLIC DOMAIN SHELL. The SHELL interpreter [if present, in: \bin] and the corresponding documentation [if present, in: \doc] are identified as: BIN: GSH.PRG = GULAM, by Prabhaker Mateti, BETA-test: 1.03.04.05. NB: The binary is patched according to a procedure described in the [GSH] DIGEST in order to fit the ATARI.ST UK-KEYBOARD settings. Archived is also the original US-KEYBOARD variant, as posted on the [UUNET].NEWS [last: January 1989]. MAN: A REFERENCE MANUAL FOR GULAM (c) 1987 Prabhaker Mateti, DOC: [GSH] PROFILES: sample initialization scripts for GULAM, DOC: [GSH] DIGEST: [UUNET].NEWS discussions [1987-88] around GULAM. Both LAMBDA and the SHELL are stand-alone programs. Other Bourne-like SHELLs can be used in conjunction with LAMBDA [see: section 5 below]. NOTE: Since the SHELL interpreter identified here as GSH.PRG, as well as the appended SHELL documenation have been posted several times already on the [UUNET].NEWS.[comp.binaries.atari.st], the LAMBDA-package archived here may NOT contain the SHELL. The ATARI.ST version of LAMBDA identifies a SHELL according to specific internal conventions ["shell-types"], as described below. Several [non- public domain] software-alternatives are listed later in these notes. 3 BOOTING LAMBDA: THE "PRIVATE" ENVIRONMENT. BOOTing LAMBDA is a system-specific operation. Described here are only the ATARI.ST modes. (This applies to any ATARI.ST [MEGA] configuration.) While BOOTing it on ATARI.ST, LAMBDA initializes a "private" environment consisting of the following variables (below, a <drive>-id is as identified by TOS; it can be a physical volume, a ram-disk, a hard-disk partition, etc.): $HOME = {home-drive:} = HOME- [and/or BOOT-]drive id for LAMBDA, NB: if any, the $SHELL is also located on $HOME $BIN = {bin-drive:}\bin\ = directory of executables accessible from LAMBDA NB: by default, the system $EDITOR is located on $BIN $LIB = {lib-drive:}\lib\ = directory for various libraries, default location for the alternate font-files $LIB\<font-name>.fnt [must be FED-format] $TMP = {tmp-drive:}\tmp\ = directory for temporary files, NB: used only by LAMBDA's built-in EDITor $SHELL = {home-drive:}\bin\<shell-type>sh.prg NB: <shell-type> ranges over {a,b,c,g,m,s} $EDITOR = {bin-drive:}\bin\ed.prg = system editor NB: this can be anything, within reason, if you don't like LAMBDA's built-in EDITor. In order to have full compatibility with the different "environment styles" supported by the ATARI.ST machines, these "environmental" variables are NEVER EXPORTED. Communication with the environment of the external SHELL must be insured separately, by customizing as appropriate the current SHELL's initialization script (running examples for several popular ATARI.ST shell interpreters are also included in the archive). LAMBDA recognizes its [physical or environmental] BOOT-location and, if no other action is taken, it initializes, by default, the internal environmental variables to the appropriate locations on $BOOT. EXAMPLES: (1) if LAMBDA is started from the DESKTOP, on internal disk a: [with an ATARI 1040ST], the following configuration is set: home-drive = bin-drive = lib-drive = tmp-drive = $BOOT = a: $BIN = a:\bin\ $LIB = a:\lib\ $TMP = a:\tmp\ $SHELL = a:\bin\<default-shell-type>sh.prg $EDITOR = a:\bin\ed.prg (2) if started from a SHELL, $BOOT becomes the SHELL's actual $cwd-drive, no matter where is the SHELL located physically. The BOOT-configuration can be altered in several ways, by calling LAMBDA [or LAMBDA.TTP, as a DESKTOP program] with the appropriate option and/or even at run-time (from the internal shell [META]). The corresponding alteration flags are UN*X-like and the LAMBDA-options affecting the drive-specifications, etc. are described below [as part of: LAMBDA.ATARI.ST Technical Notes]. -------------------------------------------------------------------------- [LAMBDA.TN.001].ATARI.ST.[1.37][890226][Technical Note 001] LAMBDA-options -------------------------------------------------------------------------- 4. BOOTING LAMBDA WITH OPTIONS: lambda {, -bcefhilpstx<modifier> } [0] The LAMBDA-options follow, in general, the UN*X option pattern: format: -[lower-case-letter][upper-case-letter]<modifier> For [TOS-only]: upper-case option/modifier specifications are also allowed in order to accommodate the DESKTOP TTP-style calls. defaults: [DEFAULT][DEFAULT-ON-FAILURE] - if not specified explicitly, the <modifier> has a [DEFAULT] - outside its legal range, a <modifier> has a [DEFAULT-ON-FAILURE] [1] DRIVE-id specifications [TOS only]: options -behltx<drive>. Following TOS, a legal <drive>-id ranges over [a-p][A-P]: - an illegal specification restores the [DEFAULT-ON-FAILURE], - if the modifier <drive> is absent, the [DEFAULT] is restored. On BOOTing LAMBDA, the default-drive configuration is as follows: - the OLD-DRIVE id = [DEFAULT-ON-FAILURE] is set to [a:] and - the CURRENT-DRIVE id = [DEFAULT] is read off from the environment. The LAMBDA-options -behltx<drive> alter the default setting to <drive>. The -bh<drive> setting can be also altered interactively from [META]: [meta][path: <drive>], [meta][home: <drive>]. For the [MSDOS]-style, see the [LAMBDA.MSDOS Technical Notes]. [2] SHELL-type specification [TOS-only]: options -s[S]<shell-type> A legal <shell-type>-id ranges over {a,b,c,g,m,s,A,B,C,G,M,S} - an illegal specification restores the [DEFAULT] = [DEFAULT-ON-FAILURE], - if the <shell-type> specification is absent, the [DEFAULT] is restored. On BOOTing LAMBDA, the default <shell-type> is as follows: - BOOTing from DESKTOP: default <shell-type> = [m] - BOOTing from a SHELL [the <shell-type> [g] is recognized internally]: IF the SHELL has <shell-type> [g] THEN the default <shell-type> = [g] ELSE the default <shell-type> = [m]. This setting can be also altered interactively from [META]: [meta][sys: <shell-type>][sh+]. [3] PROMPT-type specifications: options -p[P]<prompt-number> DEFAULT-PROMPTs [TOS-only]: MAIN [>], META [!], EDIT [>] NB: The SHELL has PROMPT as set by the shell initialization sequence. NB: [TOS-only]: Only the PROMPT of the [MAIN] interpreter is altered. [4] Most LAMBDA-options are system-dependent and agree, in general, with the following compiler #ifdef-alternatives: - [BSD]: UN*X BSD and MAC [HFS-only] versions - [GEM]: ATARI.ST and MSDOS versions supporting GEM - [MAC]: MACintosh [MFS-only] versions - [MINIX]: MINIX versions [supported by PCs and/or ATARI.ST] - [MSDOS]: PC [MSDOS-only] versions - [RESERVED]: versions supporting a GRAPHICS SHELL [NO GEM] - [TOS]: ATARI.ST [TOS-only] versions -b[B]<drive> [TOS][MSDOS] Define BIN- [and EDITOR-] drive/volume default: CURRENT-DRIVE default on failure: OLD-DRIVE -c[C] [RESERVED][BSD][MINIX] Switch OFF the [META]-interactive setting Read BOOT-environment from <LAMBDA.LOG>-script on start. defaults: [OFF][IGNORE][READ-LAMBDA-OPTIONS] -e[E]<drive> [TOS][MSDOS] Define system-EDITOR-drive/volume default: CURRENT-DRIVE default on failure: OLD-DRIVE [TOS]: default system-EDITOR: ed.prg -f[F] [RESERVED][MSDOS][TOS-variant] Set MSDOS environment-style ON default: OFF -h[H]<drive> [TOS][MSDOS] Set HOME- [and SHELL-] drive/volume default: CURRENT-DRIVE default on failure: OLD-DRIVE -i[I] [TOS] Switch ON the [META]-interactive setting: <next-command> is passed on to [MAIN] <next-command> + 1 is passed on to [META] default: OFF -l[L]<drive> [TOS][MSDOS] Define LIB- [and FONTs-] drive/volume default: CURRENT-DRIVE default on failure: OLD-DRIVE [TOS] default FONT-format .FED: <font-name>.fnt -p[P]<prompt-number> [BSD][TOS][MSDOS][MAC] Define LAMBDA-prompt character <prompt-number>: 0: [EMPTY][SPACE] 1: [_][UNDERSCORE] 2: [:] 3: [#] 4: [$] 5: [%] 6: [~] 7: [EMPTY][BELL] 8: [>] 9: [DEFAULT-PROMPT] default: [DEFAULT]-PROMPT default on failure: [DEFAULT]-PROMPT -r[R] [RESERVED][GEM] Re-shell on exit with <current-shell-type> default: [IGNORE] -r[R]<new-shell-type> [RESERVED][GEM] Re-shell on exit with <new-shell-type> default on failure: <current-shell-type> -s[S]<shell-type> [BSD][TOS][MSDOS] Define <shell-type>: [a][b][c][g][m][s] default [on failure]: [m] or [g] [TOS]: default shells: msh.prg, gsh.prg [TOS]: default shell-location $HOME\bin. -t[T] [TOS][MSDOS] Define TMP-drive/volume default: CURRENT-DRIVE default on failure: OLD-DRIVE -x[X] [TOS][MSDOS] Define BOOT-drive/volume as OLD-DRIVE default: CURRENT-DRIVE -x[X]<drive> [TOS][MSDOS] Define BOOT-drive/volume as <drive> default: CURRENT-DRIVE default on failure: OLD-DRIVE [5] Conflicting flags. In cases where the supplied optional flag-list leads to conflicting actions, the flag last specified overrides the options already set by previous flags. 5 BOOTING LAMBDA: THE EXTERNAL SHELL[-TYPE]S. If used in conjunction with a SHELL, LAMBDA has a SHELL-MODE, activated by the command [sh+], in order to pass user commands to the surrounding shell. In short, in SHELL-MODE, any command-line that is not directly interpretable in LAMBDA and/or in its internal shell [META] is passed on as such to the current SHELL. The SHELL-MODE can be de-activated with [META]-command [sh-]. LAMBDA uses the following internal setting in order to recognize calling conventions of external SHELLs. Exact specifications for the different call-types are given elsewhere in the [LAMBDA.ATARI.ST Technical Notes]. Here only some actual [software-] products, fitting the call-types built in LAMBDA are mentioned. This list is, certainly, not exhaustive. ___________________________________________________________________________ | <shell-type>: <name>: <call-type>: actual program: [origin] <id> | |-------------------------------------------------------------------------| |[m] "MY-SHELL" msh.prg external [Mark Williams] MSH [2.01-3.0+] | | msh.prg external [G. Poletiek] GPsh [Craft 2.02] | | msh.prg external [D. Beckemeyer] The Micro C-shell | |[g] "GULAM-type" gsh.prg internal [P. Mateti][PD] GULAM 1.03.04.05 | |[b] "BOURNE-type" bsh.prg external [D. Beckemeyer] The Micro C-shell | | bsh.prg external [Mark Williams] MSH [2.01-3.0+] | |[c] "C-SHELL-type" csh.prg external [D. Beckemeyer] CSH [multitasking]| |[s] "SYSTEM-type" ssh.prg internal [G. Poletiek] GPsh [Craft 2.02] | |[a] "ATARI-type" ash.prg external [J. Nowlin][PD] ASH [1986-1987]] | |_________________________________________________________________________| Here, the shell's <name> is part of the internal conventions used by LAMBDA to identify the current <shell-type>. In order to be able to use optimally the external shell interpreter in conjunction with LAMBDA, actual programs fitting the specified <call-type> must be renamed accordingly. Other [possibly new] software alternatives should be first tested as if having the "universal" (and most robust) <shell-type> [m] and/or [b]. The first two listed <shell-type>s [m], [g] are defaults. The explanation for the use of TWO actual defaults is as follows: Shells of type [g] are recognized internally. So, the <shell-type> [g] is the default-shell only if LAMBDA is actually called from [a program initialized by] a shell of type [g]. In particular, a "stack of calls" containing a "caller of type [g]" will be always recognized by LAMBDA as a shell of type [g] (try the sequences: [Xsh][gsh][lambda] and/or [gsh][Xsh][lambda] with [Xsh] being any other shell-interpreter...) Any other <shell-type> is recognized externally; that is: the user must specify explicitly the current "external" <shell-type> in order to be able to use properly a system-call via LAMBDA. So, if the shell is not recognized at "boot-time", the default <shell-type> should be [m]. Somewhat metaphorically, the [ATARI] DESKTOP is also a shell of type [m], since a limited number of system-commands can be also executed directly, via [META] [= the internal shell of LAMBDA]. If the call-type is "external", a new copy of the [external] shell is executed [with -i and/or -c flag], while calling the shell. An "internal" call-type uses the TOS [system] variable `_shell_p' in order to access the actual shell-interpreter. In most cases, there is no need for a new incarantion of the shell, in order to execute a command via an "internal" call. NOTE. In the case of `gulam', the call-type is also "internal" in a slightly different sense: while executing a shell-command via `gulam' and - often - while calling `gulam' directly, LAMBDA uses actually `gulam'-routines from the currently running copy of the shell. This means that a new copy of `gulam' is executed only in exceptional circumstances. This implementation technique has been motivated by the fact that `gulam' uses a special [dynamic] memory-allocation strategy, incompatible with several LAMBDA-triggered processes. Whenever using LAMBDA in conjunction with `gulam', the user should keep in mind that the latter is not to be considered as a usual TOS program and should rather avoid direct TOS-calls to it (by [EXEC] or [exec], say). NOTE. Typically, a RETURN-FROM-[CURRENT]-GULAM-TO-LAMBDA is obtained by typing an empty command-line [CARRIAGE RETURN], whereas a RETURN- FROM-[A-NEW-COPY-OF]-GULAM is obtained, as in the case of almost any other ATARI.ST shell-interpreter, by typing explicitly [exit]. 6 THE INTERNAL LAMBDA-SHELL: [META]. A limited number of system-specific commands are interpreted by the internal shell of LAMBDA: [META]. If somewhat metaphorically, the LAMBDA- user may think of [META] as being just "another room" within LAMBDA. In fact, the built-in editor [EDIT] is already "yet another LAMBDA-room". The LAMBDA-command [meta] forces an explicit EXIT-TO-META. Alternatively, the LAMBDA-option -i allows the user to execute a single LAMBDA-[MAIN]- specific command before EXITing-TO-META. From [META], we can re-boot LAMBDA by [boot], discarding trailing in-core term libraries, we can execute a new copy of LAMBDA with <new-options>, by asking [alter] <new-options> and we may call explicitly an external SHELL, if any, in several distinct ways. The [MAIN]-interpreter allows only two distinct escapes to an external SHELL: via a system-shell-call or via a TOS-Pexec-call. The [META]-choice is somewhat larger, by passing on the ENVironment inherited by LAMBDA to the child process. A SHELL that is able to remember its original caller [= "where it comes from"] will accurately distinguish among different types of escape from [META] (try, e. g., [set] with the Mark Williams shell, inspecting the SHELL-variable `camefrom'). Such variants are useful if the current memory-management looks suspect. [META] understands and executes at least the following UN*X-like commands [ignoring the standard UN*X options]: [cd <path>], [date], [du], [ls], [mkdir <path>], [pwd], [rmdir <path>]. On an ATARI.ST, the LAMBDA-[META]- command [mem] shows the memory currently available to the user; a would-be equivalent of the multi-user [quota], on UN*X systems. Note also that the UN*X-like commands [cat <file-name>] and [rm <file-name>] are active only via the [MAIN]-interpreter, although they are actually triggered by [META]. Identically labelled [META]-commands have precedence over external SHELL commands. For instance, [ls] is executed by TOS via [META], and not by the external SHELL, unless we use an explicit [META]-escape to the later. Any other TOS-program <program-name>.tos, any TOS-program with <options>: <program-name>.ttp <options>, <program-name>.prg <options>, as well as most GEM-programs can be called from LAMBDA, via its [META]-interpreter-part, either from the [MAIN]-"room" or from the [META]-"room" of LAMBDA. The [EDIT]-"room" allows a similar SHELL-escape and a limited number of [META]-specific commands (try single-key H for [help] within the built-in EDITor). For details, see the appropriate [LAMBDA.ATARI.ST Technical Notes], below. --------------------------------------------------------------------------- [LAMBDA.TN.002].ATARI.ST.[1.37][890228][Technical Note 002] System commands --------------------------------------------------------------------------- 7. LAMBDA.ATARI.ST [TOS] SYSTEM/SHELL SUPPORTED COMMANDS. WARNING: The [MAIN][META] system/shell commands are case-sensitive. alter <new-options>: [META] boot a new copy of LAMBDA with <new-options>, externally DIAGNOSTICS: executes a new copy of LAMBDA, in the [META]-environment specified by the <new-options>, returns to current [META] on exit; it assumes that enough memory is available in order to keep the new copy of LAMBDA in core black: [MAIN][META] set black-on-white fore/background [XOR current fore/background] DIAGNOSTICS: [black-on-white] is set if starting from [white-on-black] boot: [META] re-boot a new copy of LAMBDA, internally DIAGNOSTICS: this is a actually a simulation; in fact, the old copy is used, in the same [META]-environment, although the command-history counter is reset and the current core term-library is deleted cat <file-name>: [MAIN] view/visit <file-name> DIAGNOSTICS: expects interactive response on paging (see the SINGLE-KEY sub-menu); as a general rule, the interactive mode can be disabled by [talk-]; the paging is done according to the current screen-display setting: graphics-display is used only if graphics-mode is set explicitly by [graphics+]; here, the <file-name> must either refer to an ASCII file located in the current working directory or else be a full path specification according to the TOS conventions; in particular, the wildcard `*' is accepted as a word-part of <file-name>, although it will match only a single item (the one first encountered) [SINGLE-KEY sub-menu]: B[b] = BACK TO TOP of <file-name> e[E] = EDIT <file-name> with built-in editor Q[Q] = QUIT VIEWing <file-name> <other key> = SHOW NEXT page of <file-name> in interactive mode, this function (and the SINGLE-KEY sub-menu) is also available from the built-in EDITor as [V <file-name>] cd <directory-path>: [MAIN][META] change/set current working directory path to <directory-path> DIAGNOSTICS: changing the current directory accross volumes is a licit operation cd [without-argument] = cd $HOME (internal [META]-environment) cd <drive-name>: = cd <drive-name>:\<last-visited-sub-directory> cd {drive-name:}\ = set cwd to (the root of) {drive-name:}\ cls: [MAIN][META] clear screen and home cursor cursor[+][-]: [MAIN][META] enable | disable cursor date: [MAIN][META] show system date and time DIAGNOSTICS: CST is considered only, local time is ignored; if the system [TOS] time is not reasonably set, some historically memorable date is printed; the IKBD-time is also ignored du: [MAIN][META] show disk usage for disk holding the current working directory DIAGNOSTICS: the free space displayed is measured in bytes/sectors; the total space [and the current cluster size on the inspected volume] is also shown ed {<options>} <file-name>: [MAIN][META] call the system-editor {current-bin-drive}:\bin\ed.prg in order to edit the <file-name> with <options> DIAGNOSTICS: the calling routine assumes that the command line <options> <file-name> is parsed as appropriate by the editor; the system editor [ed.prg] can be any TOS/GEM editor with a reasonable TOS interface; recommended pd/ commercial programs to this purpose: any `micro-Emacs' (for instance, the GNU micro-Emacs), `stedi.prg', `tempus.prg', etc.; most [ATARI.ST] text-processors should also do the job env: [META] print current [internal] [META]-environment DIAGNOSTICS: shows the contents of $HOME, $BIN, $LIB, $TMP, $SHELL and $EDITOR [none of these are exported to external programs] EXEC <program-absolute-path> {<options>}: [MAIN][META] execute <program-absolute-path>.prg {<options>} DIAGNOSTICS: the <program-absolute-path> is taken modulo the current working directory, although an absolute path-specification of the kind {drive:}\<program-path> is always recognized as such exec <program-name> {<options>}: [MAIN][META] execute {current-bin-drive:}\bin\<program-name>.prg {<options>} exit: [MAIN][META] [MAIN]: exit [MAIN] [= current LAMBDA] to immediate parent process [META]: exit [META] to remote parent process font <font-name>: [MAIN][META] load a new font-set from {current-lib-drive:}\lib\<font-name>.fnt DIAGNOSTICS: this is an experimental feature: it calls an external font-loader {current-bin-drive:}\bin\ldfont.prg to load a new font set from {current-lib-drive:}\lib\<font-name>.fnt; the default fonts are restored before loading the new set; graphics-mode is switched off, if necessary NOTE: The pd font-loader supplied with the LAMBDA-package assumes that the {current-lib-drive:}\lib\<font-name>.fnt is in FED-format. Apparently, it uses directly the TOS `Malloc()'; as a consequence, it will almost always cause memory fragmentation, conflicting with processes that allocate memory dynamically (as, e. g., [edit]). This kind of problem can be circumvented by loading the new font-file from a different copy of LAMBDA or from a copy of the current SHELL that has not been invoked by the current LAMBDA. graphics[+][-]: [MAIN][META] enable | disable graphics display mode DIAGNOSTICS: the graphics-mode affects directly the built-in paging routines, although the latter are unable to recognize the graphics-mode if this has not been set explicitly by [graphics+] help: [MAIN][interactive][META] [MAIN]: displays the [MAIN] interpreter's help-page and, in [talk+]- mode, a full list of LOCAL commands currently available [META]: displays the [META] help-page [= a list of specific commands available via the internal shell] DIAGNOSTICS: in [MAIN][talk+][graphics-]-mode, expects interactive response on paging (since there are two pages to look up) home: [META][interactive] set new current $HOME-drive: [a-p][A-P] DIAGNOSTICS: expects interactive response; as usual, this is disabled by [talk-] install: [META] generates the current [BOOT] directory-structure as specified by the [internal] [META]-environment, if necessary DIAGNOSTICS: reads the contents of $HOME, $BIN, $LIB, $TMP [none of these are exported to external programs] and makes the appropriate directories [if not already present], locating the $SHELL and the $EDITOR leave: [META] exit silently [META] to the immediate parent process [no return-value] local: [MAIN][META] displays the list of LOCAL [ATARI.ST] commands currently available ls: [MAIN][META] [long] list contents of current working directory DIAGNOSTICS: identifies sub-directories and displays file-length statistics, no date/time stamp; the directory listing is as seen by TOS; whenever applicable [system][hidden][read-only][written-to]-modes are also reported mem: [MAIN][META] show the [largest chunk of] free memory currently available DIAGNOSTICS: with shell-type [g], shows also the free list of all such chuncks and the corresponding "owners" meta: [MAIN] escape to the internal shell [META] DIAGNOSTICS: specific [MAIN]-commands are disabled; specific [META]-commands are enabled; LOCAL commands available in [MAIN] are retained metashell: [META] TOS-escape to the current shell, in [META]-environment DIAGNOSTICS: `Pexec()'-call to the current shell, in [META]-environment, according to the internal conventions concerning shell-types NOTE: The [META]-environment has a "private" segment (the one that can be inspected by [meta][env]) which is never exported. This type of call will only pass the external environment, as inherited by [META] on BOOT, to the current shell, without inserting this "private" segment. For shell-type [g], this is an internal call, using the same copy of the current shell. mkdir <directory-path>: [MAIN][META] make new <directory-path> DIAGNOSTICS: the <directory-path> is taken modulo cwd; mkdir assumes that all intermediate nodes exist path: [META][interactive] set new current $PATH-drive: [a-p][A-P] DIAGNOSTICS: expects interactive response; as usual, this is disabled by [talk-] quit: [META] exit META to the immediate parent process with return-value rm <file-name>: [MAIN] delete [= unlink] <file-name> rmdir <directory-path>: [MAIN][META] remove <directory-path> DIAGNOSTICS: the <directory-path> is taken modulo cwd; rmdir assumes that all intermediate nodes exist sh[+][-]: [MAIN][META] activate | deactivate the current shell DIAGNOSTICS: the open-mode triggered by [sh+] is echoed only in [MAIN] interactive mode, as set by [talk+] shell: [META] TOS-escape to the current shell, in [NULL]-environment DIAGNOSTICS: `Pexec()'-call to the current shell, in [NULL]-environment, according to the internal conventions concerning shell-types; an equivalent escape is: !! NOTE: For shell-type [g], this is an internal call (using the same copy of the current shell). sound[+][-]: [MAIN][META] enable | disable sound bell sys: [META][interactive] change the current shell-type: { a, b, c, g, m, s } DIAGNOSTICS: expects interactive response; as usual, this is disabled by [talk-]; there is no need to set explicitly the shell-type [g] (the "internal" default); also, the shell-type [g] cannot be altered if a shell of type [g] is actually present in the environment WARNING: Lying to [META], with [sys <shell-type>], is harmless only for the "external" shell-types [a][b][c][m], in which case, renaming the current shell to the "external" default [msh.prg] would sometimes work, although not exactly as specified elsewhere in the [Technical Notes]. talk[+][-]: [MAIN][META] enable | disable interactive mode DIAGNOSTICS: controls also the verbosity of [MAIN][META] error reports and the auto-numbering of the [MAIN] command-history NOTE: Actually, these are not pure "system"-commands (for details see the REFERENCE MANUAL), although they affect the status of those system commands that require interactive response. In particular, the [talk-]-mode [= non-interactive] will also switch off the TOS error reporting for most processes triggered by [META]. TOS <program-absolute-path>: [MAIN][META] execute <program-absolute-path>.tos DIAGNOSTICS: the <program-absolute-path> is taken modulo the current working directory; an absolute path-specification {drive:}\<program-path> is always recognized tos <program-name>: [MAIN][META] execute {current-bin-drive:}\bin\<program-name>.tos TTP <program-absolute-path> {<options>}: [MAIN][META] execute <program-absolute-path>.ttp {<options>} DIAGNOSTICS: the <program-absolute-path> is taken modulo the current working directory; absolute specifications {drive:}\<program-path> are always recognized ttp <program-name> {<options>}: [MAIN][META] execute {current-bin-drive:}\bin\<program-name>.ttp {<options>} version: [MAIN][META] print the current version of the LAMBDA-interpeter white: [MAIN][META] set white-on-black fore/background [XOR current fore/background] DIAGNOSTICS: [white-on-black] is set if starting from [black-on-white] !: [MAIN][META] SYSTEM-escape to the current shell DIAGNOSTICS: pending memory available, executes a `system()'-call to the current shell, according to the internal conventions concerning shell-types NOTE: For shell-type [g], the action of the !-escape is differentiated as follows: (1) [MAIN]: internal call (using the same copy of the shell), (2) [META]: proper system-call (re-initializing a new shell). !!: [MAIN][META] TOS-escape to the current shell, in [NULL]-environment DIAGNOSTICS: `Pexec()'-call to the current shell, in [NULL]-environment, according to the internal conventions concerning shell-types NOTE: For shell-type [g], this is an internal call (using the same copy of the current shell). <any-other-string-sequence>: [MAIN][META] in [sh+]-mode: as interpreted by the current shell, if any DIAGNOSTICS: assumes that a minimal environment consisting of: <shell-type>, actual shell-location, actual location of binaries, font-library location, etc. has been correctly set and that the current shell knows about this "private" [META]-environment; the latter kind of information can be passed on via the shell's initialization script; typical echoes on failure: `?', `No shell', a [TOS] error report, etc. 8 ACKNOWLEDGEMENTS. I am indebted to Willem L. van der Poel and to his former associates at the University of Technology in Delft [The Netherlands] for the general ideas underlying the present implementation(s). Corrado Boehm [Universita di Roma, Italy] and some of his students have contributed with numerous suggestions of improvement, concerning the kernel LAMBDA-interpreter [MAIN] (especially in its MACintosh variant). The [ATARI.ST] implementation has made copious use of the excellent public domain C-library of Dale Schumacher (i. e. the LIBC called "dLibs 1.2"). The main development work on LAMBDA has been done on a VAX 750 cum BSD 4.2, whereas the specific ATARI.ST enhancements have been obtained by using valuable [if somewhat rival] C-tools signed (c) and/or derived from (c) material released by the Mark Williams Comp., Microsoft and Borland International. 9 MAIL. Since we a living in a [perpetually] changing environment, some of the e-mail boxes/paths below may not be actual. On failure, try the postal address: the reliability of the Dutch postal services has significantly increased by the recent privatization [January 1, 1989]... Adrian Rezus: Meyhorst 91-01, 6537 KJ Nijmegen, The Netherlands. adriaan @ {decvax!,cernvax!}mcvax!{kunivv1,kunivv3}. [DECNET][RELAY][FOR TECHNICAL LAMBDA-MATTERS ONLY]: boehm @ vaxrma.decnet.cern = [Corrado Boehm][Rome][Italy].