World: r3wp

Seems like, it's the CHANGE command, that rename it.

Reading the source for RENAME, it rename the file by changing its 
name in the directory file. And this doesn't work for some reason 
with USB sticks under OS X using R2.

it does not work for me under Windows either. seems like a port bug.

Cyphre, did you test with R2 or R3?

and yes, it is at the CHANGE on the port, that fails.

I tested with R2...no problems here. Henrik, maybe it has something 
to do with the fact you are emulating the Windows under OSX?

the CHANGE works, if I do it by hand. Then I can rename the file.

Cyphre, Robert reported this from a customer, who I assume is running 
Windows natively.

hmm, hard to say then.

testing one more timing issue...

does not help with timing, but I can still perform CHANGE outside 
the rename function

It works, if you don't give NEW as full path.

I see... testing that

that's how the HELP is telling you ;)

new -- new name (not a path)

:) funny it works on HD though.

Are you suggesting "RTFM!" ? ;)

ok, thanks... testing fix.

LOL, well, I remember I have been bitten by this many years ago so 
from that time I'm using it according to the help ;)

my excuse is that I could not probe the input values for RENAME :-) 
but true, this should not be standard behavior.

Best solution is probably, that it should just work with both ways.

rename capabilities in file handling do not normally allow paths 
to be used (in the OS itself).  otherwise these are a called 'move 
file operations. 


e.g. if you try using paths with rename in the DOS shell, you get 
errors.

John, refinements that can't be translated to path use can be used 
for other reasons in other dialects. REBOL isn't just DO.

When using refinements in dialect contexts where they will be translated 
from paths, it makes no sense to use them, but that is no reason 
to exclude them from the datatype. (That was the official decision 
for R3 when meijeru asked this question in CureCode here in mid-2009: 
http://issue.cc/r3/743)

Sorry, the actual decision was in a different ticket, but the discussion 
was in #743. Sometimes it can be a problem to make multiple tickets 
for the same problem, as opposed to different parts of the same problem; 
it can get a little confusing. Stuff like this is why we rearrange 
tickets more now.

It seems to me to be a sought for explanation of some inconsistency 
in the language. Also from the discussion in that ticket.

Paths <> lists of refinements. It's inconsistent in inconsistent 
situations. Refinements are supposed to be useful for more than function 
specs.

Sure, but do you believe, refinements like /1, /1a and /1.2 are made 
on purpose or just a side effect on how it's implemented?

Refinements like those would be useful as keywords in dialects, for 
instance.

There are a lot of values that can appear in paths that don't translate 
to refinements. Paths and refinements are only related in function 
call syntax; otherwise they are not related.

I don't buy it, as I could just use #1, #1a and #1.2.

There were a lot more tickets related to this, which are unfortunately 
difficult to search for because different people use different terminology 
for this problem, so they don't find the previous tickets. What I'm 
summarixing here is the final decision. I don't remember when that 
decision was made, but I remember the reasoning.

ok

john, have alternate datatypes for dialects is VERY good.   issues 
have long been ignored becaue people forget they exist.

have=having

If this is the case, then I don't understand, why refinements don't 
just act like strings without spaces.

Then you would be able to produce all kinds of refinements, like 
/:1

it just depends how they're coded internally, I guess.

its possible their container doesn't allow it.

I also think that refinements are sort of meant to be path parts, 
so it makes sense to make them compatible with paths directly.  though 
I guess one can give examples of path incompatible refinements.

I still think, these refinements are not on purpose. :-)

Check this part in the Core manual: http://www.rebol.com/docs/core23/rebolcore-16.html#section-3.7

Max, there are many, like /(1)

Anyway, it's good to be aware of these things, also for the programmers, 
who develop alternatives to REBOL.

We are still making tickets related to word and refinement inconsistencies 
for R3 (or at least I am, when I find bugs in the syntax while I'm 
trying to reverse engineer the syntax docs). While the numeric refinement 
issue is settled, there are other issues that haven't yet been discovered. 
Most of the syntax problems are related to scanner precedence. All 
of the word and path datatypes can be constructed with characters/contents 
that don't really scan the same way in literal syntax, but it is 
not really considered an error. Datatypes are meant primarily for 
in-memory use - their syntax is secondary, and in many cases the 
literal syntax only covers a subset of the possible values.

The original design of REBOL has many many great ideas. It's just 
the implementation, that isn't good enough in many cases. With these 
new explanations, the whole thing just get more complex, which isn't 
good. My view is, that it's better to stick with a simple design 
and work on getting that implemented.

The problem is that believing the original design to be simple is 
what got us into this mess. The original design was an overview, 
and the details were unspecified. The overview was simple and still 
is, but now we are looking at, documenting and refining the details.

For a scanner (also called lexical analyser), I can recommend studying 
the UNIX command lex. The code produced might be a bit bigger in 
size, but it's fast and produce good result.

I've used lex, and many other compiler generators over the years, 
and yes, it's helped with the REBOL syntax documentation discovery. 
However, it might help you to know that the REBOL lexical analyzers 
and parsers are hand-written, not generated. This is why TRANSCODE 
in R3 and LOAD in R2 are so fast, but it is also why it is so tricky 
to resolve syntactic precedence bugs quickly.

Yes, I've kinda guessed, it was hand-written. I allow me to doubt, 
it's faster, as actual measurements would be needed to compare.

But it's most likely smaller in size, the code for the scanner.