ANNOUNCE; Try python beta

[Mike Meyer]

Ok, I've given it the interface I want, and made it less of an
attractive nuisance.

http://www.mired.org/home/mwm/try_python/ is now ready for people to
play with. There's no tutorial information on it yet, that's the next
thing to do. However, I won't be able to work on it for a while, so if
you want to make suggestions about what that should look like, all
such suggestions will be given proper consideration.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Lonnie Princehouse]

Pretty neat =)

But aren't you concerned about security? Letting anybody execute
arbitrary Python expressions (and therefore also arbitrary system
commands?!) on your box --- even from within a FreeBSD jail --- seems a
bit dangerous.

[Claudio Grondi]

Mike Meyer wrote:

Ok, I've given it the interface I want, and made it less of an
attractive nuisance.

http://www.mired.org/home/mwm/try_python/ is now ready for people to
play with. There's no tutorial information on it yet, that's the next
thing to do. However, I won't be able to work on it for a while, so if
you want to make suggestions about what that should look like, all
such suggestions will be given proper consideration.

<mike

I suggest it should work like IDLE do and not remain limited to
evaluating of expressions. One can easily get the impression Python is
very limited and this is not what can help Python to show its strengths.

By the way:

The page doesn't work for me in MSIE (I am on a Windows system)

1+1 SyntaxError: unexpected EOF while parsing (line 1)

It does work for me in FireFox and Netscape: 1+1 2

but in Opera I get: 1+1

祓瑮硡牅潲㩲ç”*æ•®ç�¸æ�¥æ•´â�¤ä½…â�†æ¡·æ±©â� ¥æ…°ç�²æ¹©â�§æ°¨æ¹©â�¥â¤±>>>
I am most curious about the last one with no idea how it comes?

Maybe the subject of your posting should be changed to:

Try my skills in processing form requests from different Internet browser?

Claudio

[Gerhard Häring]

Lonnie Princehouse wrote:

Pretty neat =)

But aren't you concerned about security? Letting anybody execute
arbitrary Python expressions (and therefore also arbitrary system
commands?!) on your box --- even from within a FreeBSD jail --- seems a
bit dangerous.

I found out about the FreeBSD jail myself, too ;-)

Removing __import__ from the builtins would make such detective work
much harder, though ;-)

-- Gerhard

[Devan L]

Mike Meyer wrote:

Ok, I've given it the interface I want, and made it less of an
attractive nuisance.

http://www.mired.org/home/mwm/try_python/ is now ready for people to
play with. There's no tutorial information on it yet, that's the next
thing to do. However, I won't be able to work on it for a while, so if
you want to make suggestions about what that should look like, all
such suggestions will be given proper consideration.

I was bored so I wrote some code that takes input one line at a time
and spits out the a tuple representing the state and a message to be
echoed. It handles statements on multiple lines, too. So it might be
helpful, since your tutorial doesn't seem to handle multiple lines or
statements.

You can see it at <http://www.datamech.com/devan/bastille.txt>

[Mike Meyer]

"Lonnie Princehouse" <fi**************@gmail.com> writes:

Pretty neat =)
But aren't you concerned about security? Letting anybody execute
arbitrary Python expressions (and therefore also arbitrary system
commands?!) on your box --- even from within a FreeBSD jail --- seems a
bit dangerous.

What's there is actually more restricted than a FreeBSD jail. This one
has been tightened down to a statically linked Python interpreter, the
statically linked cgi program which does nothing but launch the Python
interpreter with the right arguments, and python library files. I've
even removed most of the latter that aren't used by the python
script. So yeah - you can run arbitrary system commands, except there
shouldn't be any.

The previous version was in a jail, which is why I didn't want it
generally announced. The logs made amusing reading. I like Gerhard's
idea of removing __import__, and have done that.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

Claudio Grondi <cl************@freenet.de> writes:

Mike Meyer wrote:

Ok, I've given it the interface I want, and made it less of an
attractive nuisance.
http://www.mired.org/home/mwm/try_python/ is now ready for people to
play with. There's no tutorial information on it yet, that's the next
thing to do. However, I won't be able to work on it for a while, so if
you want to make suggestions about what that should look like, all
such suggestions will be given proper consideration.
<mike I suggest it should work like IDLE do and not remain limited to
evaluating of expressions. One can easily get the impression Python is
very limited and this is not what can help Python to show its
strengths.

I thought about that. It's not clear that it's fixable at this
level. If not, it'll be documented.
By the way:
The page doesn't work for me in MSIE (I am on a Windows system)

>>> 1+1 SyntaxError: unexpected EOF while parsing (line 1)
Yeah, I know. I poked at it briefly, but couldn't figure out what was
goiing on. MSIE on the Mac doesn't work at all (no AJAT), and I don't
have regular access to a Windows box to try it on.
It does work for me in FireFox and Netscape: >>> 1+1 2
Also Safari, Mozilla and Netscape. If you try it with a browser
without XMLHttpRequest, it'll suggest them.
but in Opera I get: >>> 1+1

