Okay, I think I identified at least part of the problem. It's ugly, it's a
nasty Linux bug that you'll all want to know about if you write any sort of
shell or other script code on Linux. Basically, the #! magic in Linux doesn't
like \r \n sequences in certain contexts where it expects \n sequences. Check
out the following transcript carefully to observe what I'm talking about:
jbone@bastrop> ls -al
total 4
drwxrwxr-x 2 jbone jbone 1024 Jan 19 02:13 ./
drwxrwxr-x 3 httpd jbone 1024 Jan 19 02:13 ../
-rwxr-xr-x 1 jbone jbone 58 Jan 19 02:02 reb1.r*
-rwxr-xr-x 1 jbone jbone 61 Jan 19 02:02 reb2.r*
jbone@bastrop> cat reb1.r
#!/usr/local/bin/rebol -cs
REBOL [ ]
print "hello, rebol"
jbone@bastrop> ./reb1.r
hello, rebol
jbone@bastrop> cat reb2.r
#!/usr/local/bin/rebol -cs
REBOL [ ]
print "hello, rebol"
jbone@bastrop> ./reb2.r
The command line usage is:
REBOL <options> <script> <arguments>
All fields are optional. Supported options are:
--cgi (-c) Check for CGI input
--do expr Evaluate expression
--help (-?) Display this usage information
--nowindow (-w) Do not open a window
--quiet (-q) Don't print banners
--script file Explicitly 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
hello, rebol
jbone@bastrop> hexdump -c reb1.r
0000000 # ! / u s r / l o c a l / b i n
0000010 / r e b o l - c s \n R E B O L
0000020 [ ] \n p r i n t " h e l l
0000030 o , r e b o l " \n
000003a
jbone@bastrop> hexdump -c reb2.r
0000000 # ! / u s r / l o c a l / b i n
0000010 / r e b o l - c s \r \n R E B O
0000020 L [ ] \r \n p r i n t " h e
0000030 l l o , r e b o l " \r \n
000003d
jbone@bastrop> exit
--
The second script, reb2.r, has \r \n sequences instead of single \n
characters, and fails to parse out properly. A quick test indicates that this
problem affects all #! -invoked scripts, see the following transcript for a
bash example:
jbone@bastrop> ls -al s*
-rwxrwxr-x 1 jbone jbone 32 Jan 19 02:22 s1.sh*
-rwxrwxr-x 1 jbone jbone 34 Jan 19 02:22 s2.sh*
jbone@bastrop> cat s1.sh
#!/bin/sh -v
echo "hello, bash"
jbone@bastrop> ./s1.sh
#!/bin/sh -v
echo "hello, bash"
hello, bash
jbone@bastrop> cat s2.sh
#!/bin/sh -v
echo "hello, bash"
jbone@bastrop> ./s2.sh
sh: -
: unrecognized option
Usage: sh [GNU long option] [option] ...
sh [GNU long option] [option] script-file ...
GNU long options:
--debug
--dump-po-strings
--dump-strings
--help
--login
--noediting
--noprofile
--norc
--posix
--rcfile
--rpm-requires
--restricted
--verbose
--version
--wordexp
Shell options:
-irsD or -c command (invocation only)
-abefhkmnptuvxBCHP or -o option
jbone@bastrop> hexdump -c s1.sh
0000000 # ! / b i n / s h - v \n e c h
0000010 o " h e l l o , b a s h " \n
0000020
jbone@bastrop> hexdump -c s2.sh
0000000 # ! / b i n / s h - v \r \n e c
0000010 h o " h e l l o , b a s h "
0000020 \r \n
0000022
jbone@bastrop> exit
--
So the moral of the story is, beware \r \n sequences on Linux boxes, at least
recent RH flavors. ICK, huh? To its credit, Rebol tries to do the right
thing even though it doesn't get the command line params the interp was
supposed to be invoked with; to wit, it goes ahead and runs the script. Bash
gets confused and bails right away.
BTW, the reason I ran into this problem is that I was originally working with
a rebscript I'd DL'd from a website. It had those embedded \r \n sequences.
I'm not sure if that happened because of the way I downloaded it, or because
they were there in the data on the website... but we should all be careful
when posting code to eliminate \r \n sequences. What's worse, apparently VIM
looks for \r \n sequences terminating lines when it loads up, and uses *that*
even when inserting / terminating newly added lines!
$0.02,
jb
