view user.r startup "bug" finally clearly identified...

[1/3] from: moliad:aei:ca at: 7-Oct-2003 4:57

view user.r startup "bug" finally clearly identified... hello all, I am not sure how many of you have had this problem, but it has happened to me on several occasions that for the damnest reason, all of a sudden your stuff in the user.r is ignored. This sometimes has the effect that View asks you to re-install itself. Sometimes though, it will be that some later setup you added in yout user.r (like steel's library setup line) is not seen! You open your user.r script and the wanted stuff really is there, but for some obscure reason its not used! But usually, its just that some of your scripts seem to use the user.r and some don't THIS HAS DRIVEN ME MAD SEVERAL TIMES. I just realised that if you have an system environment variable called HOME and you use an icon on windows which has its "start in" property set to the path which holds the rebol.exe binary (instead of it being blank), then, the user.r in that path takes precedence over the user.r set in your home directory. This leads to some scripts behaving differently than others, depending on how the icon was created... And for some reason, not all icons are created equal.... I've been searching for this specific problem for two years... now its completely solved... I just tested putting another path, and since it didn't see a user.r in that path, it defaulted to the user.r in my home (like all other occurences of my scripts started under command-line or within a macro in my text-editor...) This might also be the cause for some of you having problems with steel, when opening the colorbox.r demo having the "open-library: unknown word" error, even though you have set it up... HTH -MAx --------------------------- steel project coordinator http://www.rebol.it/~steel v0.0.5 online

[2/3] from: greggirwin:mindspring at: 7-Oct-2003 8:06

mac> I just realised that if you have an system environment variable mac> called HOME and you use an icon on windows which has its "start mac> in" property set to the path which holds the rebol.exe binary mac> (instead of it being blank), then, the user.r in that path takes mac> precedence over the user.r set in your home directory. Thanks for posting that Max! Good bit of info. -- Gregg

[3/3] from: maximo::meteorstudios::com at: 7-Oct-2003 11:26

> -----Original Message----- > From: Gregg Irwin [mailto:[greggirwin--mindspring--com]]

<<quoted lines omitted: 8>>

> mac> precedence over the user.r set in your home directory. > Thanks for posting that Max! Good bit of info.

do [ send rebol-list all new info ] :-) I realize its a feature, but man, that wasn't obvious to figure out. here is some more info I found after sending the post last night: I was scanning the system/options object and realized that on start up there are four possible paths which you can collect which could hold a user.r file system/options/home --- the value of your home system variable (if set) system/options/root --- the path to the rebol.exe which launched the script system/options/script --- the path to the actual current script.r FILE system/options/path: --- Seems to holds the what-dir rebol value. It can be forcefully set in the windows icon by specifying the "start in" parameter or points to the script's path otherwise. but note that in any event this is a directory path not a file path, so its always different from system/options/script nonetheless. I guess in any unix shell, this is the actual directory you where in when you started the script. depending on the way you are setup and the way the icon was built-up (by windows at install, by copying a shortcut, or by creating it by hand) any of these paths could contain a valid user.r file. HTH ciao! -MAx ------------- Steel project coordinator http://www.rebol.it/~steel

Notes

Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted