World: r3wp

It's set in this snippet of code in %gfx-object.r

set [font-serif font-sans-serif font-fixed] any [
	select [
		1 ["CGTimes" "CGTriumvirate" "LetterGothic"]
		2 ["times" "arial" "courier new"]
		3 ["times" "arial" "courier new"]
		5 ["baskerville" "zurich" "courier10 bt"]
	] system/version/4
	["times" "helvetica" "courier"]
]

Use this to determine which [scaleable] fonts are available:

			fonts: copy []
			call/output "fc-list" s: copy ""
			s: parse/all s ":^/"
			foreach [fn style] s [
				all [
					not find fonts fn

     (size-text make face [text: "A" font: make font [name: fn size: 10]]) 
     <>

     size-text make face [text: "A" font: make font [name: fn size: 12 
     style: 'bold]]
					insert tail fonts fn
				]
			]

How does the 'browse' command in REBOL now which browser to open 
a URL in? I can't seem to get it to open any browser at the moment.

know

Windows or Linux?

Oh ... you have to define which browser for Linux

Yes, in Linux. How do you define the browser?

Barik: replace browse with
browse: func [
    "Open web browser to a URL or local file"
    url [url! file!]
] [
    if file? url [url: to-local-file url]
    call join "xdg-open " probe url
]

Ahem, maybe even without the probe :):
---
browse: func [
    "Open web browser to a URL or local file"
    url [url! file!]
] [
    if file? url [url: to-local-file url]
    call join "xdg-open " url
]
---

I see. So basically override the native browse function with something 
else.

I don't remember when, but the SET-BROWSER-PATH function was removed 
at some point.

i think that BROWSE is calling "netscape" or something like that... 
so it's also possible to create a shell script with that name.

R3's BROWSE is currently calling "open" on Linux, as far as I know. 
It should probably call "xdg-open", until then, symlinking xdg-open 
to e.g. /usr/local/bin/open should also do as a workaround.

wasn't "SET-BROWSER-PATH function was removed at some point." that 
to stop non pro users accessing call functionality?  And if so, it 
should now be reinstated.

I think that's also about the only reason why BROWSE is a native 
at all. With CALL generally available, I think BROWSE should really 
be a mezz.

I can't seem to make user.r or rebol.r execute on startup on Linux

There's some kind of REBOLHOME environment variable that you need 
to set to the directory containing those files, iirc. Don't remember 
the exact spelling, it might be REBOL-HOME or something.

It would only execute on startup of /Core, /View, /Command or /Command/View 
though, not /Base, /Pro or /Face.

This is all R2 of course.

I don't have any environment variable set, and my user.r is running 
fine in ~/.rebol/view/user.r (for View 2.7.6)

Guess I don't recall correctly :(

Wait, that is the HOME directory. That is a fallback that is checked 
after looking for REBOL-HOME.

And the last fallback is the current directory (on Windows, someone 
should test this on Linux). Not very secure.

It seems env. variables can't have - on linux? I tried REBOLHOME 
and REBOL_HOME without lucj so far

Unfortunately R2 only does the search for %rebol.r and %user.r once, 
not once each. This means that you can't have a %rebol.r in REBOL-HOME 
and a %user.r in HOME, so it's not very secure or multi-user friendly. 
Fixed in R3 though: %rebol.r is only loaded from the same directory 
as the executable, nowhere else, no environment variables necessary.

Apparently it's supposed to be spelled REBOL_HOME, and it needs to 
be a full path.

I can't get anything to run today as it is supposed to :/

I tried every combination I could think of

export REBOL_HOME=/usr/share/cheyenne/ (this is how I set variable, 
and without _ and without export and as string)

quite the opposite for me ,    ;-P

(running stuff today ;-)

Which version of REBOL? Which type of program (/Core, /View, etc.)?

REBOL/Core 2.7.6.4.2, debian linux (same with rebpro) .. it works 
in in view and core and rebpro on windows

I don't want to steal your time any more.. I will try this again 
.. sometimes when you return to the problem after a whike you solve 
it imediatelly

/Pro executes the startup scripts? Didn't expect that to work...

it does

on windows

I'm so glad we fixed this stuff in R3. R2's behavior sucks, even 
when it works.

I am having all this because I want to run source version of cheyenne 
 on linux. So now that I can do all those mezz/prot files set-net 
works, I added those do-s at the start of cheyenne.r and in includes 
it but when I load the page I still get "Set-Net not provided." http://www.invoice.ly/manage/sign-in.html
. My asumption is that because cheyenne starts multiple workers those 
workers didn't include/do all the mezz/prot files so that's why warning 
still happens event though if I halt the main cheyenne.r it has this 
included now. Thats why I wanted to add user.r to rebol so hopefully 
worker processes would load that too.

(the page didn't work before because I was hacking the server/now 
does)

Sorry folks, I am still at this.. how to autorun user.r rebol.r on 
linux with rebol/core (REBOL/Core 2.7.6.4.2)

to not do something stupid wrong. I created a user.r file with REBOL 
[] print "123456" . 
- I put it in same folder as rebol executable
- I put it in ~/.rebol and ~/.rebol/core
- I put it in the folder where rebol script is that I run
- I set REBOLHOME and REBOL_HOME to these 
  - export REBOLHOME=/usr/share/cheyenne/
  - export REBOL_HOME=/usr/share/cheyenne/
  - export REBOL_HOME="/usr/share/cheyenne/"
  - export REBOLHOME="/usr/share/cheyenne/"
  - export REBOL_HOME=/usr/share/cheyenne
  - export REBOLHOME=/usr/share/cheyenne
  - export REBOL_HOME="/usr/share/cheyenne"
  - export REBOLHOME="/usr/share/cheyenne"

I don't know what else I could try

I looked at rebol --help if there was some commandline option for 
this and it seems it isn't

so user.r is not loaded at all?

it doesn't print 123456 when I start. I am a little insane on all 
this, so at the end it will probably some very stupid mistake on 
my part

don't know the answer ... but just alter cheyenne.r to run your user.r 
script

I did, but the "Set-Net not.." was still on page. I assume because 
cheyenne starts multiple processes and those didn't load mezz and 
prot needed for set-net ? That is at least my assumption , because 
in cheyenne.r process the set-net then worked (I added halt ant tried 
in commandline), but page still has "Set-Net..."

set-net message is printed, because it is printed even if you start 
bare-bones rebpro kernel. This is imo a bug. But - couldn't you use 
other kernel?

or just temporarily - use core or view, those contain freed /library 
component now, no?

since you're running core, it doesn't need to load protocols