On Unixoid systems without the 'less' command, executing 
'pydoc.help(mod)' emits:

    sh: less: not found

which is annoying.  The attached patch gets it to quietly look for 'less' 
and 'more'.  I don't know if the locateexe() function is entirely correct 
(especially considering Windows) or if there are other pagers available.

backport candidate?  I know this behavior exists in 2.1.3 and 2.2.1.  
Dunno if it's more than a wart though.

Logged In: YES 
user_id=11105

locateexe does not work on Windows (for several reasons).
Dunno if people install other pagers - I certainly don't.
And when they do, are they really named 'less'?

OTOH, more is in the PATH on every windows system, so I
would suggest simply call more on Windows.

Logged In: YES 
user_id=163326

It should also honour the PAGER environment variable, and
use it if available. I'm trying to be puristic for a minute:
we probably shouldn't support any nonstandard pagers like
less, view, most, etc. at all. That's what Unix has the
PAGER environment variable for, just like the EDITOR and
VISUAL ones. I'm certainly no puristic Unix user, but we
already have zillions of patches for the webbrowser module
to support the various Unix Web Browsers out there. We
should avoid to get into the same situation with pydoc.

Logged In: YES 
user_id=163326

It should also honour the PAGER environment variable, and
use it if available. I'm trying to be puristic for a minute:
we probably shouldn't support any nonstandard pagers like
less, view, most, etc. at all. That's what Unix has the
PAGER environment variable for, just like the EDITOR and
VISUAL ones. I'm certainly no puristic Unix user, but we
already have zillions of patches for the webbrowser module
to support the various Unix Web Browsers out there. We
should avoid to get into the same situation with pydoc.

Logged In: YES 
user_id=45338

> It should also honour the PAGER environment variable

It already does this.  Read the code.

> I would suggest simply call more on Windows.

It already does this.  Read the code.

> The attached patch gets it to quietly look for 'less' 

It also already does this.  If it's not working for you,
there must be a bug. Look at the code -- all of this
behaviour is right there in getpager() and has been
there ever since pydoc was first written.

Logged In: YES 
user_id=44345

skip> The attached patch gets it to quietly look for 'less'
ping> It also already does this.

Not quite.  In situations where no PAGER was set and less was not 
found, as I indicated it emitted "sh: less: not found".  That was the entire 
reason for submitting the patch.  I'm more than willing to accept that my 
patch was incomplete or incorrect in some way, but I was trying to 
address the issue of pydoc noisily informing me that 'less' was not 
available. 

S

Logged In: YES 
user_id=33168

I think locateexe() will not work on MacOS 9, where os.sep
== ':'.  But I don't know how the path works on MacOS 9 or X.

locateexe() can't work on Windows if a path component has
C:\XXX.  Also, the path separator on Windows is ';'.  You
should probably doc that locateexe doesn't work on Windows,
or get it to work on Windows.  Right now, there's no problem
since locateexe() can't be called on windows or os2 now.

I would replace if os.path.isfile() with a try/except
OSError: because the file could exist, but could be a broken
symlink.  I think that may raise an exception now.

To answer Thomas, I think people might use less under
cygwin.  But I'm not sure what os.platform is when python is
built using cygwin.

All that said, I actually like the patch. :-)  So to try to
make those ramblings understandable, check/change
os.path.isfile(), doc/fix locateexe for windows, and check
with Jack, Just, or some other mac person how this would
work on a Mac.

Logged In: YES 
user_id=45338

> I was trying to
> address the issue of pydoc noisily informing me that 'less' was
> not available.

Right, yeah -- but the point i was trying to make is that it's
not just a simple matter of "this feature is missing because
the author never thought of it, so we'll just add it".
There's something more subtle going on here.

I tested it when i originally wrote it and i tested it again
now, and it works fine if my system doesn't have 'less'
(it tries 'more', and failing that it just dumps the text out
straight).  Looking at the code, i can't explain the
behaviour you're getting.  Have you figured out why
you're getting an error message?

About the patch, specifically: i'm generally skeptical
of doing this kind of LBYL test where the test is
different from the actual action needed.  What we
need to know is whether os.system('less') will
succeed, not whether you can find a file named 'less'
on the path with a particular mode.  Finding the
executable is the operating system's business.
I'd prefer to do a test run of os.system('less') and
notice whether that succeeds or fails (which is what
it currently does -- but for some reason it doesn't
work correctly in your setup, and should be made
more robust).

Logged In: YES 
user_id=44345

> Have you figured out why you're getting an error message?

The underlying shell spits a message out somewhere other than stdout 
or stderr?  Here's a cut-n-paste from the Solaris system in question:

$ python
Python 2.2.1 (#2, Sep  9 2002, 17:22:35) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.system('less')
sh: less: not found
256
>>> os.system('less 2>/dev/null')
sh: less: not found
256
>>> os.system('less >/dev/null 2>/dev/null')
sh: less: not found
256
>>> os.system('less >/dev/null 2>&1')
sh: less: not found

My guess is that on Solaris 8 /bin/sh (which is  a real old-fashioned 
Bourne shell, not bash trying to pretend it's the Bourne shell) actually 
spits that message out to /dev/tty instead of stderr.

Logged In: YES 
user_id=33168

I get the problem on linux too (chmod -x /usr/bin/less). 
Using parens around the string passed to system() fixes the
problem for me:

 os.system('(less 2>/dev/null)')

I don't know if this has any other subtle effects.  Skip,
can you test that on your system?

Logged In: YES 
user_id=44345

No go:

$ python
Python 2.2.1 (#2, Sep  9 2002, 17:22:35) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os 
>>> os.system("(less 2>/dev/null)")
sh: less: not found
256
>>> os.system("(less >/dev/null 2>&1)")
sh: less: not found
256

Logged In: YES 
user_id=45338

I think the trick is to put parens around just 'less'.
That way, 'less' is executed in a subshell, and the
first shell directs the stderr of the subshell to /dev/null.

Works for me on sunos5 and linux.

This behaviour all makes logical sense to me now --
it can all be explained by supposing that bash
directs any error messages to the stderr of the
command, whereas other kinds of sh direct error
messages to their own stderr.  Using a subshell
should make it quiet for everybody.

But then didn't have to use parens to get it to be
quiet in Linux (like Neal) -- so i don't know what's
different about our setups.

Logged In: YES 
user_id=44345

Yes, this works for me as well:

$ python
Python 2.2.1 (#2, Sep  9 2002, 17:22:35) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.system('(less) 2>/dev/null')
256

I checked in that change as pydoc.py 1.70 and am closing this item.  
One last question, however...  Is there some reason the 'more' test just 
below:

    if hasattr(os, 'system') and os.system('more %s' % filename) == 0:

has a slightly different structure?  Why not 'more 2>/dev/null' or now 
'(more) 2>/dev/null'?

Logged In: YES 
user_id=33168

I tested more carefully on Linux and using parens works
either around just less or everything.   The problem was I
didn't restart python between runs, I used reload().