program in interactive mode

[B.G.R.]

Hi all,

I'm working on an interpreter for a university subject, which is programmed
in python under linux.
I got most of the work done and I'm just trying to settle some problems I've
found on my way.
Right now, the most important is reading the user input. Everything goes
through the standard input, and now I got something like this:

numline=0
for line in sys.stdin:
numline+=1
workwithline(li ne)

A little bit more complex, but that's the idea. That will work if the user
does something like "./myprog.py < code" or "cat code | ./myprog.py", and
that's ok, but if the user only does "./myprog.py" then I got to get into
interactive mode and show a prompt in every line expecting the user input
for that line. Problem is I don't know how to tell if I've been "piped" or
not.
I used to think that the piped program doesn't know anything and it's just
OS dependant to close and open the right descriptors, but I'm not sure
anymore. Any help or pointer in the right direction would be greatly
appreciated.

Happy christmas everyone,

RGB

[M.E.Farmer]

B.G.R. wrote:

Hi all, [snip] A little bit more complex, but that's the idea. That will work if the user does something like "./myprog.py < code" or "cat code | ./myprog.py", and that's ok, but if the user only does "./myprog.py" then I got to get into interactive mode and show a prompt in every line expecting the user input for that line. Problem is I don't know how to tell if I've been "piped" or not.
I used to think that the piped program doesn't know anything and it's just OS dependant to close and open the right descriptors, but I'm not sure anymore. Any help or pointer in the right direction would be greatly
appreciated.

Happy christmas everyone,

RGB

Hello RGB,
what you are loking for is sys.stdin.isatt y()

py> if sys.stdin.isatt y():
.... print 'Console'
.... else:
.... print 'Redirected'

Hth,
M.E.Farmer

[Alex Martelli]

B.G.R. <no****@yahoo.t k> wrote:
...

numline=0
for line in sys.stdin:
numline+=1
workwithline(li ne)
Consider the alternative:
for numline, line in enumerate(sys.s tdin):

Nothing to do with your main program, but still neater...
that's ok, but if the user only does "./myprog.py" then I got to get into
interactive mode and show a prompt in every line expecting the user input
for that line. Problem is I don't know how to tell if I've been "piped" or

sys.stdin.isatt y() should serve you well.
Alex

[B.G.R.]

"Alex Martelli" <al*****@yahoo. com> escribió en el mensaje
news:1gpf7qp.c9 e4w97cdazzN%al* ****@yahoo.com. ..

B.G.R. <no****@yahoo.t k> wrote:
...

numline=0
for line in sys.stdin:
numline+=1
workwithline(li ne)
Consider the alternative:
for numline, line in enumerate(sys.s tdin):

Nothing to do with your main program, but still neater...

that's ok, but if the user only does "./myprog.py" then I got to get into interactive mode and show a prompt in every line expecting the user input for that line. Problem is I don't know how to tell if I've been "piped"

or
sys.stdin.isatt y() should serve you well.
Alex

Thank you all very much for your help and tips, that's exactly what I was
looking for.
I guess my knowledge of the libraries is still quite limited. Time to work
on that too.

Regards
RGB

[Scott David Daniels]

B.G.R. wrote:

numline=0
for line in sys.stdin:
numline+=1
workwithline(li ne)

I'd use:

for numline, line in enumerate(sys.s tdin):
workwithline(li ne)

Note: The line numbers start at 0, but that is often acceptable.

--Scott David Daniels
Sc***********@A cm.Org

[Mike Meyer]

"B.G.R." <no****@yahoo.t k> writes:

Hi all,

I'm working on an interpreter for a university subject, which is programmed
in python under linux.
I got most of the work done and I'm just trying to settle some problems I've
found on my way.
Right now, the most important is reading the user input. Everything goes
through the standard input, and now I got something like this:

numline=0
for line in sys.stdin:
numline+=1
workwithline(li ne)

A little bit more complex, but that's the idea. That will work if the user
does something like "./myprog.py < code" or "cat code | ./myprog.py", and
that's ok, but if the user only does "./myprog.py" then I got to get into
interactive mode and show a prompt in every line expecting the user input
for that line. Problem is I don't know how to tell if I've been "piped" or
not.
I used to think that the piped program doesn't know anything and it's just
OS dependant to close and open the right descriptors, but I'm not sure
anymore. Any help or pointer in the right direction would be greatly
appreciated.

I've discovered a truly elegant trick with python programs that
interpret other data. You make them ignore lines that start with # at
the beginning of the line, and accept the name of a file to be
interpreted as a first argument. Your users can then put

#!/usr/bin/env mycode.py

at the top of their files, and then treat their files as normal
executables. mycode.py has to be on their path; if not, they need to
plug in the full path to mycode.py.

I save the state of TkInter programs by writing this out then pickling
the objects that define the state to the file. Executing that file
will bring the program back up in the same state it was saved in.

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

[John Machin]

Mike Meyer wrote:

I've discovered a truly elegant trick with python programs that
interpret other data.
Q0. Other than what?
You make them ignore lines that start with # at
the beginning of the line,
Q1. After the first user accidentally gets a # at the start of a real
data line, a few hundred lines into their file, then what will you do?
Fix your script to detect this error and re-issue your documentation,
emphasising that this is not a general comment convention?

Q2. Then when users 2+ steam up complaining that they have stacks of
files containing lines like "#### Next section is frappenwanger
readings in picoHertz ####", and the script is printing out a whole lot
of what they regard as gobbledegook followed by
"HashmarkAtStar tOfOtherThanLin eZeroError", and then stopping, what do
you do?
and accept the name of a file to be
interpreted as a first argument. Your users can then put

#!/usr/bin/env mycode.py
Q3. Will that work on 'Doze?

Q4. Doesn't that tie their file to your script, or force other scripts
to ignore the first line?

at the top of their files, and then treat their files as normal
executables. mycode.py has to be on their path; if not, they need to
plug in the full path to mycode.py.

Q5. For comparison purposes, could you please post an example of what
you regard as a filthy ugly trick?

[Mike Meyer]

"John Machin" <sj******@lexic on.net> writes:

Mike Meyer wrote:

I've discovered a truly elegant trick with python programs that
interpret other data. Q0. Other than what?

Other than Python code.

You make them ignore lines that start with # at
the beginning of the line,

Q1. After the first user accidentally gets a # at the start of a real
data line, a few hundred lines into their file, then what will you do?
Fix your script to detect this error and re-issue your documentation,
emphasising that this is not a general comment convention?

Depends on how you implement it. Possibly issue an error
message. Possibly treat this as data. Possibly treat this as a comment.
Q2. Then when users 2+ steam up complaining that they have stacks of
files containing lines like "#### Next section is frappenwanger
readings in picoHertz ####", and the script is printing out a whole lot
of what they regard as gobbledegook followed by
"HashmarkAtStar tOfOtherThanLin eZeroError", and then stopping, what do
you do?
You don't implement the hashmark that way, of course.

and accept the name of a file to be
interpreted as a first argument. Your users can then put

#!/usr/bin/env mycode.py

Q3. Will that work on 'Doze?

Probably not. I don't know if this is part of the Posix compatability
level or not.
Q4. Doesn't that tie their file to your script, or force other scripts
to ignore the first line?

This trick is really only applicable to data where you control the
file format. As I mentioned, I use it to treat pickled program
configuration files as executables.

at the top of their files, and then treat their files as normal
executables. mycode.py has to be on their path; if not, they need to
plug in the full path to mycode.py.

Q5. For comparison purposes, could you please post an example of what
you regard as a filthy ugly trick?

f = __import__(__na me__)
f.__dict__['name'] = value

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