Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Problems with rebol startup Re:

From: brian:hawley:bigfoot at: 20-Sep-2000 4:36

[tim--johnsons-web--com] wrote:
>Hi: > It appears that user.r is not evaluated by rebol unless rebol >is started from the home directory. > >To clarify : > >OS is Windows NT
Say no more. When REBOL starts up, it runs %rebol.r and then %user.r if it finds them. It looks for these files in these directories, in this order: (REBOL/View checks these first) - The directory referenced by REBOL_VIEW the environment variable if it exists. - The directory referenced by the registry entry /View installs. (All REBOLs) - The directory referenced by REBOL_HOME the environment variable if it exists. This is supposed to be where REBOL is installed. - The directory referenced by the HOME environment variable if it exists. This is supposed to be the user home directory. - The current directory (or startup directory of the shortcut). On Windows platforms this lookup process has three problems: - Minor: The user home directory is referred to by the USERPROFILE variable on WinNT. The APPDATA variable refers to where you put user data for applications on Win2K, although the USERPROFILE variable is there too. Lastly, the Win9x/Me distributions don't use environment variables at all. Programs can get the AppData location from the registry if IE 4.0 or above is installed, but stock Win95 installations don't even have this as a concept. Don't you love consistency? - Somewhat bad: REBOL doesn't expand any existing environment vars in the definition of the REBOL_HOME and REBOL_VIEW variables on WinNT/2K, even though every other program does. This means that you have to explicitly specify the full paths rather than the paths relative to the appropriate system variable. This seems to be a "feature" to let you specify directories in REBOL syntax. - Major: This lookup process is only performed once, rather than once for %rebol.r and again for %user.r. This means that you have to store your global settings (%rebol.r) in the same place you store your user-specific settings (%user.r). This completely defeats the purpose of having two settings files. This is a bug. The first problem can be worked around on WinNT/2K and ignored on Win9x/Me where multiuser settings are more a problem than a benefit. The second and third problems have been sent to Feedback by me as a bug report. It would help if others would do so as well. Here's how I set up my Windows REBOL installations. This works. Directories: C:\Lang\REBOL (can be C:\Program Files\REBOL) \Command \Core \View Environment Variables, single-user: REBOL_HOME=C:\Lang\REBOL (or C:\Program Files\REBOL) REBOL_VIEW=C:\Lang\REBOL\View (or C:\Program Files\REBOL\View) Environment Variables, multi-user (replace Username with real ID): (On WinNT, in the System control panel) APPDATA=%USERPROFILE%\Application Data REBOL_HOME=C:\WINNT\Profiles\Username\Application Data\REBOL REBOL_VIEW=C:\WINNT\Profiles\Username\Application Data\REBOL\View (On Win2K, in the System control panel) REBOL_HOME=C:\Documents and Settings\Username\Application Data\REBOL REBOL_VIEW=C:\Documents and Settings\Username\Application Data\REBOL\View Files: I put %rebol.r and %user.r in the REBOL_HOME directory, and again in the REBOL_VIEW directory in case I want them to be different. I reference all global library scripts with full paths and user library scripts with relative paths. If I want to reference scripts in REBOL_HOME from both that and View I write the filenames as %////script.r with the appropriate number of / for the depth of REBOL_HOME in the directory tree. Since I tend to load these scripts with %require.r, which indexes scripts by fully qualified paths, I had to fix clean-path so that it would properly expand %// REBOL relative paths. REBOL briefly had my fixed clean-path, but went back to the old one - I think it got lost in the shuffle. It works, though. Look for it on my web site, such as it is. Yes, this is all rather awkward. Brian Hawley