Bug reporting impossible

[Nick Maclaren]

Currently logins are disabled to sourceforge.net, and (despite the
comments) it won't let me report a bug anonymously. Does anyone
know whether this is short or long term? I have a bug in 2.5 to
report - which has been there for a while and isn't overwhelmingly
critical and has been there for a while.

Create a file called '<stdin>' in your current directory containing
'print "Oh, yeah?\n"' and then import a module that doesn't exist.
Don't include the single quotes.


Regards,
Nick Maclaren.

 

[Georg Brandl]

Currently logins are disabled to sourceforge.net, and (despite the
comments) it won't let me report a bug anonymously. Does anyone
know whether this is short or long term? I have a bug in 2.5 to
report - which has been there for a while and isn't overwhelmingly
critical and has been there for a while.

Create a file called '<stdin>' in your current directory containing
'print "Oh, yeah?\n"' and then import a module that doesn't exist.
Don't include the single quotes.

You should have said what the bug is.
To save others reproducing this: you get a traceback akin to

$ python
Python 2.4.3 (#1, May 8 2006, 18:29:03)
[GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):
File "<stdin>", line 1, in ?
print "Oh, yeah?\n"
ImportError: No module named xyzzy
The problem is that Python does not know whether a file name is bogus
or an actual file. So it was assumed that names like "<stdin>" or "<string>"
are safe enough to use them as subsitutes.

I don't know whether this is worth fixing.

Geor

 

[Simon Forman]

Nick Maclaren wrote:
....

Create a file called '<stdin>' in your current directory containing
'print "Oh, yeah?\n"' and then import a module that doesn't exist.
Don't include the single quotes.

Why would you have a file named '<stdin>' in your current directory?

~Simon

 

[Grant Edwards]

Currently logins are disabled to sourceforge.net, and (despite the
comments) it won't let me report a bug anonymously. Does anyone
know whether this is short or long term? I have a bug in 2.5 to
report - which has been there for a while and isn't overwhelmingly
critical and has been there for a while.

Create a file called '<stdin>' in your current directory containing
'print "Oh, yeah?\n"' and then import a module that doesn't exist.
Don't include the single quotes.

Cute.

2.4 has the same bug I'm guessing:

$ echo "Oh, yeah?" >\<stdin\>

$ python
Python 2.4.2 (#1, Feb 17 2006, 12:02:16)
[GCC 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.Traceback (most recent call last):
File "<stdin>", line 1, in ?
Oh, yeah?
ImportError: No module named asdfasdf

 

[Grant Edwards]

Nick Maclaren wrote:
...

Why would you have a file named '<stdin>' in your current directory?

Why shouldn't you?

 

[Nick Maclaren]

|> ...
|> > Create a file called '<stdin>' in your current directory containing
|> > 'print "Oh, yeah?\n"' and then import a module that doesn't exist.
|> > Don't include the single quotes.
|>
|> Why would you have a file named '<stdin>' in your current directory?

Why would Python search for one?

In both cases, the normal answer is "Someone made a mistake" but, if
you have a script that creates a files of the same names specified in
the current directory, what name should it use if you specify stdin?
It is one of the standard conventions, which is (after all) why Python
is searching for it.

Anyway, I have now reported the bug - but this bug is more amusing than
serious.


Regards,
Nick Maclaren.

 

[Nick Maclaren]

|>
|> You should have said what the bug is.

Well, maybe, but it is more amusing than serious. I have now reported it
properly, as Sourceforge is back up.

|> The problem is that Python does not know whether a file name is bogus
|> or an actual file. So it was assumed that names like "<stdin>" or "<string>"
|> are safe enough to use them as subsitutes.

That is no justification for spuriously executing a file called '<stdin>'
when attempting to produce a diagnostic for one called 'fred'. strace
or equivalent shows up clearly what the bug is.

|> I don't know whether this is worth fixing.

It's definitely worth fixing, but not as a high priority. Invoking a
file spuriously is potentially serious, with very low probability.


Regards,
Nick Maclaren.

 

[Fredrik Lundh]

It's definitely worth fixing, but not as a high priority. Invoking a
file spuriously is potentially serious, with very low probability.

the traceback printer is reading the file (using a very robust reader),
it's not "invoking" it.

</F>

 

[Simon Forman]

|> ...
|> > Create a file called '<stdin>' in your current directory containing
|> > 'print "Oh, yeah?\n"' and then import a module that doesn't exist.
|> > Don't include the single quotes.
|>
|> Why would you have a file named '<stdin>' in your current directory?

Why would Python search for one?

Fair enough.. : )

In both cases, the normal answer is "Someone made a mistake" but, if
you have a script that creates a files of the same names specified in
the current directory, what name should it use if you specify stdin?
It is one of the standard conventions, which is (after all) why Python
is searching for it.

Anyway, I have now reported the bug - but this bug is more amusing than
serious.


Regards,
Nick Maclaren.

I usually refrain from posting if I don't have anything to add to the
discussion, but that struck me as perverse and I was curious.
I certainly have no objection to having that bug fixed. : )

Peace,
~Simon

 

[Nick Maclaren]

|>
|> > It's definitely worth fixing, but not as a high priority. Invoking a
|> > file spuriously is potentially serious, with very low probability.
|>
|> the traceback printer is reading the file (using a very robust reader),
|> it's not "invoking" it.

Boggle! Upon checking, that is indeed the case. All right - that drops
the importance of the bug another notch. It's still an issue on systems
with 'active' files, but that makes the chances of serious trouble even
less likely than before.


Regards,
Nick Maclaren.

 

[olsongt]

I usually refrain from posting if I don't have anything to add to the
discussion, but that struck me as perverse and I was curious.
I certainly have no objection to having that bug fixed. : )

