World: r3wp

Yes, Janko, that is probably the cause of the symptom you see.

There is a way to hack the executable. It's been discussed previously 
on this AltME world. You should be able to Google it.

Although you might want to consider just switching to 32 bit if you 
don't have a specific reason to use 64 bit Linux.

64 bit uses more memory, and memory is usually the most significant 
constraint on a VPS.

Try this :  
	ldd rebol 
to see if REBOL can find all the required libs to run.

kcollins ... this VPS was given to me as a present by long time customer 
... I said I wanted 32 bits but I guess his admin mixed up things

I will try getting 32 bits, if it won't be possible I will google 
for hack ..


Doc : I tried ldd and it said >> not a dynamic executable  (so I 
guess that isn't the problem)

I was reminded that this could be the probem by my customer, he had 
some rebol things on his vps-s and used 64 bits and said he had similar 
problem , then his admin solved it somehow :) but I prefer 32bit 
for reasons you said (RAM)

On 32bits linux :
# ldd /usr/bin/rebol 
        linux-gate.so.1 =>  (0xffffe000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7ed3000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7da2000)
        /lib/ld-linux.so.2 (0xb7efe000)

AFAIK, on 64bits Linux, 32bits librairies are located in /lib32 and 
not in /lib. This may be the reason why you can't run REBOL.

[root-:-www]:/usr/bin# ./rebol
-bash: ./rebol: No such file or directory
[root-:-www]:/usr/bin# ldd ./rebol
        not a dynamic executable
[root-:-www]:/usr/bin# ldd ./who
        linux-vdso.so.1 =>  (0x00007fffe89fd000)
        libc.so.6 => /lib/libc.so.6 (0x00007ff4e02bc000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff4e060f000)

Doc: I have /lib/ and /lib64/  -- do you think that lib are 32b libs? 
or do I have to install them ... the client told me now he thinks 
admin installed the 32b libs at his vps

thanks guys.. works now ...!!!

client said that reinstalling linux would be a little problem, so 
this will do for now ... 


I installed the ia32-libs ( apt-get install ia32-libs ) and now rebol 
works

Great! I was not aware of that solution.

this page explained it: http://www.debian-administration.org/article/Running_32-bit_Applications_on_64-bit_Debian_GNU/Linux

rebol now works, but I have a problem with cheyenne , something similar 
to what Doc said before
--------------

[root-:-www]:/usr/share/cheyenne# ./cheyenne

** Script Error: Library error: /lib/libc.so.6: wrong ELF class: 
ELFCLASS64
** Where: do-cache
** Near: all [
    any [
        exists? libc: %/lib/libc.so.6
        exists? libc: %/lib/libc.so.5
    ]
    libc: load/libra...
[root-:-www]:/usr/share/cheyenne# ldd ./cheyenne
        libm.so.6 => /lib32/libm.so.6 (0xb7ef7000)
        libdl.so.2 => /lib32/libdl.so.2 (0xb7ef3000)
        libc.so.6 => /lib32/libc.so.6 (0xb7da1000)
        /lib/ld-linux.so.2 (0xb7f24000)
[root-:-www]:/usr/share/cheyenne#

I think 32 libs are in lib32 now (which I got after installing that 
package) and cheyenne is probably looking in /lib/ like the rebol 
code in exception shows ..

I fix that issue in my developement version of Cheyenne a week ago. 
Just edit %misc/unix.r and change the access path to libc like this 
: 
	any [
		exists? libc: %libc.so.6
		exists? libc: %/lib32/libc.so.6
		exists? libc: %/lib/libc.so.6
		exists? libc: %/lib/libc.so.5
	]

<fixed>

I just wanted to say that I isntalled cheyenne from source now and 
wanted to fix that code in unix.r .. and ran it via rebol cheyenne.r 
and it already worked without fixing any code :)

cool :-)

Thanks Doctor :)

So I just need to move to the latest cheyenne ... now I have the 
reason to do so :)

Let me know in !Cheyenne group if you have any issue with the latest 
release.

(ok)

Browse on Linux temporary solution
browse: funct [ url ] [ call reform [ "x-www-browser" url ]]

And browse works, and all commnads based on browse ( docs, bug, changes 
) too

ManuM, can you do something similar for a file manager window? That 
would solve a bug in R3 Chat. Thanks.

I have an ext3 filesystem and I need to add "nls=utf8" to /etc/fstab 
for this filesystem to correctly convert filenames that are coming 
from window machines.

Just adding this option makes the filesystem read-only while mounting.

Any idea how to enable utf8 support? Do I need to "convert" the existing 
filesystem?

Henrik: If you are talking about bug#779 I have added a comment at 
bug
http://curecode.org/rebol3/ticket.rsp?id=779&cursor=1
Something similar can be:
open-file-manager: funct [ dir ][ call reform [ "xdg-open" dir ]]

very nice and simple. thanks.

Robert: I work with kubuntu 8.10 but I think that can help

This is one line from my "/etc/fstab" file. It mounts a fat filesystem 
at /media/DESARROLLO ( dir /media/DESARROLLO already exists )
/dev/sda7 /media/DESARROLLO vfat rw,utf8,umask=000 0 0

With umask=000 the access to /media/DESARROLLO will be rwxrwxrwx 
( the owner is root and the group is root, I don't know how to change 
it )

Ok, trying it.

There is a tool to convert filenames (convmv) to UTF8. I'm wondering, 
what influence this has on running programs?

For example: IOS has a registry, if I conver the filesystem names 
to UTF8, will this render the registry entries invalid?

I don't know ( the two questions ) :)

Robert, afaik file names are utf8 by default on ext filesystems. 
(actually i think the filesystem does not care much about the encoding, 
but the os in general uses utf8.) i think you need that option on 
the ntfs filesystem, not the ext one.

re: ios, if you have non-ascii chars, it could be a problem.

I'm wondering how I got those "invalid UTF-8 characters" onto my 
EXT3 filesystem. IOS cleans-out filenames that contain special characters, 
so it should be no problem on the server-side.

I'm going to try to convert 1 single filename and see what happens.

most programs do not check that the file name is valid utf-8. normally, 
you're using a utf-8 terminal so there is no way you can type an 
invalid filename. but you can easily create one using rebol for eg. 
or using escape sequences in the shell and so on

in the same way, you can convert them back as long as you know what 
the source charset was

Ok thanks.

I haven't played with unix for so long I'm a bit (very :-)  rusty.

when doing an 'ls -al'

I get:

total 20
drwxr-xr-x  2 root root 4096 May 16 05:37 .
drwxr-xr-x 21 root root 4096 May 16 12:10 ..
-rw-------  1 root root  437 May 17 09:35 .bash_history
-rw-r--r--  1 root root  412 Dec 15  2004 .bashrc
-rw-r--r--  1 root root  140 Nov 19  2007 .profile


I can't remember what the "total 20" stands for. 

it doesn't map to file numbers, block counts used by files, or anything 
I can gather... is this some type of millisecond count of time it 
took to perform the file list?

I used to be an IRIX certified integration expert... working on 1M$ 
+ systems ... this feels strange...I feel like a newbie all over 
again  :-)

It matches the number of "o" in double "oo". ;-)

More seriously, it looks like it's the total number of file system 
blocks. See there : http://www.mailinglistarchive.com/[fedora-list-:-redhat-:-com]/msg51203.html

ahhh yes using the -h flag does make it explit and clear