World: r3wp

It would just convert a "view-script.r" link into a "download-a-script.r" 
link, so that users take, for example, the money.r link and type 
this into their console:


 do get-rebol.org-script http://www.rebol.org/view-script.r?script=money.r

I fire up rebol consoles everywhere .. so I would need to have that 
function everywhere. Much simple to fix the source.

Simpler for _you_ if we change the source; but perhaps not simpler 
for _others_ who expect it as it is.

Another even easier solution (easier for me, anyway:)


....In theory, REBOL does hunt through verbiage looking for "REBOL 
[" and starts executing from there.


So If the R2/R3 interpretor also de-escaped strings like < then 
the view-script would be executable.
Why not curecode/RAMBO that as a request!?

My 2 cents:  I like the way the links work now, but I also echoed 
Graham's request when I initially started using rebol.org.  Is it 
possible to hide a copy of the actual (downloadable script) code, 
at the top of the web page, so that it's executable by REBOL, but 
not visible by those using a browser?

Nice idea. But there is no foolproof way that does not leave someone 
with a screenreader seeing (or not seeing) double.

Also, may mess things up for (the few I hope) people with early CSS 
implementations in their browsers.


I'm still looking for an argument to convince me that one URL should 
serve two separate resources depending on user-agent sniffing.

You want an argument??  Let's step outside and discuss this!

:/)

I'm seeing very strange line endings in scripts downloaded from the 
script library.

I am downloading http://www.rebol.org/download-a-script.r?script-name=test-framework.r

Did you see such line endings in other library scripts, or do you 
think it is just me doing something strange?

I get it for all scripts, AFAICT.

Just downloaded 2 different scripts at random, same weirdness.

Now let me see what's actually going on.

Okay, I get a script library header inserted, which uses CR LF to 
terminate lines.

Then the rest of the script uses CR LF as well.

But at the very end, there's a trailing single LF.

Ah, and there's a single leading LF as well, right before the script 
library-inserted header.

We've had all sorts of fun trying to get the line endings to work 
for everyone.


There's a magic, undocumented URL parameter you can add to the URL 
that might make a difference on your platform.

It is MODE=????


I'll just cut'n'paste the comment from the download-a-script source... 
it may help explain it:

;; mode=windows -- the default. Makes LF or CR into CRLF
;; mode=binary  -- sends file as binary
;; mode=carl    -- saved and reloads file first as Carl thought
;;                 this would fix the problem
;; mode=text    -- the old default. Works in most cases. Just
;;                 prints the file (so sends whatever line
;;                 terminations work on the platform the library
;;                 is running on.

But we (s far as I remember) accept contributions with whatever line 
endings they come with, so some may be pre-messed with.

Yeah, unfortunately currently break line endings predictably.

That should be: currently you* break line endings predictably :)

Due to the erroneously inserted leading/trailing LF.

Just lookin at the source......We do edit line ending to try to get 
them consistent.
Perhaps consistent, but wrong!

It's not really the editing of the script per se, something is wicked 
in the surroundings.

The aim to to end up with CRLF in all defaiult cases.

Yeah, and you are achieving that.

But somewhere on the way something inserts a single LF as the very 
first and very last character.

Wait, I'll upload a hexdump of what actually goes over the wire.

Thanks....That'll help.

There you go: https://gist.github.com/c3ef82f0b05dc1aea045

You see the `0a` at very start and end?

Yes, thanks.

That is most certainly a bug.

Inside
 those LFs, everything is nicely and consistently CRLF'd.

Basically it looks like you've some PRINTs somewhere you'd rather 
want PRINs :)

Certainly a bug .... and a bit of a mystery. not obvious where they 
come from (not yet, anyway)
The dev server does it right, live does it wrong.

Hmm, if by "the dev server does it right" you mean the dev server 
has CRLF instead of LF at the start and end, I can tell you what's 
going on.

Yes I do.....What's going on!?

But in my opinion, "right" would be _no_ extraneous whitespace at 
the start/end.

The dev server is running Windows, the live server is running Linux.

And the download-script script generates the output by using PRINT. 
Which leads to a terminating LF on Linux and a CRLF on Windows.

Switch the output generation to use PRIN instead (and add a `prin 
crlf` at the start/end if you really want the extra whitespace), 
and it should be fine.

Possible.....But if you add &mode=binary, then do not do a PRINT.
We do this instead
   set-modes system/ports/output [binary: true]
    insert system/ports/output script-source
And that also looks wrong on live.

Yeah, because that's not where trouble occurs.

Most likely you have a PRINT before and after that.

Or, depending on where the SCRIPT-SOURCE in the above comes from, 
you do one unchecked reform/rejoin somewhere.

We have a print for the HTTP headers, prior to chaning modes....that 
may be part of the problem.

Maybe even in the upload process, so that the scripts are already 
stored on disk with the leading/tralinig LF.

Yeah, the HTTP header print sounds like a very plausible source.

Okay....let me look at it.