If you find that sort of perversity strangely exciting, I would like to
refer you to pages 67-69 of the Unix Hater's Handbook:

http://www.simson.net/ref/ugh.pdf

 

[Grant Edwards]

the traceback printer is reading the file (using a very robust reader),
it's not "invoking" it.

If you make <stdin> a fifo and pipe something into it, it's
sort of fun:

$ mkfifo \<stdin\>
$ while true; do yow >\<stdin\>; done


$ python
Python 2.4.2 (#1, Feb 17 2006, 12:02:16)
[GCC 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Traceback (most recent call last):
File "<stdin>", line 1, in ?
Yow! Bo Derek ruined my life!
NameError: name 'a' is not defined
Traceback (most recent call last):
while File "<stdin>", line 1, in ?
Yow! YOU!! Give me the CUTEST, PINKEST, most charming little VICTORIAN DOLLHOUSE you can find!! An make it SNAPPY!!
NameError: name 'a' is not defined
Traceback (most recent call last):
File "<stdin>", line 1, in ?
Yow! I will establish the first SHOPPING MALL in NUTLEY, New Jersey...
NameError: name 'a' is not defined
Traceback (most recent call last):
File "<stdin>", line 1, in ?
Yow! Is this where people are HOT and NICE and they give you TOAST for FREE??
File "foo.py", line 4, in ?
p('set out')
NameError: name 'p' is not defined


OK, so not everybody finds things like that amusing...

 

[Fredrik Lundh]

|> Why would you have a file named '<stdin>' in your current directory?

Why would Python search for one?

In both cases, the normal answer is "Someone made a mistake" but, if
you have a script that creates a files of the same names specified in
the current directory, what name should it use if you specify stdin?

given that "<stdin>" is an invalid filename on some platforms, why would any

It is one of the standard conventions, which is (after all) why Python
is searching for it.

the only reason Python's searching for it is that the CLI implementation passes
"<stdin>" as the second argument to compile:

http://pyref.infogami.com/compile

</F>

 

[Nick Maclaren]

|>
|> > |> Why would you have a file named '<stdin>' in your current directory?
|> >
|> > Why would Python search for one?
|> >
|> > In both cases, the normal answer is "Someone made a mistake" but, if
|> > you have a script that creates a files of the same names specified in
|> > the current directory, what name should it use if you specify stdin?
|>
|> given that "<stdin>" is an invalid filename on some platforms, why would any
|> serious programmer use "<stdin>" for an external file ?

You can't be serious, surely?

Firstly, why does Python? Well, I can answer that

Secondly, EVERY string is an invalid filename on some platforms, without
exception! As every single (not system-specific) language has done since
languages imported the concept of filenames, Python says that the set of
strings that are valid filenames is implementation-dependent or perhaps
implementation-defined.

Thirdly, I had better explain what a LOT of programs and scripts actually
do. You have a command 'fred' that takes filenames as arguments and, if
there are none, uses stdin; as part of its function, it needs to create a
file of the same name as those in its arguments, in the current directory.
What filename should it use for stdin?

I sincerely HOPE that you are not proposing to use the null filename
(which could and probably still can be created on some systems), as it is
a gibbering nightmare to handle thereafter, and a poor sod of an ordinary
user has little hope of cleaning up the mess. Been there - done that for
them

It can't use 'stdin', as that is a possible file name, so it uses an
obvious derivation that is unlikely to be created by accident. '<stdin>'
is one of the standard conventions - I am one of perhaps a few hundred
(perhaps more) people who invented it independently, 20 years back, but
doubt that I was even close to the first. It is quite a good name for
Unix, as you can't easily create it by accident in any normal shell.

|> > It is one of the standard conventions, which is (after all) why Python
|> > is searching for it.
|>
|> the only reason Python's searching for it is that the CLI implementation passes
|> "<stdin>" as the second argument to compile:
|>
|> http://pyref.infogami.com/compile

And the reason that it does that is because it is using one of the standard
conventions for naming stdin. Python didn't INVENT that convention, you
know.

The bug isn't in passing an information string "<stdin>" but in using
that string (which is not meant to represent a real file) to perform a
file search.


Regards,
Nick Maclaren.