World: r3wp

and to get and set the current directory. CD ?

Anton: my comment may be dismissive, but the point I'm making is 
that that is just my opinion, I'm not sure why I should be forced 
to "like" a heredoc syntax :) I understand that it is very handy 
on occasions, but the price is a ugly script, which I'd rather not 
pay if I can avoid it easily enough (for example, if I were generating 
a lot of PHP or JS, I would just build a dialect to do that, instead 
of using strings). Again, though it's funny for me to have to repeat 
it again and again, this is just IMHO, Robert should be free to do 
things his own way, and if REBOL can provide a syntax for heredocs 
without creating other problems I'm fine - I'll just avoid it (and 
I'll hope not many people start using it ;)

Anton - just simple "path" does it ...

Some commands work, some don't call "path" does not work, call "help" 
works, etc.

Gabriele, I had a look at a few of the heredoc formats and some of 
them do look quite ugly. I admit that I actually haven't used heredocs 
myself yet, only come across a few snippets here and there recently, 
so I guess I don't have much experience with them yet, and can't 
tell what problems they may cause. My initial thought was that they 
would be a good idea, since you could just paste foreign code straight 
into your script.

Or you could use an editor which hides all the ugliness

Pekr, commands like dir and path are built into cmd.exe - they aren't 
separate programs. So CALL "cmd.exe /c dir" should work.

At a command prompt, call cmd /? to get help on cmd.exe and its commands.

Brian - "help" does it too ...

Brian - what's the mess with intermixing cmd shell, and rebol one? 
See above output. And why do I need to hit enter to get back to rebol 
console?

R2 intermixed the cmd shell with CALL - with R3 you do that manually 
if you need to.

As for your other question, look at this:

>> call "cmd.exe /c dir"
== none

>>  Volume in drive E is APPS
 Volume Serial Number is 7845-7730

 Directory of E:\REBOL\2.100

01/14/2009  03:17 PM    <DIR>          .
01/14/2009  03:17 PM    <DIR>          ..
01/14/2009  03:24 PM    <DIR>          base
01/15/2009  12:17 PM    <DIR>          updates
07/12/2009  03:08 PM                56 blah.txt
02/25/2009  08:09 PM               492 user.r
03/02/2009  10:22 PM    <DIR>          work
04/09/2009  08:41 PM                66 test.r
06/13/2009  12:09 AM                28 mod1.r
06/13/2009  12:09 AM                28 mod2.r
06/13/2009  12:10 AM                47 mod.r
08/10/2009  08:39 PM    <DIR>          plugin
08/13/2009  03:35 PM           613,376 r3.exe
08/13/2009  07:08 PM    <DIR>          extension
08/13/2009  08:46 PM            20,480 ext-test.dll
               8 File(s)        634,573 bytes
               7 Dir(s)   4,893,769,728 bytes free
1 + 1
== 2


I did that 1 + 1 to show that I didn't have to hit enter to get back 
to REBOL. You only have to hit enter to see the prompt. The extra 
>> above the dir outpt is the result prompt that you aren't seeing 
below. This is because CALL on Windows returns immediately, rather 
than waiting for the called process to finish its work, including 
its console output.

Keep in mind that this behavior may change in the future: CALL is 
in the host code.

how do I trap the console output into the variable for e.g.? something 
like str: call "cmd /c dir" does not make it ...

call/output "cmd /c dir" my-var

I think

there is no refinement with R3 call :-)

well, I guess in R3 you don't do that. :-) Forget my response.

the only chance, probably, is to catch console port?

does 'echo work?

Call is pretty unusable with R3. I have to say, that some ppl could 
already move to R3, but we have few showstoppers:

- call - really bad situation ....
- missing networking protocol 
- missing CGI mode

- DB access ... now we can proceed with extensions for SQLite, but 
not sure. If call would work at least, we could at least call sqlite.exe 
;-)


Unless those issues are fixed, R3 will be in alpha stage, and my 
opinion is - absolutly unnecessarily ...

echo? who want to work with file? Theat is weird. I want call being 
fixed, or it is good for nothing ...

I thought you wanted debug output. Otherwise wait until CALL is fixed.

Pekr, what are yhou trying to do?

Sounds like Pekr is trying to capture the output of a directory listing 
in R3, is that correct?

anyway Pekr, just use:

call "cmd dir > somefile.txt"

then you can just read the file back into a string.

Paul - correct ....

Paul - I know that is an option ... but what is it good then to get 
'call output into console, if it can't be even easily captured into 
a string?

Isn't that a limitation of R3?

dunno. As an interim solution, you suggestion is good enough .... 
I'll wait for 'call being fixed/enhanced ...

Yeah, we will have to wait and see if they develop 'call further.

CALL is in the host code. We'll fix it when the host code is released.

Can anyone tell me how to view an image with r3?

Is it me, or the example to read a dns address is broken ???
>> print read dns://www.rebol.net

I get

make port! [
    spec: make object! [
        title: "DNS Lookup"
        scheme: 'dns
        ref: dns://www.rebol.net
        path: none
        host: "www.rebol.net"
        port-id: 80
    ]
    scheme: make object! [
        name: 'dns
        title: "DNS Lookup"
        spec: make object! [
            title: none
            scheme: none
            ref: none
            path: none
            host: none
            port-id: 80
        ]
        info: none
        actor: make native! [[]]
        awake: make function! [[event][print event/type true]]
    ]
    actor: make native! [[]]
    awake: make function! [[event][print event/type true]]
    state: #{}
    data: none
    locals: none
]

Geez...

>> first wait read dns://www.rebol.net
read
== 216.240.11.203

>> first wait read dns://216.240.11.203
read
== "www.rebol.net"

A little bit obfuscated, but it works...

Nicolas, VIEW in its built in state doesn't work properly, so do 
something like this:

>> load-gui
>> a: load http://arkandis.com/images/blog/google.gif
>> b: make gob! [image: a]
>> view b

thanks Henrik

(This will be much easier in the future, I hope)

I see Carl is going to add Read/Text functionality with UTF conversion. 
 That is going to be sweet.  That alone should begin to make REBOL3 
useful.

What is the point of /any on dir?

As far as I can see, as soon as you add a wildcard char, dir?/any 
always returns true

    dir?/any %ddddff.file
    == false                              ;; no wild ==> false
    dir?/any %ddd?dff.file
    == true                                ;; wild ==> true
    dir?/any %ddd*dff.file
    == true                               ;; wild ==> true

    dir?/any http://www.test.com/file.html
    == false                             ;; no wild ==> false
    dir?/any http://www.test.com/*.html
    == true                              ;; wild: true

looks like a bug

definitely a bug. please add it to curecode, thanks.

It's already there - add your code as a comment on the existing DIR? 
/any ticket.

The ticket in question is #649.

Thanks -- had not seen that ticket.

I proposed change of command! to external! extern! or something like 
that. We will see, if Carl reacts to that ....

The word "command" is more specific, and better expresses what you 
are referring to.

I have heard at least one other opinion, that name "command" might 
be too worthy to waste on simple and signle thing as wrapping merely 
a funciton call. Of course even Devices have commands, but those 
are not probably rebol level related and influence nothing ...

You mentioned that "command" would need to be reserved for devices. 
There's no reason that devices couldn't use the existing command! 
type. It's very flexible.