[REBOL] RFC: Split-Path Re:
Hi, what I will not like is this: split-path %./a == [%./ %a] split-path %a == [%./ %a] ,because the latter may mean something slightly different, than the former. I would prefer the following instead: split-path %./a == [%./ %a] split-path %a == [none %a] (or something similar taking the difference into account) My reason is this: if I write something like: include %a.r I don't mean the same as include %./a.r instead I want Include to search the desired file in its path in the former case and pick the file in the current directory in the latter case. Regards Ladislav - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 05, 2000 6:24 PM Subject: [REBOL] RFC: Split-Path Request for Comments on Split-Path Revision --- Issue: Should split-path be changed? Discussion: Split-path currently returns the last element of a path, regardless of whether it is a file or directory. That is: split-path %a/b/c == [%a/b/ %c] split-path %a/b/c/ == [%a/b/ %c/] This allows writing iterative code like: path: %/a/b/c/d == %/a/b/c/d while [path %/] [set [path file] split-path path print file] d c/ b/ a/ (Note, this example also shows another problem with split-path... in that it has no regular iterative termination condition. If you provided a path of %a/b/c/d this code would loop forever, because the path would reduce to %./ not %/ ) However, you would normally think that a split path type of function would separate the directory path from the file name itself. This would take %a/b/c/ and return a directory path of %a/b/c/ and a file of none (not a file of %"", which is a file with no name). However, you loose the iterative "peeling" shown above. Since split-path has other issues that we will be fixing very soon, I would like to get your comments on this issue soon. Do not consider legacy with existing code base. It is better to correct this problem today, rather than when the child is 20. -Carl "Dad"
[REBOL] parse / space Re:(2)
parse "LIB1 " ["LIB1"] == false parse "LIB1 " ["LIB1" to end] == true parse "LI B1 " ["LIB1" to end] == false result says, could parse full string, or there is a rest, IMO. Volker Am Mit, 05 Apr 2000 schrieben Sie: Hi bciceron, The short version is: I believe it's a bug. The long version: space at the begining of string: parse " LIB1" ["LIB1"] == true space smack in the middle of token: parse "LI B1" ["LIB1"] == false ;- Elan [: - )] -- Volker
[REBOL] parse / space Re:(3)
Hi Volker you wrote: At 12:41 PM 4/6/00 +0200, you wrote: parse "LIB1 " ["LIB1"] == false parse "LIB1 " ["LIB1" to end] == true parse "LI B1 " ["LIB1" to end] == false result says, could parse full string, or there is a rest, IMO. that is correct and undisputed. According to the documentation parse ignores spaces unless used with the /all refinement. In the example (1) parse " LIB1" ["LIB1"] == true I demonstrate that parse w/o /all refinement indeed *ignores* spaces, at least leading spaces. The example (2) parse "LIB1 " ["LIB1" (print "found it")] found it == true demonstrates that parse w/o /all also ignores *trailing* spaces. If we leave away the expression (print "found it") and simply do (3) parse "LIB1 " ["LIB1"] == false the trailing space is *not* ignored. Why all of a sudden is the trailing space not ignored? Should it be ignored? My position is: In example (3) the trailing space should be ignored, because the pattern matching part of the rule in (3) is no different from the pattern matching part of the rule in (2). Since we are doing the same pattern matching against the same input stream we should be getting the same results. Should (2) return the same results as (3), or should (3) behave like (2)? Since we are using parse without the /all refinement, and parse ignores spaces without the /all refinement, the trailing space should be ignored in (3) as it is being ignored in (2) and the string should be considered completely parsed. My guess is that (3) does not act like (2) because the termination code for parse is incomplete in situation (3). How do (2) and (3) differ? In (2) the rule block is *not* exhausted with the "LIB1" pattern. In (3) it is. When parse encounters the trailing space, it still has something remaining in the rule block, namely (print "found it"). This means that empty? rule-block at this point will return false. Since there's still something remaining in the rule block, parse continues to evaluate the rule-block. In doing so, it returns to a part of the parse code that is ignore-spaces-aware. In (3) the rule block is exhausted with the "LIB1" pattern. empty? rule-block returns true and parse returns false because it has not reached the end of the input stream, but it has already exhausted its rules. That is an incorrect termination, since we are using parse without the /all refinement, and parse should determine whether or not all remaining characters in the input stream are spaces, before it decides whether to return true or false. If only spaces remain, - and in our example that is the case - parse should report true, just as it did in (2). ;- Elan [: - )]
[REBOL] bug ? parse / space Re:(2)
[EMAIL PROTECTED] wrote: but i cannot change the input string to parse. so if it is a bug can we get a fix, and how to workaround it ? parse/all your-string [lib-name any #" " lib-type] HTH, Gabriele. -- Gabriele Santilli [EMAIL PROTECTED] - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[REBOL] CGI problem Re:(6)
Hi Rachid, Those were the words of [EMAIL PROTECTED]: Hello, What you _could_ do, is something like #!rebol -cs REBOL[] secure [net quit] This would give all access to files, but none to the web. Why would one do that? Can it still process a form? How does this exactly limit Rebol? Well, I just tried to answer the question, in te way I understood it. I think GET should still be possible, I am not sure about PUT. (I have written one test cgi up to now, so am not exactly a profi in this field). Thinking about it, the better solution would be to add 'secure to %user.r, know you could be sure, that none of your cgi's ever sends a mail with your files attached, or something like that ... regards, Ingo -- _ ._ ingo@)|_ /| _| _ We ARE all ONE www._|_o _ _ ._ _ www./_|_) |o(_|(/_ We ARE all FREE ingo@| |(_|o(_)| (_| http://www.2b1.de/Rebol/ ._| ._|
[REBOL] [REBOL]CGI script problems on Linux
I have written a test cgi script works as
expected on my own machine using Person Web
Server.
It's acting strangely on a linux server using
Apache server.
On PWS, I see for content:
hello world from rebol script
as I would expect
On the Linux Server, the only content I see is:
REBOL
I am enclosing first the SOURCE of the content
from the Linux server, and then the script itself.
thanks in advance.
tim
Here is the source of the content as posted
when I run it:
; content source below
REBOL options script arguments
All fields are optional. Supported options are:
--cgi (-c) Check for CGI input
--do exprEvaluate expression
--help (-?) Display this usage information
--nowindow (-w) Do not open a window
--quiet (-q) Don't print banners
--script fileExplicitly specify script
--secure level Set security level:
(none write read throw quit)
-s Shortcut: no security
+s Shortcut: full security
--trace (-t) Enable trace mode
Examples:
REBOL script.r
REBOL script.r 10:30 [EMAIL PROTECTED]
REBOL script.r -do "verbose: true"
REBOL --cgi -s
REBOL --cgi -secure throw --script cgi.r "debug: true"
REBOL --secure none
Content-Type: text/html
HTMLheadtitle hello world /title/head
h1hello world from rebol script/h1/body/html
;===
;now, hello-world.r script source below
;
#!/usr/bin/rebol -cs
REBOL
[
Title: "Test Rebol CGI script"
Date: 28-Mar-2000
File: %hello-world.r
Purpose: {just to see if we can get anything to work}
]
; functions
;
fprint: func [fp1[port!] value]
[ append fp1 value ]
;
write_to_file: func []
[
either equal? system/options/cgi/server-name none
[return true]
[{else}return false]
]
;
init_output: func[fname[string!] /local fpl]
[
either write_to_file
[
file_name: make file! fname
fpl: open/new/write file_name
]
[fpl: system/ports/output]
return fpl
]
;
text_html_header: func [fp1[port!]]
[either write_to_file [][fprint fp1 "Content-Type: text/html^/^/"]]
;
html_header: func [fp1[port!] title[string!]]
[fprint fp1 reform ["HTMLheadtitle" title "/title/head" newline]]
;
html_footer: func [fp1[port!]] [fprint fp1 "/body/html^/"]
;
fp: init_output "hello.htm"
text_html_header fp
html_header fp "hello world"
;
fprint fp "h1hello world from rebol script/h1"
html_footer fp
either write_to_file [close fp][]
[REBOL] [REBOL]CGI script problems on Linux Re:
Hi, I don't know if it's the problem, but as you run the script on PWS it may have MS-DOS end-of-line characters. make sure the first line starting with #! does end with LF alone and not CRLF, because Linux does not like it. -- Michal Kracik
[REBOL] Newsletter via Procmail
My web host supports REBOL and limited procmail but not SMTP (direct outgoing mail). I want to create an opt-in/opt-out subscriber e-mail newsletter with REBOL that runs through their procmail. What I need are some simple REBOL commands to test sending messages through procmail. I know next to nothing about procmail and would rather things stay that way if they can. They do support the procmail-based "SmartList" system for discussion groups. So in principle REBOL could interface to procmail and accomplish the same thing. In may case I don't need a discussion group, just a newsletter. I am learning a lot about REBOL on this e-list and appreciate all inputs. Sincerely, Mark Evans
[REBOL] saving and loading objects
I am stuck. I have followed along with the "Simple Database" contained in the Rebol how-to.html file, but I can't manipulate the header object that save/header load/header creates. I want to make changes and save the data back, with the header intact. Here's what I have been trying out: 1. I started by copying some data into Rebol (its from the how-to.html): cities: [ "Ukiah" CA 95482 "Richmond" VA 12345 "Omaha" NE 43210 "New York" NY 20202 ] 2. I saved it with a header added save/header %cities1.r cities [ Title: "City data" User_Groups: "PDX Vanc" ] The cities1.r file looks like this: REBOL [ Title: "City data" User_Groups: "PDX Vanc" ] "Ukiah" CA 95482 "Richmond" VA 12345 "Omaha" NE 43210 "New York" NY 20202 3. I then loaded the file with header cities1: load/header %cities1.r 4. Testing header and data shows everything is there: header: first cities1 data: next cities1 a. inspect header probe first header [self Title Date Name Version File Home Author Owner Rights Needs Tabs Usage Purpose Comment History Language User_groups] probe header/Title "City data" probe header/User_groups "PDX Vanc" b. inspect data items probe data [ "Ukiah" CA 95482 "Richmond" VA 12345 "Omaha" NE 43210 "New York" NY 20202] 5. Now I change something in the data: change find data 12345 9 probe data [ "Ukiah" CA 95482 "Richmond" VA 9 "Omaha" NE 43210 "New York" NY 20202] 6. -- Here's where I am stuck - How can I save the data with the header information? 7. I tried a simple save: save %cities2.r cities1 cities2.r looks like this: make object! [ Title: "City data" Date: none Name: none Version: none File: none Home: none Author: none Owner: none Rights: none Needs: none Tabs: none Usage: none Purpose: none Comment: none History: none Language: none User_Groups: "PDX Vanc" ] "Ukiah" CA 95482 "Richmond" VA 12345 "Omaha" NE 43210 "New York" NY 20202 Attempting load/header results in ERROR cities2: load/header %cities2.r ** Syntax Error: Script is missing a REBOL header. ** Where: cities2: load/header %cities2.r load without refinement loses the header info, or at least puts it in a different part under cities2 cities2: load %cities2.r == [ make object! [ Title: "City data" Date: none Name: none Version: none File: no... but: header2: first cities2 == make probe first header2 ** Script Error: first expected series argument of type: series pair event money date object port time tuple any-function libr ary struct event. ** Where: probe first header2 8. Save/header with only one argument is ERROR: save/header %cities3.r cities1 ** Script Error: save expected header-data argument of type: bl ock object. ** Where: save/header %cities3.r cities1 9. save/header *almost* works: save/header %cities3.r data header buts adds words 'make object! after REBOL thusly: REBOL make object! [ Title: "City data" Date: none Name: none Version: none File: none Home: none Author: none Owner: none Rights: none Needs: none Tabs: none Usage: none Purpose: none Comment: none History: none Language: none User_Groups: "PDX Vanc" ] "Ukiah" CA 95482 "Richmond" VA 12345 "Omaha" NE 43210 "New York" NY 20202 --- I cannot find information about converting objects into blocks etc, or how to reach the values of object keys. Thanks. doug edmunds 6 April 2000 YOU'RE PAYING TOO MUCH FOR THE INTERNET! Juno now offers FREE Internet Access! Try it today - there's no risk! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
[REBOL] [REBOL]CGI script problems on Linux Re:(2)
Hi Michael: that is EXACTLY what the problem was. I'm up and running. Fortunately I am using a nifty windooz editor that lets me edit Unix LF style and still look like it's using CRLF. Notepad won't do that. thanks so much!! tim At 11:06 PM 4/6/00 +0100, you wrote: Hi, I don't know if it's the problem, but as you run the script on PWS it may have MS-DOS end-of-line characters. make sure the first line starting with #! does end with LF alone and not CRLF, because Linux does not like it. -- Michal Kracik
