Is there a "poor man's" perldoc?
in [Perl]
|
From: John Bokma on 5 Mar 2010 12:15 Sherm Pendley <sherm(a)debian.shermpendley.com> writes: > 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. Not argueing with you there. OTOH I see no great harm in 1 (or maybe more) additional modules, and a bunch of text files. >> 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. Yup, true. On the other hand a customer might run SunOS with perl 5.0xxx ;-) -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development
From: John Bokma on 5 Mar 2010 12:20 Jürgen Exner <jurgenex(a)hotmail.com> writes: > 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. I haven't seen anybody implying such a thing. Why is it that working remote seem to imply you're working on a live server? There *are* situations where the development environment is remote. And in that case it's good to have perldoc available on that system. Not only because reproducing the environment on your own computer for the sake of having access to the documentation that comes with Perl is cumbersome (or might even be impossible), but also because it's useful to read the documentation of custom Perl modules. And customers who want you to work on their development computers are often not happy when you download the custom modules to your own computer so you can read the documentation with perldoc locally ;-) -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development
From: J�rgen Exner on 5 Mar 2010 13:25 John Bokma <john(a)castleamber.com> wrote: >J�rgen Exner <jurgenex(a)hotmail.com> writes: > >> 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. > >I haven't seen anybody implying such a thing. Why is it that working >remote seem to imply you're working on a live server? Well, servers came up as an example of an environment where there is no need for documentation on the machine. >There *are* situations where the development environment is remote. And >in that case it's good to have perldoc available on that system. No question about that! On a development system, no matter if local or remote, you do want and need all the tools that make you productive. You wouldn't put up with ed, either, instead of vim or emacs or whatever your favourite editor is. jue
From: Mart van de Wege on 6 Mar 2010 04:12 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. Quite frankly, I disagree. When I am debugging a production problem, and part of the problem is perl scripts and/or modules, it's convenient to read the docs in-place, especially since I know the version of the docs should fit the deployed perl. Mart -- "We will need a longer wall when the revolution comes." --- AJS, quoting an uncertain source.
From: Peter J. Holzer on 6 Mar 2010 04:14
On 2010-03-05 16:59, J�rgen Exner <jurgenex(a)hotmail.com> wrote: > 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. Unless you're a consultant called in to fix something. Then it's damned convenient to be able to read the docs of the scripts and modules which are actually installed on the server with the problem instead of those on your home system without the problem. Oh, and perldoc -l Module::Name is also nicer to type than perl -MModule::Name -le 'print $INC{"Module/Name.pm"}' hp |