Skip to main content

Standard Directory System

STD -- Standard Directory

Overview

The 'Standard Directory System' has been in use in various forms for more than 30 years.The principal aim of the system was to avoid collisions. That is, it was intended to allow files that are different from one another to never overwrite one another. This was accomplished by having conventions for the names that are used for various common programs.As the system has developed, the system is made to organize things so that they are easier to find. This is accomplished by having conventions as above for particular programs and general conventions for particular types of programs and conventions for standardized directory structures. The standard anticipates various types of common requirements and assigns standard names to those requirements.

Standard Directory Names

Where possible, conventions that already exist have been followed. In some instances, such as the 'usr' directory under UNIX, it has been decided to deviate from the convention so that collisions are avoided. In other instances, such as the 'home' directory, the convention has been followed to allow easy transition back and forth between the systems.

General Conventions

Three letter name sizes

As a rule, directory names are only three letters long. There are several reasons for this: People generally find 'TLAs' easier to remember. By making most 'standard' names the same size, other directories are easy to spot in a listing Organizing large disks can require very deep structures. Using long names often leads to over-runs in the size of the name. This is particularly true for various target media. For instance, some media limit the total path length to only 63 characters. ISO 9660 CD-ROMs have a maximum path length of 207 characters. By making the standard names only three characters long, we free up more space for other software that does not follow the standards. For instance, here is a real pathname as constructed by other software and its equivalent as a 'standard directory name':
  1. C:\Program Files\Microsoft Small Business\Small Business Accounting Addins\Fixed Asset Manager\Templates
  2. C:\std\app\mcs\msb\sba\fam\tpl
Example 1 is 104 characters long. Example 2 is only 30. Should there arise an occasion (as there does in the real world) where one would want to copy a backup with the full directory structure into the bottom of the path, it would exceed the length allowable on most CD-ROM's and it would not be possible to copy it there. Worse, many file systems will allow you to write a path that exceeds their limits and then not allow you to read or delete that path.Experience with real world systems where entire structures must be written deep into other directory structures shows that problems arise quickly if very long names are used. Since we can't control the use of long names in other systems, we are doubly obliged to keep our own usage to a minimum.

Simple Names

The standard specifies that names should be, as much as possible, formed according to simple 'lowest common denominator' rules. This is in keeping with the principal that we are attempting to avoid 'collisions'. In this case, the collisions are with the conventions of a given operating system. That means: No spaces, use underscores if needed. No characters that conflict with operating system shells -- example: '(', ')', '[', etc. Generally use lower case letters to remain compatible with case-sensitive systems such as HTTP. If practical, there is still a bias toward 8.3 DOS style file names, especially with files that may travel to many operating environments -- example: readme.txt As a general rule, the name should be able to retain its exact structure across all environments where it is likely to reside.

Some specific names

Root directory

The root directory currently in use is 'std'. This is not particularly important and for anyone using the system outside of ones created by us, any three-letter root that does not collide with conventional directories would be fine.Standard Sub-Directory NamesThis is not an exhaustive list and it changes from time to time as standards change.std -- Root Directory Root directory as currently used. This can reside on any drive or in the case of UNIX would hang off the regular root. Example: C:\std\
  • app -- Applications
  • app -- application directories
  • arc -- Archives
  • arc -- Archive Files -- Not quite the same as the backup directory. This directory merely contains archives of files that are taking up space but still may be needed from time to time. It is also a 'scratch area' to allow archiving temporarily to free up disk space.
  • bin -- Executable Files
  • bin -- binary executables and scripts.
  • bkp -- Backup Files
  • bkp -- Backup files and related files. These are intended for actual backups. What type of backup resides here depends upon the location of the directory.
  • cyg -- Cygwin
  • cyg -- Under Windows environments reserved for Cygwin.
  • dvl -- Development
  • dvl -- Software Development directories.
  • doc -- Documents
  • doc -- Documents -- *.doc, *.txt, *.xls, *.ppt, etc.
  • home -- User Home Directories
  • * home -- home directory -- retains UNIX convention for home directory.
  • hme -- home directory -- home is deprecated. By making user homes different from both Windows Logins and UNIX logins, it makes the system more 'OS agnostic'. It also does not suffer from the clutter put in home directories by well-meaning admins. Copying /std/hme/nzt/doc from one system to another should not interfere with anyone else's conventions.There is also the matter of symmetry. Branches should generally be three letters. That seems to work best in practice and it makes directory trees easier to visualize, less tedious to type, etc. Leaves can (and arguably should) take longer names thus creating: /std/hme/rst/dvl/vb6/tst/TestTrackBall would be perfectly valid. The path above breaks down as :
  • std -- Standard root hme -- Home directories rst -- Robert Stephen Trower's home directory. dvl -- development vb6 -- vb6 specific development tst -- test programs TestTrackBall -- Working directory to Test TrackBall code.
  • inc -- Include Directories
  • inc -- include directory -- contains various types of include file. This is generally different from the C-Language standard 'include' directory.
  • lib -- Library Directories
  • lib -- Libraries. This typically contains *.lib or *.o or *.obj files.
  • std -- std 'reflection' directory
  • std -- Under C:\std, for instance, this would be C:\std\std. It is used as a 'reflection' of a standard structure that might, for instance be the subject of a network share.
  • svn -- Subversion
  • svn -- Subversion Revision System
  • tmp -- Temp files
  • tmp -- Temp files. This is especially used by things such as session variable.
  • trn -- Transfer files
  • trn -- Transfer directory. When files are being transferred into or out of the system, this is where they reside during transfer.
  • web -- WWW files
  • web -- Root of things related to a local web server.
  • wrk -- Work/Scratch files
  • wrk -- Many things done on a file system involve things that are experimental, have a limited lifetime or require some thought to create a permanent home. The 'wrk' directory is designed to give a quick area to do work that will not interfere with the rest of the system.