祓瑮硡牅潲㩲ç”*æ•®ç�¸æ�¥æ•´â�¤ä½…â�†æ¡·æ±©â� ¥æ…°ç�²æ¹©â�§æ°¨æ¹©â�¥â¤±>>>

Yup, I've seen that one as well. I have *no* idea what Opera thinks
it's doing. Adding a charset to the content-type didn't solve the
problem. I checked opera's web site, and couldn't find a page for web
developers.

I've added a note about these problems.
Maybe the subject of your posting should be changed to:
Try my skills in processing form requests from different Internet browser?

Actually, it's doing form processing. It's doing XMLHttpRequests.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[skip]

It does work for me in FireFox and Netscape:

>>> 1+1

2

Mike> Also Safari, Mozilla and Netscape.

I tried 4+3 in Safari and got

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>500 Internal Server Error</TITLE>
</HEAD><BODY>
<H1>Internal Server Error</H1>
The server encountered an internal error or
misconfiguration and was unable to complete
your request.<P>
Please contact the server administrator,
we*******@mired.org and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.<P>
More information about this error may be available
in the server error log.<P>
<HR>
<ADDRESS>Apache/1.3.26 Server at www.mired.org Port 80</ADDRESS>
</BODY></HTML>

in the terminal just now (9:05 or so CST).

Skip

[David Wahler]

Mike Meyer wrote:

The previous version was in a jail, which is why I didn't want it
generally announced. The logs made amusing reading. I like Gerhard's
idea of removing __import__, and have done that.

Oh, you have, eh? Are you absolutely sure? Try running "grep 'all your
base' log".

-- David

[Mike Meyer]

"David Wahler" <dw*****@gmail.com> writes:

Mike Meyer wrote:

The previous version was in a jail, which is why I didn't want it
generally announced. The logs made amusing reading. I like Gerhard's
idea of removing __import__, and have done that.

Oh, you have, eh? Are you absolutely sure? Try running "grep 'all your
base' log".

Yup, removing it securely is more trouble than it's worth. Which is
why this is running in a sandbox inside a jail - I knew that securing
Python was a probably impossible.

I put __import__ back, and even imported os just to save you some
time. I also put the expression that will get do the equivalent of "ls
-R /" up for anyone to read.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

sk**@pobox.com writes:

>> It does work for me in FireFox and Netscape:
>> >>> 1+1
>> 2

Mike> Also Safari, Mozilla and Netscape.
I tried 4+3 in Safari and got

I've been futzing with it all evening. Various things I've done have
broken it in strange ways. It's working now (or was - someone may have
found a way to break it).

I'm tempted to put in a hook to log expressions and let people play
them back - it's kind of amusing.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Kay Schluehr]

Mike Meyer wrote:

Ok, I've given it the interface I want, and made it less of an
attractive nuisance.

http://www.mired.org/home/mwm/try_python/ is now ready for people to
play with. There's no tutorial information on it yet, that's the next
thing to do. However, I won't be able to work on it for a while, so if
you want to make suggestions about what that should look like, all
such suggestions will be given proper consideration.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Very nice though a little tedious to use ;)

Working on Windows XP behind a proxy ( trying both Mozilla + Internet
Explorer ) and typing

1+2

results in a HTML request in the output field of the console:

<html>
<head>
<title> Data Transfer Status Report </title>
<META http-equiv="Refresh" content="1;
URL=http://www.mired.org/home/mwm/try_python/GGTSPU-fw1.gdm.de-1305-446462-DAT/python.sbox?%3E%3E%3E%201+2">
</head>
<body bgcolor="#ffffff">
<h2> Data Transfer Status Report</h2>
<hr>
<table>
<tr><td align=right>URL:</td><td align=left><b><a
href="http://www.mired.org/home/mwm/try_python/python.sbox?%201+2">http://www.mired.org/home/mwm/try_python/python.sbox?%201+2</a></b></td></tr>

etc.

The interesting issue is the provided link. Copying the HTML output
into a file and executing it opens a file transfer connection. The
result is as expected:

python.sbox

It contains the correct result: it is 3 :)

Kay

[Richie Hindle]

[Claudio]

The page doesn't work for me in MSIE (I am on a Windows system)
[Mike] Yeah, I know. I poked at it briefly, but couldn't figure out what was
goiing on. MSIE on the Mac doesn't work at all (no AJAT), and I don't
have regular access to a Windows box to try it on.

I think it's your JavaScript '\r' processing that's broken. Certainly the
error ("unexpected EOF while parsing") is consistent with having a \r on the
end of the expression. Won't this:

if (input.length == 1)

always fail in the case where the user has typed a newline? I'd ditch that
code and do it at the server end:

expr = expr[4:].strip()

--
Richie Hindle
ri****@entrian.com

[Paul Boddie]

Mike Meyer wrote:

[Browser behaviour]

Actually, it's doing form processing. It's doing XMLHttpRequests.

You might want to add some workarounds for Konqueror. What I found was
that Konqueror (on KDE 3.4.0) has a tendency to add null bytes to the
end of some form field values. Consequently, I get mostly "SyntaxError:
unexpected EOF while parsing (line 1)" in that browser. It could well
be that other browsers also have their quirks with XMLHttpRequest.

Paul

[Mike Meyer]

