Mailing List Archive: bug or feature? traceback with python -x off by one line

bug or feature? traceback with python -x off by one line

Apr 11, 1999, 10:42 AM

Post #1 of 4 (1251 views)

I'm using Python 1.5.1 on Windows NT 4.0 Service Pack 3.

If I run a script the "normal" way, the exception
traceback prints the correct source file line numbers:

E:\home\dale\test\>python testx.py
Traceback (innermost last):
File "E:\home\dale\test\testx.py", line 18, in ?
main()
File "E:\home\dale\test\testx.py", line 14, in main
f = open( 'foo.txt', 'r' )
IOError: (2, 'No such file or directory')

However, if I run the exact same script with the Python -x
command line option to skip the first line of the script, the
reported line numbers are consistently off by one:

E:\home\dale\test>python -x testx.py
Traceback (innermost last):
File "testx.py", line 17, in ?
try:
File "testx.py", line 13, in main
def main():
IOError: (2, 'No such file or directory')

Is this the way it's *supposed* to work?

I package a lot of Python scripts as ready-to-run Windows NT batch
files by prepending the line

@python -x %~f0 %* & goto :EOF

which means "without echoing to the console window, run Python
with the -x option, passing it the full path to this batch file
with the rest of the commmand line arguments, and after it
finishes executing, jump to the end of the batch file so it
doesn't try to interpret the remainder of the file as native NT
batch language".

So when an error occurs in one of these Python-scripts-disguised-
as-NT-batch-files, the traceback line numbers are always off by
one.

I've seen this enough times now that if I'm not too lazy or tired,
I can grudgingly remember to adjust the line numbers, but since
I've managed to convince a growing number of co-workers to start
using Python and indeed make it an essential part of our software
development, it's becoming an increasing source of confusion.

Any ideas on the best way to resolve this?
How, from within a script, can I detect that the -x option is
in effect? Or do I have to go hack the interpreter source?

Thanks in advance,

--
Dale Nagata | tel : +1 604.451.2700 ext. 2254 (UTC-0800)
Software Developer | fax : +1 604.437.9891
Creo Products Inc. | pgr : +1 604.691.8279
Burnaby BC Canada | http://www.creo.com/

bug or feature? traceback with python -x off by one line [ In reply to ]

bwinton at iname

Apr 11, 1999, 11:35 AM

Post #2 of 4 (1232 views)

Permalink

On Sun, 11 Apr 1999 10:42:24 -0700, Dale Nagata <dnagata@creo.com> wrote:
>I package a lot of Python scripts as ready-to-run Windows NT batch
>files by prepending the line
> @python -x %~f0 %* & goto :EOF

Hey, that's pretty cool looking... But I have to wonder, why don't you
just type "filename.py"? The associations are set up correctly by
default if I remember correctly, so if you have python installed on the
machine, you don't need the trick. (Say, does that work on Win95/98 as
well? There it could be very handy for some stuff we're doing at
work...)

>which means "without echoing to the console window, run Python with the

This got me started thinking about the "Hello Polyglot" program I saw a
while ago, and I wondered just what that line would do if interpreted as
a Perl program (because of the @)... The answer is:

syntax error at temp2 line 1, near "@python -x "
Warning: Use of "-x" without parens is ambiguous at temp2 line 1.
Bareword found where operator expected at temp2 line 1, near "%~f0"
(Missing operator before f0?)
Execution of temp2 aborted due to compilation errors.

>Any ideas on the best way to resolve this? How, from within a script,
>can I detect that the -x option is in effect? Or do I have to go hack
>the interpreter source?

I think you'ld have to hack the source, since the traceback line numbers
are set in there, no matter what you do.

Later,
Blake.

bug or feature? traceback with python -x off by one line [ In reply to ]

tim_one at email

Apr 11, 1999, 3:04 PM

Post #3 of 4 (1224 views)

Permalink

[Dale Nagata]
> I'm using Python 1.5.1 on Windows NT 4.0 Service Pack 3.

This should work the same way everywhere, 1.5.2 included.

> If I run a script the "normal" way, the exception
> traceback prints the correct source file line numbers:
>
> E:\home\dale\test\>python testx.py
> ...
> File "E:\home\dale\test\testx.py", line 18, in ?
> main()
> ...
>
> However, if I run the exact same script with the Python -x
> command line option to skip the first line of the script, the
> reported line numbers are consistently off by one:
>
> E:\home\dale\test>python -x testx.py
> ...
> File "testx.py", line 17, in ?
> try:
> ...
>
> Is this the way it's *supposed* to work?

Feeling a bit under-telepathic today, I can only confirm that the code is
functioning as written <wink>. -x is implemented via advancing the input
file stream beyond the first line (well ...) before the parser ever sees it.
As far as the parser is concerned, the first line it sees is line number 1.

> ...
> Any ideas on the best way to resolve this?

I agree it would be nice to change. In the meantime, I don't see a
Python-only workaround. Under NT you don't *need* the -x trick, though
(look for NT help on "assoc" and friends; provided you have the cmd.exe
extensions enabled (the NT default), you can teach NT that .py files are to
be run by Python, much as .bat files are to be run by the command-line
interpreter; you cannot teach Win95 this, though).

> How, from within a script, can I detect that the -x option is
> in effect?

Can't; the info is long gone.

> Or do I have to go hack the interpreter source?

Start with function Py_Main in Modules\main.c. If you get it to work, send
a patch to Guido! I'd try replacing the "skipfirstline" fgets with a loop
that does getc until it hits a newline or EOF, and if hits a newline pushes
it back with ungetc. This is a local change to one block of code. Then the
first line the parser sees will be "\n", which is harmless, but will advance
the line counter. As is, the skipfirstline block advances the stream
*beyond* the newline, and that's where you're getting in trouble; the
current code is also flawed if the first line (including trailing newline)
has more than 255 characters.

aha!-12-more-than-a-power-of-3<wink>-ly y'rs - tim

bug or feature? traceback with python -x off by one line [ In reply to ]

dnagata at creo

Apr 11, 1999, 4:04 PM

Post #4 of 4 (1236 views)

Permalink

Blake Winton wrote:
>
> > @python -x %~f0 %* & goto :EOF
>
> Hey, that's pretty cool looking... But I have to wonder, why don't you
> just type "filename.py"? The associations are set up correctly by
> default if I remember correctly, so if you have python installed on the
> machine, you don't need the trick. (Say, does that work on Win95/98 as
> well? There it could be very handy for some stuff we're doing at
> work...)
>

I don't just type filename.py because I can't be certain that
the machine the script will run on has Python installed in the
normal way with file type associations defined etc, but I can
reasonably expect that it will have a native NT CMD.EXE command
interpreter that supports the above cool-looking syntax, and a
minimalistic Python run time environment.

The above trick doesn't work with the 4NT command interpreter,
and I am almost certain it won't with Win95/98's either (and it
won't work on NT's built-in CMD.EXE if command extensions are
disabled).

And besides, redirecting I/O is known not to work properly if
you try to use

filename.py >filename.out

instead of

python filename.py >filename.out

but it does work if the cool syntax is used.

--
Dale Nagata | tel : +1 604.451.2700 ext. 2254 (UTC-0800)
Software Developer | fax : +1 604.437.9891
Creo Products Inc. | pgr : +1 604.691.8279
Burnaby BC Canada | http://www.creo.com/