LOGIN --- A (hard)disk software package managing system Copyright notice It is not allowed to spread this program for other than non-profit purposes. For Fred: It is explicitly allowed to spread this program for non-profit purposes, like PD, BBS'es, ... Environment for running These 5 script files (!) run on WorkBench 2.0, because they make have use of SETENV/GETENV and SET/GET. If you have your own versions of these, beware: lots of assumptions are made on the implementations of those. Nevertheless, it should be possible to do on onther configs too. Why managing packages? The average (hard)disk organization is a mess. My disk sometimes seems to be the only exception (I admit that most disks I see are on a PEECEE...) and I'd like to stop this. Let's define the mess I was talking about: lots of harddisk users use gigantic paths for accessing all programs they might ever use. This slows down CLI operation, but also makes working with the system structureless. A solution to this problem is a menu at startup-time, but I hate those, they tie my hands and restrict my toes to twinkle. On a Unix system, it is possible to have users log in under some package they always use; when they use more packages, they get more user-IDs. This way, a seperate environment is set up for the user(s), depending on the application they use. This implies short/fast paths, directly reachable data, etc. I use this sort of system on my Amiga 500 with hard disk and like it very much. Even some PEECEE-users who got a smaller version of it are pleased with it. Cool down! I am getting away with this. What I am offering here is hardly software (5 shell scripts on Workbench 2.1), but merely a set of ideas and guidelines. The scripts are easy ways to get these ideas going and will ease system administering enormously. What programs are there? Some definitions: A package is a piece of software, a project is what is being created with it. LOGIN: Enter a package and automatically select the last project worked on using this package. PRJ: Switch to another project within the same package. If it does not yet exist, the option to create it exists. PACK: Manage packages that LOGIN accepts. HM: Go home, i.e. to your project's directory. I know, this can hardly be called a program, but gee... It's handy!!! GLOBAL: Make settings more popular than now (local to the shell), so filerequesters can access them, and "login auto" goes to this Package/Project combination. How is it done? Each shell or CLI gets local environment variables, and also there will be global environmental variables. The locals are: $HOME The base of the piece of software. This value is deducted from the shorthand that is entered as an argument to LOGIN. $BIN The binaries for the program. When $HOME/bin exists, this becomes $BIN, otherwise $BIN equals $HOME. $WORK The basis for the user data. This variabel is deducted from the shorthand name that was entered as a LOGIN argument. Due to the differentiation between $HOME and $WORK it is possible to put programs and data on seperate (hard)disks. See the "MIRROR" program (distributed seperately) for extra ease in using this approach. $WF The WorkFiles for the current project. This value is influenced by the PRJ command in a way that can be redone when doing a new LOGIN on this package (also after rebooting). $PACKAGE Is the name of this package. This is the shorthand entered to LOGIN. Apart from $PACKAGE, all names are full pathnames. How to use LOGIN? Simply enter "LOGIN " to log in to application package . For management purposes, login has a flag "NOINIT", which asks LOGIN not to execute initialization code for the application, as it is put in files named ".login". The NOINIT flag sets the user in the $HOME directory, thus allowing easy editing of the $HOME/.login file. The file "$HOME/.login" file is executed if it exists, and can thus contain user startup code. (Assign x: y, SETENV ThisDIr=that etc.) The path has alsready been (re)set to "$BIN, C:" so this is not needed anymore. After $HOME/.login has been executed (or not) the same approach is applied to $WF/.login. How to use PRJ? After a successfull LOGIN, one ends up in some data directory known as $WF to the LOGIN system. This is the $WF that was active when the package was last left gracefully (i.e. I cannot cope with all sorts of memory failure or whatsoever, but turning your Amiga off when you are inactive within some package should not be any problem.) Simply enter a directory name that starts from $WORK. It may or may not exist; PRJ will handle it all. The most common structure is just a name, so you have a $WORK directory with a set of subdirs defining projects. Of course, it is also possible to have a deeper structure. To get rid of all sorts of nasty little things in between major projects, I have adopted a Misc directory that contains the small projects. Adding a new one would be done as follows: PRJ Misc/Ricky After answering questions this would create $WORK/Misc/Ricky. Never mind long pathnames: The LOGIN system takes care of these most of the time. (Actually, the only thing left to you is the switching between projects.) Another non-standard use is adding '/' in front of the filename, or even a device name. This is useful when packages share data, e.g. in the case where one tool generates a C-source that is to be compiled using another package, etc. How to use PACK? PACK can be used to watch, add or remove packages from the system. Note that PACK does not influence the actual programs/data, but only the database it holds online for LOGIN! PACK ADD This adds a new package for use by LOGIN, where is the shorthand in use for it, will become $HOME and will become $WORK. On first login, $WF=$WORK, and new projects can be started up using PRJ . Defaults for and exist. Note: if these do not apply, edit the PACK script! PACK REMOVE This deletes the package that is referred to as from the LOGIN system. The according "PACK ADD" entry as well as applying "PRJ " calls are deleted from existance. Removing of actual programs etc. is the user's task! PACK This displays all currently known packages in the form LOGIN_. PACK does not show the contents of the packages, though. It is assumed that you know this by means of earlier LOGINs; why else would you call PACK like this? How to use HM? Simply enter "HM" and you'll soon be home. (This does only "CD $WF", nothing fancy here, but very handy!) How to use GLOBAL? Simply enter "GLOBAL" and some settings are done. These are: HOME: WORK: WF: BIN: become the same as the values of $HOME $WORK $WF $BIN in the current shell. (What do you mean with "is this respectively? Of course!) LOGIN AUTO will next time be in the current package and project combination, as set in the current shell. The Assigns are useful for making choices in filerequesters faster; you have a logical device (viz. WF:) that makes it possible to access the correct directory in no-time. The AUTO package is a virtual package maintained for automatic login at boot time. To do so, extend your s:StartUp-Sequence or your s:Shell-StartUp etc. with the line "LOGIN AUTO" and all will be done as you want it: after a reboot, LOGIN AUTO places you in the last package in which "GLOBAL" was entered, and LOGIN switches to the project that was active during this "GLOBAL" call. Due to the LOGIN approach, minimal setup is needed, as you only want one single pakage started up. Have you ever tested self-written programs without a good debugger? I know I have! What does this package cost? Don't be silly. It's just some silly script files and a lot of bla bla. Though, now we got to think about it, I AM very interested in other people's opinions about this method. Do you have a better one maybe? Let me hear your experiences, please! Have fun, Rick van Rein Binnenes 67 NL-9407 CX Assen The Netherlands Internet: vanrein@cs.utwente.nl