Richie Hindle <ri****@entrian.com> writes:

Yeah, I know. I poked at it briefly, but couldn't figure out what was
goiing on. MSIE on the Mac doesn't work at all (no AJAT), and I don't
have regular access to a Windows box to try it on.
I think it's your JavaScript '\r' processing that's broken. Certainly the
error ("unexpected EOF while parsing") is consistent with having a \r on the
end of the expression.

Python doesn't care about the trailing newline.
Won't this:

if (input.length == 1)

always fail in the case where the user has typed a newline? I'd ditch that
code and do it at the server end:

The point of the '\r' processing is to make sure we don't send the
entire text area string to the server. That breaks things pretty
badly. My assumption is that if splitting on '\n' leaves us with one
thing, we may have gotten a string that used \r for newlines, so we
split on that. Hmm. If the results of the first split left us with
"'\r'expr", then the second split will send an empty string, which
would result in what we're seeing.

I'll investigate that.

thanks,
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Richie Hindle]

[Richie]

I think it's your JavaScript '\r' processing that's broken. Certainly the
error ("unexpected EOF while parsing") is consistent with having a \r on the
end of the expression.
[Mike] Python doesn't care about the trailing newline.
That's a carriage return, not a newline:

eval("1+2\r") Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<string>", line 1
1+2
^
SyntaxError: unexpected EOF while parsing
My assumption is that if splitting on '\n' leaves us with one
thing, we may have gotten a string that used \r for newlines

Ah, OK. Your comment talks about DOS - that won't happen on DOS (or
Windows) which uses \r\n. I don't know about the Mac. But the \r\n pair
isn't handled by your code - strip() on the server side will make it work if
that's the problem:
eval("1+2\r".strip())

3

--
Richie Hindle
ri****@entrian.com

[Mike Meyer]

Richie Hindle <ri****@entrian.com> writes:

My assumption is that if splitting on '\n' leaves us with one
thing, we may have gotten a string that used \r for newlines

Ah, OK. Your comment talks about DOS - that won't happen on DOS (or
Windows) which uses \r\n. I don't know about the Mac. But the \r\n pair
isn't handled by your code - strip() on the server side will make it work if
that's the problem:

You mean there's a difference between DOS and Windows?

The Mac stuff I can test, so that's easier to get right.

eval("1+2\r".strip())

3

I actually did wind up doing it this way. MSIE works now, but still
doesn't seem very reliable.

Thanks,
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Eric]

On 20 December 2005, Mike Meyer wrote:

Ok, I've given it the interface I want, and made it less of an
attractive nuisance.

http://www.mired.org/home/mwm/try_python/ is now ready for people to
play with. There's no tutorial information on it yet, that's the next
thing to do. However, I won't be able to work on it for a while, so if
you want to make suggestions about what that should look like, all
such suggestions will be given proper consideration.

I'm not sure about everyone else, but I find the big warnings about
CSS and JavaScript almost as annoying as the fact that it doesn't do
anything. At all, even with JavaScript enabled. Then again, my main
browser is elinks, so my opinion is somewhat biased.

If you get it working in Lynx, supporting other browsers should be
easier than the other posts make this solution sound.

- Eric

[Maravilloso]

I'm afraid that I've spoiled the "try_python" working by means of
executing the sentence:

open("try.py").write("\n")

Sorry. I hope it don't be difficult for you to restore the module again
to the default folder.

In any case, I think it should include some control for malicious code
like that one.

[Mike Meyer]

"Maravilloso" <ma*********@gmail.com> writes:

I'm afraid that I've spoiled the "try_python" working by means of
executing the sentence:

open("try.py").write("\n")

Sorry. I hope it don't be difficult for you to restore the module again
to the default folder.
No problem - I'm not crazy enough to leave unreplaceable data on a
machine with open incoming ports.
In any case, I think it should include some control for malicious code
like that one.

Normally, it is. I must have left the module writeable after updating
it :-(. It's been replaced, and if you try that now you'll get an
IOError.

Thanks for reporting it.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

Eric <gr****@brainshell.org> writes:

I'm not sure about everyone else, but I find the big warnings about
CSS and JavaScript almost as annoying as the fact that it doesn't do
anything. At all, even with JavaScript enabled. Then again, my main
browser is elinks, so my opinion is somewhat biased.
Well, if you have CSS working properly and JavaScript enabled, you
won't get the warnings. Would you honestly prefer that it just quietly
not work at all, rather than tell you why it doesn't work? At least it
doesn't insult your intelligence by telling you how to enable them for
browsers you aren't using.
If you get it working in Lynx, supporting other browsers should be
easier than the other posts make this solution sound.

True. On the other hand, it was designed from the ground up to use
AJAT, to keep the traffic required to update the page at a sane
level. Future plans also depend on JavaScript, since it's required for
the basic functionality in any case.

A version could be designed that didn't keep the history around that
would work in lynx (though I'd test it in my preference: w3m) and used
the same evaluation back end. That would look a lot less like the
python interpreter, though. If you want to do that, I'd be more than
happy to provide a link to it, or even host it. Otherwise, I'll think
about it after I finish the currently planned version.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.