Back to top
The Shell is the user interface for those users who prefer
entering commands via the keyboard rather than permanently
moving around with the mouse on the screen.
Furthermore, with the help of Shell-scripts (i.e command files,
that are executed like programs) many processes can easily
be automated.
But also when using the p.OS-Shell we can still use
Drag&Drop and intuitive operation. Commands and file names
can be moved to the Shell-window with Drag&Drop.
The shell even allows to enter abbreviated commands and file
names and automatically extends them. A history-function
enables the reverse-scroll through the previously entered commands
which may then even be edited.
In addition, a number of shortcuts is available as well.
The Shell is opened in a so-called Console-Window (CON:),
displaying the in- and output environment of the programs started
from the Shell as well as the shell itself. The device CON: may
also be used by other programs for their own keyboard in- and outputs
and this way profit from the extended functions like shortcuts, file name-
and command extension as well as from the History-function.
Here is again a brief overview:
File name- and command completion,
History
Special features of the
Console-Window
Redirection of standard in-
and output
Argument templates
environment variables
file system
pattern matching
runtime error handling
command reference (alphabetical)
Well, let us now open a Shell-window.
Then enter an incomplete command name and press the
[TAB]-key. Is the part of the entered command unique
i.e. does only one command exist in the command path of the
Shell starting with the characters entered by us, the command is
automatically expanded without any further action from our part.
However, if several commands are found starting with these characters,
a small window opens with a list of the possible commands
from where we can then select the suitable command by mouse-click.
The same is valid for file names.
It can be undone with the keys [Shift+TAB].
With the key combination [CTRL+C] the explicit expansion
of a command can be demanded, [CTRL+D]
expands just the directory name and [CTRL+F] just the file names.
Furthermore, the History-function allows to repeat and edit the
command last entered with the [Cursor up]-key.
Also see section:
"Special features of the Console-Window" for further
information on these subjects.
Shell-commands usually pass on their data via the< BR>
standard output and expect to receive entries from
the standard input.
These two paths can be redirected to files or other devices
like e.g. to a different output window with the signs ">", "<", ">>" and "<>".
">" deviates the output to the file entered, which will be
overwritten if the file already exists.
">>" redirects as well to the file entered, however, in
case the file already exists, the output of the command
is added to the already existing file. Should the file not yet
exist, the file will be created.
"<" redirects the input "from" a file, i.e. when the program
asks for an entry, this will be read from the file entered.
Last but not least, "<>" redirects the in- as well as the output to the
same file.
Special files are e.g. "CON:", redirecting the in-/output to
a new window, or "NIL:",the nirvana of data: anything deviated
to NIL: simply disappears forever. This is e.g. important for
command files but as well in case you wish to start a program
in the background and afterwards close the Shell-window.
Also see the Runcommand.
CON: offers several further possibilities
CON: is able to process arguments, that can be annexed to
the device name like a path name of directories.
CON:[LeftEdge]/[TopEdge]/[Width]/[Height]/[Title]/[extensions]
Optional extensions (after "Title"):
/CLOSE
create Close-Gadget, click on the CloseGadget corresponds to Ctrl-\
/AUTO
Window opens with first output only
/WAIT
Window contains a Close-Gadget and has to be
closed manually
/INACTIVE
Window is not activated when opening
/NOSIZE
Window contains no Size-Gadget
/NODRAG
Window cannot be dragged with the mouse
/NODEPTH
Window contains no Depth-Gadget
/NOBORDER
Open window without border (and without System-Gadget)
/NOSLIDER
Window contains no slider
/LINES
defines number of lines to be buffered, e.g.
/LINES 800 => 800-lines are buffered
/FONT
Defines the window-font, e.g. /FONT topaz,11 => the
'topaz.font' with a height of 11 is used as font.
Could the font not be opened, the screen-font will be
used. Proportional fonts are not to be used.
/SCREEN
Public-Screen, where the window is to be opened.
/TAB
Activates the special CON-extension.
/READONLY
The console only allows output and no input.
Some shortcuts are available as well:
During the execution of commands the key-combinations
(Shortcuts) [Ctrl+C],[Ctrl+D], [Ctrl+E] and[Ctrl+F]
serve as process-signals, i.e. a singal with a certain
meaning is sent to the running program. The signals
have the following meaning:
C - cancels the current command
D - cancels the current script
E/F - can freely be interpreted by the command
During the input via the command line, the following
shortcuts are available:
Ctrl-X
Delete line
Ctrl-S
Stop display/stepwise display
Ctrl-Q
release stopped display again
Ctrl-\
create EOF resp. ^C + ^D
Ctrl-Z
Zip Window, toggle window size between minimum/maximum
Backspace
delete character left of the cursor
DEL
delete character underneath the cursor
Cursor-Left
Move cursor to the left
Cursor-Right
Move cursor to the right
Cursor-Up
scroll up history-buffer
Cursor-Down
scroll down history-buffer
Shift-Cur-Left
Cursor to line start
Shift-Cur-Right
Cursor to line end
Shift-Cur-Up
browse History-buffer for pattern
Tab
create (expand) path
Shift-Tab
Undo path
Ctrl-C
expand command name
Ctrl-F
expand file name
Ctrl-D
expand directory name
A command usually also receives arguments. To clearly
specify, which and how arguments are accepted by a command,
argument templates are available, that can be used
as well when describing the different commands.
Under p.OS, the arguments cannot only be read from
the command line, but as well from external configuration
files or Shell-variables, and even from the
proper programs (commands), start-arguments can be read.
To save default-arguments in shell-variables
please see section environment variables.
Further to the proper arguments, there are Shell-options
that can be entered in addition to the arguments.
A command line of the p.OS-shell consequently has the
following structure:
The Shell-options always have to be surrounded by "{}".
Several options can be entered, which are then separated by
colons or have to be entered directly in a row.
The following options are available:
{^}
Lists the argument assignment
{%}
Reads the arguments of Standard-IN, e.g. dir
{%}
{!}
Default-arguments are not considered
{?}
gives a list of options
{*}
Displays just the argument template, without
an entry-requester appearing after the display.
Example: dir {^%} waits until an
argument is entered, displays it again and only then displays
the directory entered. Fine, and what the hell is the use of it?
It is primarily very useful in scripts. This way, the user
is able to enter arguments of a command in the script
without having to use any input-function at all (with "%").
Furthermore, with the "^"-option it can immediately
be checked, if all arguments have correctly been entered.
Example:
; The interactive directory lister-script
echo "Which directory you wish to view?"
dir {%}
; Here the script ends
Let us now talk about the arguments.
Each argument has a keyword, which may optionally
be followed by an identifier, separated by a slash("/")
from the keyword. Does a template contain an equal
sign, the keyword before as well as the one following the
equal sign can both be used as a synonym. This option is
often used with commands, awaiting the entry of
arguments with the corresponding keyword. Since these
are usually very long, to make clear what is meant,
abbreviations may also be used. By entering a command with
the argument "?", the argument template of the respective
command is displayed and the arguments can interactively
be entered (in contrast to the "*"-Shell-option, see above).
With the entry "??" a short helptext on the program is displayed,
provided a text has been defined. Unfortunately, many shell-
programs do currently not yet have a help text.
To pass on arguments to a program, there are several
possibilities:
The keywords from the argument template may be entered
as well, to make clear which argument is meant, like e.g.:
3.pOS:pOS.0[0]> dir DIR MyDir
Or as well:
3.pOS:pOS.0[0]> dir DIR=MyDir
Where this is not expressly required, the keywords may also
be left out. However, in this case the sequence of
the arguments has to be considered, i.e.:
3.pOS:pOS.0[0]> dir MyDir
Does an argument contain a space, it has to be set in
inverted commas, so that it can be recognized
as anargument:
3.pOS:pOS.0[0]> dir "My Dir"
The longest method would consequently be:
3.pOS:pOS.0[0]> dir DIR="My Dir"
The identifiers in the template have the following meaning:
/S
The keyword stands for a switch-option.
Is the argument entered corresponding to this keyword,
an option of this command will be activated.
Under p.OS it is also possible to explicitly activate or
deactivate such a switch. Like e.g.:
dir all=on or
dir all=1, the opposite would
thus be: dir all=off or
dir all=0.
This does not only have the sense of better readability in
configuration files as well as a completely different purpose
explained in section Shell-variables.
/K
The keyword has to be entered as well when
the argument is used.
/N
The argument has to have a numeric value.
/A
The argument always has to be entered.
/M
The argument may also be entered several times.
/K
The keyword has to be entered with the value of the argument.
/F
The argument has to be entered last.
Anything following the argument in the command line
will be considered as one single argument. This
allows e.g. to pass on strings as an argument, containing
spaces or other special characters.
The p.OS-Shell knows two kinds of variables: local and
global ones.
Local variables are only valid within the
Shell-process they were defined for. Global variables,
are valid in all p.OS execution environments.
Values are assigned to the variables with the Shell-command
Set and with Get
the values can be output.
The variables are saved as files in the
directories ENV: and ENVARC:. Also see:
Set-Command.
By starting a Shell-variable with a dollar sign ($)
it is dereferenced, i.e. wherever a dollar sign
appears followed by a variable name, the value of
the variable will be used. Basically, command macros
might also be defined this way. However, this should
rather be done with the command Alias.
The values of variables are always strings of characters.
Shell-Variables for Default-Arguments of Commands
Under p.OS the commands are also able to read standard-
arguments from variables. These variables are saved in the
directory ENV:shell (bzw. EnvArc:shell).
Let us e.g. determine that whenever calling
the DIR-command, all sub-directories are automatically
displayed as well, without having to enter"ALL" every time:
SET shell/DIR ALL
Should we now wish to view a directory without its sub-directories
we have to proceed as follows:
dir ALL=OFF
Now, the sense of the explicit activation and
deactivation of switch-arguments becomes clear!
Furthermore, even the Shell-Option "{!}" can be used,
suppressing the use of default-arguments.
The present file system of p.OS is mostly compatible
with the AmigaOS FastFileSystem. So far, hardlinks can
only be read and softlinks are not supported at all.
We will also have to wait some time to get the Multiuser-feature.
The file name may contain up to 34 characters, where
basically any characters can be used. However, we do not recommend
to use special characters that already have a special meaning
as pattern.
Does a file name contain spaces, it has to be passed on
to a command as an argument inclosed in double quotes.
The generation date, the time, 8 protection bits and
optionally a comment are saved with each file.
The protection bits have the following meaning (also see commands List and Protect):
s
The file is a script and may be executed without
the command Execute.
p
This file is a "pure" executable program, i.e. it is
multitasking-reentrant and reexecutable and with
the command Resident
it can be made memory resident.
a
The file has been archived. Many Backup- and
archiving programs use this bit to determine
which files have already been archived so that
those files do not have to be read again with the
next archiving process.
r
The file can be read
w
The file can be edited
e
The file can be executed (only useful for
programs)
d
The file can be deleted
Patterns consisting of so-called wildcards, are accepted by most
commands as arguments, where a file name or a path name has to
be entered. These wildcards are characters, standing
for a string of signs. The following wildcards ("w" is any
pattern) are available:
?
dummy for any single character
#w
A "#" stands for a repetition of the succeeding wildcard, i.e. "#?" means
"any combination of any number (including zero) of single characters",
which corresponds to "all" in the case of file names.
w1|w2
Stands for all character strings either defined
by w1 or w2
~w
Stands for anything not defined by w
(w1 w2 ...)
stands for anything defined by w1 and w2 and ...
%
stands for an empty character string
[-]
stands for all characters, alphabetically (in ASCII )
located between and
It naturally often happens, that a program cannot be
executed in the way it was originally planned. The
reason might be wrong arguments that were passed
on, or the file entered could not be found etc.
In such a case, the user gets an error message
via the standard error-output.
But what can be done if a program causes an
error, that was not interactively started via the
Shell, but e.g. from a script? Simply cancel the script?
Further operate with probably erraneous data?
Is an error message to be given or not?
The answer to all these questions is the
error coding of the Shell.
After executing a program, the program returns a certain
value, the error code, back to the Shell.
If no errors occurred, the value is between 0 and 4
(NO ERROR). Some errors do not necessarily
require a cancelation of the program. In this case, the program
reports a value between 4 and 7 back to the Shell
(WARN) to warn the environment (the script) that the
program might probably not have fully been correctly executed
but still did not have to be cancelled.
In case of all other errors, the program has to be cancelled
and the executing environment (the script) has to be informed
which does, however, not necessarily mean that the script
needs to be cancelled as well.
There could be the special case, that the program was
cancelled by the user which would induce an error code
of 8 (ABORT). Should the program internally recognize
a "non-fatal" error, this would be marked by a
value between 9 and 19 (ERROR). Should an error occur,
that turns the further execution of the addressed script
(or whatever was addressed by the program) impossible
("fatal" error), the value reported will be 20 or higher (FAIL).
When executing its script, the p.OS-shell checks the return value
after every executed command, and cancels the script as soon as
the value exceeds 10 (ERROR).
With the command FailAt this
response may be changed. The limit value leading to a cancelation
of a script may e.g. be increased to then manually intercept
the error with IF WARN, IF ERROR or IF FAIL.
Command Reference
The p.OS-Shell