Standard Path Variable

The 'standard path' is formed so that the commands available depend upon your context within the file system. For instance, there may be utilities specific to one set of files that do not apply to another. This ensures that when appropriate, the commands are on your path, but does not require your path to include everything on the disk.
The standard path usually contains something similar to the following:

Standard Paths

Absolute Paths

Personal Command directory (over-rides all) C:\std\home\myname\bin; Global command directory; C:\std\bin; Root command directory \bin;

Relative Paths

local command directory bin; Parent command directory ..\bin; grand-parent command directory ..\..\bin; great-grand-parent command directory ..\..\..\bin;The above forms a path similar to this: path=C:\std\home\myname\bin;C:\std\bin;\bin;bin;..\bin;..\..\bin;..\..\..\bin;

Operating System Paths

Other paths are required as well, such as: Adjunct OS path (Cygwin) C:\std\cyg\bin; The operating system path: C:\WINDOWS;\C:\WINDOS\SYSTEM32;It may also be convenient for certain things to be usable globally from the command line:Application Paths Application path C:\std\svn\bin;

Putting things together in the intended order gives a path that looks like this:path=C:\std\home\myname\bin;C:\std\bin;\bin;bin;..\bin;..\..\bin;..\..\..\bin;C:\std\cyg\bin;C:\WINDOWS;\C:\WINDOS\SYSTEM32;C:\std\svn\bin;

As can be seen above, this is already a substantial path. However, it allows a very wide range of commands to be available while working and leaves room for the many applications that add their own paths during installation. Because many of the commands are on relative paths, the search for a command is much faster than it would be if all application commands were on the path at once. The bin;..\bin;..\..\bin; relative path construct also allows the placement of commands to show a finer granularity and greater specificity to the task at hand.

By placing everything that pertains to a given system within its own directory structure, backup, removal and restoration of backups is simple and has a minimal impact on the rest of the system.

Relative paths also allow the simple relocation of directories and also allow the creation of completely operational copies of the directory in other places. It is possible, therefore, to try a radical global change on a group of directories on a copy rather than the original.

Comments

Popular posts from this blog

The system cannot execute the specified program

It always annoys me no end when I get messages like the following: "The system cannot execute the specified program." I got the above error from Windows XP when I tried to execute a program I use all the time. The message is hugely aggravating because it says the obvious without giving any actionable information. If you have such a problem and you are executing from a deep directory structure that may be your problem. It was in my case. Looking on the web with that phrase brought up a bunch of arcane stuff that did not apply to me. It mostly brought up long threads (as these things tend to do) which follow this pattern: 'Q' is the guy with the problem asking for help 'A' can be any number of people who jump in to 'help'. Q: I got this error "The system cannot execute the specified program." when I tried to ... [long list of things tried] A: What program were you running, what operating system, where is the program? What type of

Coming Soon: General Artificial Intelligence

The closer you get to experts who understand the nuts and bolts and history of AI, the more you find them saying that what we have is not nearly General Artificial Intelligence (GAI), and that GAI seems far away. I think we already have the roots in place with Neural Networks (NN), Deep Learning (DL), Machine Learning (ML), and primitive domain limited Artificial Intelligence (AI). Things like computer vision, voice recognition, and language translation are already in production. These are tough problems, but in some ways, machines are already better than humans are. I expect GAI to be an emergent property as systems mature, join, and augment one another. I was around during the 70s AI winter, and was involved in the 80s AI winter as one of the naysayers. I built a demonstration system with a Sperry voice recognition card in 1984. I could demonstrate it in a quiet room, but as a practical matter, it was not production ready at all. Around 1988 we built demonstration expert systems usin

Your call is important to us, but not much.

Rogers entire network is down and Rogers either does not know why or sufficiently disrespects its customers that it won't say. I was on the advisory committee for the largest private network in Canada serving 150,000 employees countrywide. I was also an active participant building out that network. I installed the first Local Area Networks there. I wrote a code generator responsible for the most critical portion of Bell's mobile network. I also wrote a portion of code for a system in the United States that detected and pinpointed line breaks in their network before they happened. For a time, I held the title 'Networking Professor' at our local College. I registered my first domain name in the 1980s. I have administered Internet network servers for decades. In one capacity or another, I have worked with most of the telecommunications providers in Canada past and present. Nearly a billion devices use a small network codec written by me decades ago.  Except that Rogers was