ShellDir is an AmigaDOS script that enables the user to start a new CLI from
any directory. Being a script, ShellDir belongs in S: and should have its 'S'
ShellDir can not only take a directory path as argument, but also a path to
a file instead (including wildcards).
ShellDir behaves similarly to the commands NewShell and NewCLI, allowing the
user to specify WINDOW and FROM arguments as required.
ShellDir needs no additional software and should run happily on any 2.x or
ShellDir takes little disk space, so you'll hardly notice it's there!
It can also be used with menu software such as ToolsDaemon or AppMenu; in
which case selecting any file, directory or volume on your Workbench screen
and then selecting ShellDir from your menu, a new CLI will be opened in that
location. Example configuration files are provided for you.
For example, typing 'shelldir sys:utilities' (without quotes) will create a
new AmigaShell window in which the current directory will be SYS:Utilities.
shelldir devs:do#? -> AmigaShell in DEVS:DOSDrivers
shelldir sys:p#?/e#?/sys -> AmigaShell in SYS:Prefs/Env-Archive/Sys
shelldir / -> AmigaShell in parent directory
shelldir : -> AmigaShell in root directory
shelldir from/ -> AmigaShell in 'From' directory (assuming it
shelldir "from" -> As per previous example exists)
shelldir dir from -> As per previous example
shelldir devs:#?rs -> AmigaShell in current directory
In the previous example, the pattern matches more than one drawer (Monitors,
DOSDrivers and Printers), which makes the path invalid as far as ShellDir is
concerned. Note: ShellDir will always create a new Shell, even when a path
is found to be invalid. If you do not like this behaviour, install ShellDir
Lite instead (see below).
shelldir l: from s:custom-startup window "con:100/50/40/100/My Shell/close"
-> Custom dimensions, name and startup file, with L: as current directory
Note the use of double quotes in the above example due to the space used in
the window title. Likewise, if there is a space in the path of your custom
startup file then you must enclose your FROM argument in double quotes as
well. This also applies to the DIR argument:
shelldir "work:my music/the seekers" from="s:my spiffing shell-startup"
When used with menu or dock software, the .INFO switch is provided so that
icons without associated files can be used with ShellDir also. One such icon
would be the Shell icon provided with Workbench. Other examples are tool or
project icons from icon collections.
By consequence of supporting files, ShellDir is able to enter directories
where you perhaps thought it ought not. For example:
shelldir sys:prefs/#? -> AmigaShell in SYS:Prefs - Despite there being two
drawers here (Presets and Env-Archive) which cannot of course be entered,
there does however exist a number of files, subsequently matched via the
wildcard #?. Had there been just a single drawer here instead of the two,
that drawer would have been entered instead. Whereas ShellDir can only enter
a desired drawer via a single drawer match, one or more file matches are
all that's required to enter that path also (should the desired drawer not
exist or more than one matched drawer exists). Consider another example:
shelldir sys:?????/e#? -> AmigaShell in SYS:Fonts - Two drawers are matched
here (Prefs/Env-Archive and Fonts/emerald), thus cannot be entered, yet a
file does exist which matches e#? - namely emerald.font.
If you are too vague with paths, you will get file matches across multiple
directories and therefore ShellDir may not open in the directory you expect.
For the purist, I include ShellDir Lite. This version does not consider
files, but only directories. Nor does it open Shell's regardless; if it does
not open a new Shell it will tell you as to why, leaving also an appropriate
return code ($RC=10) in the process. This ensures proper behaviour when used
from within scripts, for example.
ShellDir Lite Template:
shelldir sys:prefs/#? -> 'More than one directory matches' (returns $RC=10)
Then there is ShellDir De Luxe. This version is like the standard ShellDir,
except it adds two additional switches; these are REQ and CLOSE. REQ will
open a file requester, enabling you to select any file, directory or volume.
REQ also works in conjunction with DIR, to the end that the file requester
will open in the directory specified.
Upon successfully creating a new Shell window, the CLOSE switch will close
the Shell behind itself.
ShellDir De Luxe Template:
shelldir sys:prefs req -> Opens a file requester in directory SYS:Prefs
shelldir req -> Opens a file requester in current directory
shelldir devs: close -> AmigaShell in DEVS: (parent Shell will close)
A correctly booted OS 2.04+ environment (T: and ENV: assignments made).
It should work with v36 too, but this has not been tested.
Double click on the provided Install icon. There are four versions provided:
Normal, Alternative, De Luxe and Lite. The first two are equal in terms of
functionality, yet the Alternative version tends to resolve files slightly
quicker (and drawers marginally slower).
The De Luxe version adds REQ and CLOSE switches, along with a safeguard for
deep directories, but is otherwise the same as the Normal version.
The Lite version does not resolve files, but it does leave an appropriate
error message and return code should an error occur. An error could be, for
example, a multiple directory match. The safeguard is present here also,
which simply protects the calling Shell from a change in current directory,
should this directory be too deep. ShellDir will gracefully exit in these
To use the installer via the Shell only, you must first 'CD' into the
ShellDir directory, and then type 'install'.
For manual installation, copy the required version of ShellDir for your OS
to the S: directory, then rename to 'ShellDir' as necessary. Refer to the
chronological version table below. To avoid mishaps, please use the provided
Install icon instead.
OS2.x to 3.9BB1 -> v37
OS3.9BB2 to BB4 -> v45.3
OS3.1.4 to 184.108.40.206 -> v45.3 (except v45.194 for .dlux version)
OS3.2.1 or higher -> v47.3
The installer can be run as many times as you wish. If it finds an existing
version of ShellDir, it will inform you accordingly.
If you'd prefer to change the default WINDOW and FROM specifications, then
these are editable from within the ShellDir script itself. To do this, look
for the line starting 'NewShell "<WINDOW$CON:...'.
Alternatively, if using ShellDir with a menu or dock program, of course you
can edit the command field adding WINDOW and FROM specifications there, too.
If you require preservation of the calling Shell's fail limit, then you'll
need to RUN ShellDir, otherwise it will be reset to the default value of 10.
If executed from within another script, it will become 21.
ShellDir doesn't check whether T: or ENV: are assigned, but these are
required for correct functioning.
For the non-De Luxe versions, a file requester option is easily attainable
in AmigaDOS like this:
shelldir `requestfile` (note the use of backticks (`), not apostrophes)
Or, for a more handsome version:
ShellDir `RequestFile SYS: TITLE "Select File or Directory" NOICONS`
It will then open a new Shell in the chosen directory, or the directory of
the chosen file. If you examine the ToolsDaemon.menu file, you will see that
a longer form has been used in order to facilitate erroneous selections via
the Workbench, and handling of the Cancel button in the file requester (see
the 'Example_Configs' drawer). This makes for a handy extra in your menu or
hot key program. ('Erroneous' here refers to multiple icon selections, for
ShellDir can only receive one single DIR argument.)
Note that 2.x users will need to download RequestFile from Aminet, as it is
not part of the OS. I highly recommend 'util/batch/RequestFile.lha' by Simon
Dick (v37.4), as other implementations appear to have problems.
On the subject of menus, if you use AppMenu then I recommend you RUN it at
the bottom of the Startup-Sequence, just above 'EndCLI >NIL:' like so:
'Run >NIL: Work:MyTools/AppMenu2.4/AppMenuCx'. That way it will inherit the
same paths as Workbench - notably S: (home of ShellDir). This method also
avoids the annoyance of Shells starting in SYS:WBStartup. I recommend that
ToolsDaemon is started in the same manner, except that it need not be RUN,
due to it detaching itself from the CLI. It would be wise to add the DELAY
option to the LoadWB command too; this avoids a possible situation whereby
your menu program will be unable to create its menus due to Workbench not
being fully initialised.
Another way to get around a path issue would be to add an ALIAS in your
User-Startup file like so: 'Alias ShellDir S:ShellDir'. This ensures that
ShellDir will always be found, even if S: isn't available in the current
path. Note: only edit your Startup-Sequence if you know what you are doing!
ToolsDaemon allows keyboard shortcuts to be assigned to menu items, and for
those items to be passed arguments (icon selections on the Workbench Screen)
when invoked via their shortcut key. ToolManager doesn't fully support this,
and AppMenu doesn't support it at all. In these cases, I highly recommend
'util/wb/ReKeyIt2_4a.lha' by Michael Barsoom. This wonderful program will
allow you to assign keyboard shortcuts (of your choice) to invoke ShellDir
correctly with arguments, via they keyboard. The shortcut keys I have chosen
for my own personal use are as follows:
Item "ShellDir" = right_amiga # -> Open ShellDir in chosen location
Item "ShellDir *" = right_amiga -> Open ShellDir using a file requester
On a UK keyboard, these are the same key, where the '' needs the Shift key
to be pressed too. This is highly convenient, as it sits just to the left of
the Return key. In the menu items, 'ShellDir *' has been chosen for the file
requester option. I have included this simple (asterisk friendly) ReKeyIt
configuration for you to try for yourself.
The example ToolManager (2.1) configuration also demonstrates the use of a
ShellDir AppIcon. Simply drag any file, directory or volume onto the AppIcon
and a new Shell window will be opened in that location.
For extra speed on slow systems, you might try making the commands Execute
and List both resident, if not already so. ShellDir Lite does not use List,
so just Execute in this case. In order to check whether these commands are
already resident, simply type 'resident' at a command prompt and take note
as to whether they appear in the list. If Execute does not appear, then you
may need to edit your Startup-Sequence and comment out the following line:
'Resident Execute REMOVE'. (In most cases, Execute is made resident and then
later removed from the resident list after execution of the User-Startup.)
List is somewhat more straightforward. For permanent 'residency', add this
line to your User-Startup:
Resident C:List PURE
In addition, if using ToolsDaemon via WBStartup, then you could add the Tool
Type 'WINDOW=NIL:' to its icon, and dispense with the 'Run >NIL:' section of
ShellDir's command field. This saves the overhead of creating a background
Shell. Bear in mind though that this will suppress console output for all
relevant commands launched via ToolsDaemon, unless you manually redirect
such commands to a new console window.
If you get an 'object not found' message whilst running OS3.2.1 (or higher),
then you'll need to check your Shell version by typing 'version shell' at
the command prompt. If it reads 'shell 47.47', then it appears you are still
running the older Shell and for some reason it is not being updated via the
LoadModule mechanism (as of 3.2.1 this becomes 'shell 47.48').
If ShellDir doesn't 'CD' into your chosen directory, then this will likely
be due to the specified path being too deep, or that there is a CD entry in
your Shell-Startup file which will need removing, or bypassing with the FROM
argument. Alternatively, you could edit the default FROM setting of ShellDir
itself (see the Configuration section above), thereby pointing to a custom
If ShellDir appears to not work at all, or you get a 'file is not executable'
message, then please check ShellDir's protection bits. You can set these via
the CLI, or use the Workbench menu's 'Execute Command...' (right Amiga+E) by
typing 'protect s:shelldir srwd'. This will set them correctly.
If when being used from a menu program such as ToolsDaemon, ShellDir doesn't
open in the directory you expect after certain icons are selected, then in
all likelihood these are lone icons (without associated files) and you will
need to edit the ShellDir menu command to include the .INFO switch like so:
'Run >NIL: S:ShellDir  .INFO'. This switch is left off in the example
configurations because ShellDir Lite does not have this facility.
Please note that if using ToolsDaemon on OS3.9 or later, you will need to
patch it first. At the time of writing, this can be downloaded from Aminet
ShellDir is to be used entirely at your own risk, and without warranty. This
applies to ShellDir both in its unmodified and modified forms. Documentation
is provided as guidance only, with no guarantees made regarding its accuracy
nor its fitness for purpose.
Humanity has, and sadly continues to cause damage to the natural world. By
my own observation, loss of habitat being not the least of the problems.
If you find ShellDir useful, please consider making a donation to a charity
that helps wildlife or their natural habitats, wherever that may be. Help
may be offered by other means too; your charity and consideration being key.