Is there a "poor man's" perldoc?
in [Perl]
|
From: John Bokma on 5 Mar 2010 11:55 Sherm Pendley <sherm(a)debian.shermpendley.com> writes: > "jl_post(a)hotmail.com" <jl_post(a)hotmail.com> writes: > >> That might work, if only I lived anywhere near the administrator. >> But in some cases, (s)he's in another country altogether. > > There's this thing called "email," you see... :-) > >> Sadly, some people just don't think the perldocs are all that >> important. > > Having perldocs on a production server is *not* important. You > shouldn't be using that server for development work anyway. With > VirtualBox et al, you can easily mirror whatever deployment config > you need, right on your desktop, and install the tools and docs > you need on that. There is such a thing as working on a remote development server ;-). While you can mimick the development environment on your own machine, it might not always be easy to do so. -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development
From: J�rgen Exner on 5 Mar 2010 11:55 Bart Lateur <bart.lateur(a)telenet.be> wrote: >J�rgen Exner wrote: > >>"jl_post(a)hotmail.com" <jl_post(a)hotmail.com> wrote: >>> I use the perldocs frequently when I'm programming in Perl. >>>However, on some systems I've used, "perldoc" is apparently not >>>installed (despite the fact that Perl is). >> >>Then you may want to kick the administrator until he fixes the broken >>installation. > >Yeah, yeah. > >Why not complain against the people making the Linux distributions. A >lot of them, if not all, separate the perl binary from the core modules. Not sure if you really meant core modules or rather perl documentation. As for the documentation being in a separate package that is actually logical when thinking about servers (of all kind). Documentation is for human consumption during code development and nobody in his right mind would develop code on a live server. On the contrary, in a server environment you want the configuration to be as slick and streamlined as possible to reduce any even far-fetched chance of interference. Therefore I would expect servers not to contain any documentation. Of course omitting the docs in a developer's environment is unforegivable. jue
From: J�rgen Exner on 5 Mar 2010 11:59 Sherm Pendley <sherm(a)debian.shermpendley.com> wrote: >Ben Morrow <ben(a)morrow.me.uk> writes: > >> perldoc almost certainly *is* installed somewhere > >That's not necessarily true. Many Linux systems package perldoc >and the various .pod files into a separate perl-dev or similar >package. Which actually makes sense because you need those only while _dev_-eloping Perl code but not on any server that is running perl as a utility. jue
From: Sherm Pendley on 5 Mar 2010 12:00 John Bokma <john(a)castleamber.com> writes: > Sherm Pendley <sherm(a)debian.shermpendley.com> writes: > >> Having perldocs on a production server is *not* important. You >> shouldn't be using that server for development work anyway. With >> VirtualBox et al, you can easily mirror whatever deployment config >> you need, right on your desktop, and install the tools and docs >> you need on that. > > There is such a thing as working on a remote development server ;-). True, but what I said is still valid, whether the dev environment is on your desk or on the other side of the planet. Either way, it's the developer's machine that needs perldoc, not the deployment server. > While you can mimick the development environment on your own machine, > it might not always be easy to do so. It depends on the degree of accuracy you need. I don't have a Sparc workstation in the office, for example - but I can install Solaris in a VirtualBox instance, and for many purposes that can be close enough. sherm--
From: J�rgen Exner on 5 Mar 2010 12:07
Sherm Pendley <sherm(a)debian.shermpendley.com> wrote: >True, but what I said is still valid, whether the dev environment is >on your desk or on the other side of the planet. Either way, it's the >developer's machine that needs perldoc, not the deployment server. Exactly. Nobody in his right mind would develop code on a live server. And for those red hot fixes that have to be done this instance bypassing any and all testing and deployment procedures you can still check the documentation on your dev machine or in the worst case online. You are taking a very high risk anyway, the added risk of mismatched doc versions is negligable in comparision. jue |