World: r3wp

I don't know the answer, Henrik, but since you mention it, I really 
think that the act of moving a file should be invoked by a function 
named something like "MOVE" or "MOVE-FILE", regardless of whether 
its implementation in the OS is by a "rename" function.

Anton, I haven't tested it under Windows though, so it could be a 
Linux/OSX side effect since rename usually equals move here.

Yes, POSIX rename can do moves:
http://en.wikipedia.org/wiki/Rename_(C)

but I agree that a rename should behave identically under all OSes 
and that move should be a separate function.

Post it as a question for Carl. I imagine it's an implementation 
side effect.

I think I know what the trouble is - it's not easy to know whether 
a host OS rename can support move or not. Therefore rebol can't choose 
beforehand between rename and copy+delete.

A workaround to that might be to try the rename first and see if 
it works (does not return an error message), but that adds complexity 
and performance problems. It could be done once at rebol startup 
in a temp directory, though it still seems a bit messy.

(The real solution seems to be to go back in time and define POSIX 
rename and move properly.)

anyone have an idea on when and why exactly system/options/script 
is none? I'm running a simple script in OSX, and it seems to always 
return none.

It is none when you are running at the top level interpreter.

In theory, it shouldn't be none during the running of a script.

not sure I understand why that is so

well, it is none here in my tests. rather useless, I think.

When you are running the REBOL interpreter straight, you are not 
running a script, so it is none. This can be useful to know.

by straight, you mean, I'm typing system/options/script in the console? 
because that's not what I'm doing. I'm running a script that probes 
that path and it returns none.

or do you mean, it returns none, when you say "do %script.r" ?

rather than "rebol -qs script.r"?

Yes.

You probably want to be looking at system/script instead.

system/script doesn't tell the name of the script.

I had hoped to be at any time able to identify the running script 
by filename

I believe that is what the file: header field is for.

the trouble is that the header information may not be correct

and File: also says none

You set the File: header in the script. For that matter, since the 
check of the script settings is specific to the currently running 
script, you have to add them to the script anyways, so why not correct 
the header while you're at it?

Another interesting one is the Content: header. Try this script:
REBOL [content: true] print mold system/script

still returns none.

but my issue is that I have over 100 scripts for this project. there 
might be an error in one of them, if I forget changing the header 
when cloning a script. If it really is impossible for rebol to determine 
the script name (which I highly doubt), then so be it, but it's inconvenient 
not to have the script name available at all times.

I said Content: would be interesting, not that it would solve your 
problem.

It is currently impossible to determine the filename of an inner 
script unless you have stored this information somewhere. For that 
matter, if there is an error in a script, you would only be able 
to get the name of the running script. If the error is in a function 
created by a script that is used after the script is finished executing, 
there is no way to determine which script the function came from 
without storing that information somewhere ahead of time.

The value system/options/script refers to the script the interpreter 
was started from, if any.

I see the issue, but I'm not sure it's unsolvable. It seems strange 
to me that you can't pass a script to DO as an argument, and then 
not have that filename stored somewhere. If multiple scripts are 
DO'ed or LAUNCH'ed under that script, then append them to a block 
until the script is finished and then remove it again, when that 
script is done. system/script/parent provides similar functionality, 
except, it does nothing to track the true filename, but only the 
header which may hold incorrect information.

I think it would be worth tracking the filename in R3. Don't want 
to mess up R2, if it is a big problem to implement here.

It's system/script/header that stores the header of a script - parent 
stores the system/script object of the calling script.

Seriously though, it should be simple to just write a loop that flags 
all scripts in a directory that have missing or incorrect File: headers.

yeah and run that every time a script is renamed and perhaps also 
when an enduser gets a hold of the script. nope, it's too errorprone. 
I can see this won't be fixed, but I still think it's a missing feature. 
gotta go spend a couple of hours fixing this. :-)

For that matter, the mapping of bugs to scripts is not an easy task 
if you are using library scripts. If you are just doing scripts for 
effect, system/script would make sense. If you are doing scripts 
to load functions that will be run later, the script file name would 
map to the name of the script that is running when the function is 
run, rather than the script that was curent when it was being created.

If I have a block of datatype shouldn't I be able to do?:

find blk datatype!

Yes, you can do that:
>> find [a 1 3.0] decimal!
== [3.0]
>> find [a 1 3.0] integer!
== [1 3.0]
>> find [a 1 3.0] word!
== [a 1 3.0]

yeah I know that but not datatype!

Oh wait, I didn't get your question

in other words what if the blk has the following:

blk: [string! 2 4 5 6 integer! 7 8 9 decimal!]

After checking, I got this:
>> find [1 integer!] datatype!
== none
; This is right
>> find reduce [1 integer!] datatype!
== none
; This shouldn't happen

Yeah that is the problem I see.

I would think we would want to be able to find out if a block contains 
a datatype given that we might not know what the datatype is if it 
is populated dynamically.

The parse equivalent doesn't work either:
>> parse reduce [1 integer!] [to datatype! x:] x
** Script Error: x has no value
** Where: halt-view
** Near: x

Yeah I know I ran into that problem already as well.

I haven't seen anyone put actual datatypes into blocks before; normally 
people just put the datatype words in as keywords. I wonder if this 
bug is the reason why.

Could be.  I use it in TRETBASE

I use it in TRETBASE to define the datatype of each respective field. 
 It saves time and performance cost.

Perhaps you could use the datatype words as keywords instead.

I had it that way previously.  Now in my last release I do a save/all 
to serialize though and this has been a big boost for TRETBASE.  
I really don't need the find blk datatype! feature at this point 
but just pointing it out.