World: r3wp

but apart from the error - is that the sort of thing you were looking 
for Petr?

Icarii - yes, that might help ....

oh my, how usefull is read %/, if you can't use it further dynamically?

== [%c/ %d/ %e/ %g/]


it is missing one backslash. You simply can't  do thing like foreach 
drive drives [print exists? join drive "kiosk/"]

it has to be a bug, because it is not logical - it is a result of 
'read operation, yet if you query the result, e.g. exists? %c/ you 
get 'false result. That is not imo correct.

that only probably happens under windows where the filesystem is 
so screwy

:-)

petr, no, that is not a bug.

>> read %public/www.rebol.com/
== [%index.r %docs/ %bay.jpg %view/ %downloads/]

do you see %public/www.rebol.com/   in the block?

so what you do is, for any dir,

foreach file read dir [do-something-with dir/:file]

>> print-dir: func [dir] [foreach file read dir [print dir/:file]]
>> print-dir %public/www.rebol.com/
public/www.rebol.com/index.r
public/www.rebol.com/docs/
public/www.rebol.com/bay.jpg
public/www.rebol.com/view/
public/www.rebol.com/downloads/
>> print-dir %/
/c/
/d/
/e/
/f/
/g/
/h/
/z/

Petr, my file-list stuff should be on REBOL.org.

gabriele - how does it relate to my report?

I strictly refuse following result:

>> exists? %rebol.exe
== true
>> exists? %c/
== false

both queried items are result of regular 'read function call on filesystem 
...

>> change-dir %/
== %/
>> exists? %c/
== true

still does not explain my results

what is first slash representing? It is a root-dir? Then it might 
make sense. Or is it just a syntax?

Yes, filesystem root.

then your example stands for something like following?

>> exists? join %/ %c/
== true

Yep.

so that %c/, even if being a drive assigned letter, is being treated 
as a directory here ....

hmm, ok, I will remember it, but it might confuse some ppl ....

Yes.  I think this is Rebol's way of handling Windows unique drive 
system.

Sunanda - here is one fine doc about all possible modes - http://rebol.com/docs/changes.html#section-6.2

somehow can't set-modes for directory :-)

is there a bug or what? Can copy-modes be set for directory too?

>> modes: get-modes %sqlite/ get-modes %sqlite/ 'copy-modes

== [creation-date: 2-Jul-2007/10:20:05+2:00 access-date: 2-Jul-2007/10:20:07+2:00 
modification-date: 2-Jul-2007/
10:20:07+2:00 owner...

>> set-modes %sqlite/ modes
** Access Error: Cannot open /c/!rebol/view/sqlite/
** Near: set-modes %sqlite/ modes


I simply wanted also my copied directories, not only files, to carry 
on original attributes ....

Pekr, 
>>exists %/c/
= true

... even when not in the root directory.

>> exists? %/c/
== true
>> what-dir
== %/C/Program Files/rebol/view/
>>

Petr, I'm not sure what you want. Obviously %c/ is a dir, and obviously 
it is at the root, so you have to access it as %/c/. This is called 
platform independent file paths. It's the same for all platforms.

Brock, I was confused about reading %/ and getting %c/ instead of 
%/c/, that is all. I did not regarded %/ a root, I thought it is 
just a helper, as %. is .... that dot surely is not real part of 
filesystem, is it?

I resolved it for myself by defining root: %/ and joining it with 
the result of the read, works .... new problem for me is how to set 
attributes of copied directory. Not sure why do I receive error. 
It seems like that dir would be locked or so, but not sure why set-modes 
fail. Is set-modes supposed to work with directories?

no

I reported this a couple of years ago .. it does not work

ok, thanks a lot ... it is a pity, I don't need it in fact, but found 
that possibility in docs, tried it, and it nicely works for files 
....

and is there a way to create directory not using make-dir, directly 
setting such attributes during creation process, not later?

Petr, that dot (%./) *is* part of the filesystem in most filesystems.

Can I get following solved somehow, without defining globally visible 
word?

report: does [print item]
foreach item [1 2 3][report item]

Given 'does is simply a shortcut for 'func, why not:
    report: func [item] [print item]

because I want to have clean interface to my copy-dir source target 
.....

the trouble is, that later on, I dynamically detect new drive. I 
can't know, what letter usb drive maps to. So I do:

forever [

  for each disk difference stored-disks read %/ [copy-dir source target]
]

foreach item [1 2 3] [do bind second :report 'item] may work

And I somehow wanted to have 'disk available in my copy-dir :-) Well, 
I can easily solve it via drive: disk and use drive global word in 
my copy-dir func. It is just that I was thinking if I can somehow 
magically bind to it :-)

I need it vice versa - bind item in report to foreach item ....

but no problem, I can get it working other way, I was just curious 
...

That will bind report and item to the local foreach item.

Well actually it binds print and item  to the local item.

ah .... I tried to look at it from the perspective of report function, 
and was stuck ....