Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister


( #480=superdoc: print w/ replies, xml ) Need Help??

If you've discovered something amazing about Perl that you just need to share with everyone, this is the right place.

This section is also used for non-question discussions about Perl, and for any discussions that are not specifically programming related. For example, if you want to share or discuss opinions on hacker culture, the job market, or Perl 6 development, this is the place. (Note, however, that discussions about the PerlMonks web site belong in PerlMonks Discussion.)

Meditations is sometimes used as a sounding-board — a place to post initial drafts of perl tutorials, code modules, book reviews, articles, quizzes, etc. — so that the author can benefit from the collective insight of the monks before publishing the finished item to its proper place (be it Tutorials, Cool Uses for Perl, Reviews, or whatever). If you do this, it is generally considered appropriate to prefix your node title with "RFC:" (for "request for comments").

User Meditations
Pi Zero
4 direct replies — Read more / Contribute
by hippo
on Nov 26, 2015 at 05:22

    The Pi Zero is out today. While nobody can predict the future it is certainly a possibility that this could be a huge deal in terms of the next generation of programmers. In order to help them to get the best start possible there ought to be a big effort to allow the installation of perl on this little box of tricks in a way that is as simple and fault-tolerant as possible for the novice.

    Is this a realistic goal? I do hope so. With the demise of Java this could represent the best opportunity to avoid another single-language-fits-all monopoly over the next 20 years.

    Caveat: I know next to nothing about RaspberryPi so far and the Pi Zero may even come with perl bundled already, in which case feel free to call me a numpty. However, I would rather raise awareness and be thought foolish/ignorant than let this go by without having tried to do something to raise awareness. I will be trying to track down one of these little wonders for my own edification (as no doubt will quite a few of you) and it would be great to be able to flex Perl's muscles on such a potentially ubiquitous platform.

    If you have any good links to Perl on the Pi, please reply. Thanks, Hippo.

Something that bugs me about the Numeric class hierarchy in Perl 6
1 direct reply — Read more / Contribute
by grondilu
on Nov 24, 2015 at 03:16

    Hello Monks,

    This is something that has bugged some times to times : I have the feeling that the class hierarchy for numeric types in Perl 6 is upside down.

    Let me give you an example. The other day I wrote on rosetta code the following function to compute binomial coefficients:

    sub infix:<choose> { [*] ($^n ... 0) Z/ 1 .. $^p } say 5 choose 3;

    I was quite happy about it, until I realized that the output was of type Rat, not Int. So I had to make an explicit conversion:

    sub infix:<choose> { ([*] ($^n ... 0) Z/ 1 .. $^p).Int }

    That was a bit annoying. Frankly, I expect something like 10/5 to be an integer, not a rational. I mean, I know it is a rational, but it also is an integer. Because normally in math, all integers are rationals. Their denominator is just 1.

    Things don't work like this in Perl 6. Numeric types are more about implementation than mathematics. Yet there is a feature in Perl 6 that could be used to make things work more like in math:

    subset Int of Rat where [%%] *.nude;

    If Int was defined as such, integers would be particular cases of rationals. In the same way, real numbers would be special cases of complex numbers:

    subset Real of Complex where { $_ == .conj };

    An other possibility would be:

    role Int does Rational { method nude { self, 1 }; ... }

    Or something like that, I don't know. Neither do I know if it would be possible or desirable to rewrite the whole Numeric hierarchy. Maybe it would not be worth the effort. But I do find it annoying that an Integer is not a Rat, or a Real not a Complex.

"Indirect" object syntax?
3 direct replies — Read more / Contribute
by muba
on Nov 22, 2015 at 21:30

    Disclaimer: IANAL. I am not a lawyer linguist.

    The syntax of (for example) $cgi = new CGI; is called indirect object syntax, which is also said to be in the dative case. Are these actually the correct designations?

eval error stack
2 direct replies — Read more / Contribute
by shmem
on Nov 11, 2015 at 16:13

    There's the perl special variable $@ which is set at eval errors. It is a global variable, and it is a SCALAR type variable. It gets easily clobbered if you don't proceed with utmost care (tye wrote some nodes about that) and fails to report the really interesting thing, e.g. in nested evals. Consider:

    my $foo = eval { my $bar = baz(); if ($@) { die "baz failed!\n"; } }; die $@ if $@; sub baz { eval "1 = 2"; } __END__ baz failed!

    With that code, there's currently no way to get at the real problem, which is in the baz code, where $@ is set to

    Can't modify constant item in scalar assignment at (eval 1) line 1, at + EOF

    and gets clobbered by my $foo = eval {...} Of course, the above program would have reported the baz() error, if baz()behaved well:

    sub baz { my $result = eval "1 = 2"; die $@ if $@; $result; }

    Nonsensical assignment reported, but where is the error from my $foo = eval { };? Looks like I have to set up a die signal handler, or some such. This is all very confusing and doesn't DWIM.

    And you cannot rely on $@ being propagated properly, unless you revise any included code that uses eval, which is pretty much anything, because eval is the heart of any perl code. All perl code is somehow evaled.

    Back to $@ - a SCALAR. Why don't we have @@ as an error stack, and a builtin %@ hash keyed upon the names of the stack frames (e.g. Package::sub or 'eva123') or such?

    The variables @@ and %@ currently (well, I have perl v5.18.2) work as a regular array/hash. But *@{SCALAR} isn't related to $@ at all.


    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
Building the Right Thing (Part III): Customers
1 direct reply — Read more / Contribute
by eyepopslikeamosquito
on Nov 01, 2015 at 01:37

    After introducing Lean startup in the last episode, this installment focuses on good ways to communicate with customers.

    Don't do what customers say they want, understand their problems and solve them.

    -- Per Haug Kogstad (Tandberg founder)

    Problems, Products and Markets

    Most startups begin with a brilliant new product idea. Most startups fail. While pulling an ingenious new product idea from your lower torso may work on occasion, a more systematic approach is to perform a sober analysis of the following three aspects:

    • A problem is the reason people want your product. Is it a big enough problem for people to pay you to solve it?
    • A product is the way you solve the problem. Are you capable of solving the problem? How do you know if you've found the "best" way to solve the problem? Are there other ways to solve it?
    • A market is a group of people who might want to buy your product. Who wants the problem solved badly enough to buy your product? Can you build a sustainable business in this market?
    Perhaps the worst way to answer these questions is to ask the customer what they want.

    A more promising approach is to observe and listen to the customer, so as to gain a deep understanding of their problems. Focus on their big problems, the ones they'll be glad to pay you to solve.

    You need to differentiate between cool and interesting problems and real problems for real people. Laura Klein gives some examples:

    • Word processors solved the problem that it was tough to edit something once you've typed it.
    • GPS navigation solved the problem that we are likely to get lost when away from our homes.
    • Angry Birds solved the problem of delivering pleasure hormones to our brains while waiting for a train.
    Admittedly, this is hard to predict and there is no guarantee of success. Is playing Angry Birds while waiting for a train really a vital problem? While there is no guarantee of success, and yes, most startups fail, early validation of product ideas ensures you fail as cheaply as possible, allowing you more shots at success.

    Customer Interviews

    Justin Wilcox suggests you start by asking your customer two introductory questions:

    • How do you describe your role?
    • What does success look like for you?
    With that context clarified, ask the following five questions:
    • What's the hardest part about <your problem context>?
    • Can you tell me about the last time that happened?
    • Why was that hard?
    • What, if anything, have you done to solve that problem?
    • What don't you love about the solutions you've tried?
    Notice that we are trying to steer away from hypothetical questions, in search of genuine problems that might be used to start a new business or grow an existing one.

    After the customer interview, you need to go away and figure out if you can build a solution to any of their big problems.

    Solution Interviews

    Rather than pitch a proposed solution to the customer with a demo that ends with them saying: "Thanks very much, we'll get back to you", Wilcox recommends doing a Solution Interview instead.

    • Don't start with a demo!
    • Pick the big problems from the customer interview that you think you can solve. Restate the problem; for example, I heard about this problem you have. Is that right? You need confirmation that you've properly understood their problem.
    • Propose a potential solution. Honestly ask for feedback. What do you think about this solution? Initiate a two-way discussion.
    • Finally, now we agree we've got the right problems, and we think we can solve them together, what do we need to do to make progress? What are the next steps? Make a to-do list with the customer.
    The general idea is not to pitch your solution, rather to engage the customer, build trust, build a partnership.

    User Testing

    If the Solution Interview went well, build a prototype solution (MVP) and observe the user interacting with it. Don't fall into the trap of building a broad MVP that is crappy and unusable. Instead, build a usable, but limited, version of your product.

    Laura Klein gives some tips on how to get good feedback from customers, based on years of watching mistakes made by folks lacking a user-experience background:

    • Shut the hell up. You want their opinions, not your own. You also need to give them more time than you think to figure things out on their own.
    • Don't give a guided tour. Let the user explore a bit on his own. Then give the user as little background information as possible to complete a task.
    • Ask open-ended questions. The more broad and open-ended your questions, the less likely you are to lead the user and the more likely you are to get interesting answers.
    • Follow up. For example, if the user says "that was cool", follow up and ask precisely why that was cool. Don't assume you know what makes a product cool.
    • Let the user fail. This can be painful, especially if it's your design that's failing. You're not testing if a person can be shown how to use a product, you're testing to see if a person can figure out how to use the product.

    Quantitative vs Qualitative research

    Quantitative research, for example A/B testing or Funnel analysis, measures what real people are actually doing with your product. It's statistically significant.

    Qualitative research, for example customer interviews and observing users and understanding their behavior, gives important insights, but is not statistically significant.

    Quantitative research tells you what. Qualitative research tells you why. You need both.

    Miscellaneous Tips

    Some general tips taken from a talk by Atlassian Product Manager Sherif Mansour on Building the right thing:

    • Distill customer interviews and customer conversations into a manageable set of Personas. Make these personas visible to everyone (Atlassian even stick them in the toilets).
    • Ask why. Understand why.
    • Find the root of the problem.
    • Understand the problem.
    • Define the solution.
    • User Journey Mapping. Shows end to end flow of a persona using a feature, starting with installation.
    • Get the user journey right (e.g. map out how someone enters/exits a feature).
    • Fake it till you make it. They use a variety of Pretotyping techniques as discussed in episode one; e.g. recording videos and showing to customers to elicit feedback.
    • Get feedback before you start (fake to validate you are building the right thing).
    • Choose carefully (beware domino effect).
    • Tell your story. Before you start. Build your box (hero shot, pitch and three pillars).
    • Assume no docs. This changes how you build your solution.

    Perl Monks References

    External References

Looking for Stuart Lory, author of CPAN Text::Banner module
No replies — Read more | Post response
by toolic
on Oct 29, 2015 at 09:19
    UPDATE: Success! ambrus sent me a private message with another email address he dug up from a 2001 message on perl5porters. I sent an email, and the author responded.
    Original post:

    Does anyone know of a way to contact Stuart Lory, the author of the CPAN Text::Banner module?

    I am at step 4 of the PAUSE procedure for taking over a module ("Try posting in public places such as ...").

    I have tried to contact the author by sending emails to 3 addresses: from the AUTHOR section of the POD, the Email listed on, and the generic All 3 emails bounced immediately.

    As far as I can tell, this author uploaded the module in 1999 and has never uploaded any updates to it. There are a few bugs reported on RT (the first in 2008), but the author never updated any of those reports.

OOP: A Bird's Eye View
3 direct replies — Read more / Contribute
by Arunbear
on Oct 27, 2015 at 12:04

    Most tutorials that teach Perl OOP (Object Oriented Programming) focus on the nuts and bolts (which is important), but neglect the equally important "Why" or reasons for using OOP. This is an attempt to remedy that, in the form of a story.

    A fable

    There once was a farmer who had a flock of sheep. His typical workday looked like this:
    $farmer->move_flock($pasture); $farmer->monitor_flock(); $farmer->move_flock($home);
    Eventually, due to successful wool sales, he expanded his farming activities and his day become like this:
    $farmer->move_flock($pasture); $farmer->monitor_flock(); $farmer->move_flock($home); $farmer->other_important_work();
    But now the farmer wanted to devote more time to other_important_work(), so he decided to hire a minion to handle the sheep related work, so the work was now split like this:
    $shepherd_boy->move_flock($pasture); $shepherd_boy->monitor_flock(); $shepherd_boy->move_flock($home); $farmer->other_important_work();
    This did give the farmer more time for other_important_work(), but unfortunately $shepherd_boy had a tendency to cry wolf so the farmer had to replace him with a new minion:
    $sheep_dog->move_flock($pasture); $sheep_dog->monitor_flock(); $sheep_dog->move_flock($home); $farmer->other_important_work();
    $sheep_dog was more reliable and demanded less pay than $shepherd_boy, so this was a win for the farmer.



    To handle complexity, delegate to a suitable entity e.g. the farmer delegates some of his work to $shepherd_boy.


    Tell objects what to do, rather than micro-manage e.g.
    rather than
    $sheep_dog->{brain}{task}{monitor_flock} = 1;
    At a high level, we do not particularly care what the internals of the object are. We only care what the object can do.

    But, an object becomes harder to change the more its internals are exposed.


    $sheep_dog and $shepherd_boy both understood the same commands, so replacing the latter with the former was easier than it would have been otherwise.

    I've had this in my scratchpad for a long time and I'm sure there's more that can be said, but I finally decided to post this after reading OOP's setter/getter method - is there a way to avoid them? in case anyone finds it helpful.

Building the Right Thing (Part II): Lean Startup
1 direct reply — Read more / Contribute
by eyepopslikeamosquito
on Oct 21, 2015 at 17:11

    Just like pretotyping, discussed last time, Lean startup was a love-child born from the ashes of entrepreneurial catastrophe.

    Having experienced devastating failure in his first two Startup adventures (Catalyst Recruiting and, Eric Ries understandably became highly motivated to make sure that never happened to him again ... finally achieving startup glory at his third attempt, at IMVU in 2004.

    Having experienced both heady success and catastrophic failure at startups, Ries was well qualified to develop a methodology to help startups succeed: Lean startup.

    Ries was fortunate to have Steve Blank, a formidable methodologist, as his mentor at IMVU and he became Blank's star pupil. Indeed, Blank's "Customer Development" became a cornerstone of Ries' subsequent Lean Startup movement. Nowadays, Ries spends most of his time advising companies and teaching entrepreneurship.

    Ries' experiences are not atypical: most startups fail. Indeed, the world is crying out for a way to reduce the waste and misery associated with failed startups.

    Not only that, but with disruptive technologies on the rise, it's becoming more crucial than ever for established companies to innovate to survive.

    Lean Startup vs Pretotyping

    Lean Startup is an approach that is, to some extent, broader than the one put forward by "pretotyping". It's applicable before you get to the stage of having a "pretotype" (e.g. interviewing customers) and afterwards (when you're actually building and delivering live features.)

    -- Adrian Howard aka adrianh

    As usual adrianh is right on the money: Lean Startup is more ambitious than pretotyping, in that it covers all aspects of running a successful business, while pretotyping just focuses on identifying the right "it" to build. Put another way, pretotyping is a subset of Lean Startup.

    What is Lean Startup?

    After defining a Startup as:

    A human institution designed to create a new product or service under conditions of extreme uncertainty
    Ries defines Lean Startup as:
    A set of practices for helping entrepreneurs increase their odds of building a successful startup
    I think the key point here is "extreme uncertainty". Ries experienced first hand that traditional business practices, such as creating a detailed business plan, simply do not work in conditions of extreme uncertainty.

    Steve Blank gives his take on Lean Startup as based on three principles:

    1. Business model canvas. Instead of writing a detailed business plan, entrepreneurs list a series of untested hypotheses in a "business model canvas", a diagram of how a company creates value for itself and its customers.
    2. Get out of the building aka "Customer Development". Go out and ask potential users and partners for feedback on all elements of your business model. Rapidly assemble minimum viable products (MVPs) to aid in eliciting customer feedback. Based on this feedback, make further small adjustments (iterations) or big ones (pivots) to ideas that aren't working. Rinse and repeat.
    3. Use Agile software development to develop the MVPs.

    In the foreword to the Lean UX book, Ries further comments:

    Lean Startup is a big tent. It builds on established ideas from many disciplines, from lean manufacturing to design thinking.
    Clearly, there are many ideas and influences behind the Lean Startup movement, and it is constantly evolving.

    Product Features vs Business Outcomes

    Laura Klein gives a practical example that further clarifies what Lean Startup is about:

    Before Lean UX, Company X might have said, "We need to record user comments for each product and display them on the product page". The product manager would have spent time writing a spec for comments on product pages. A designer might have come in and designed a great comment experience. Engineers would then have written code that matched the spec and the design. The whole process might have taken two or three months. At the end of the process, the product pages would allow users to leave comments. But so what? Would this make users spend more money on products? Would they stick around for longer? Would users even bother to leave comments? What is the actual benefit to the company for spending those three months?

    The problem with this approach is that it starts with a feature rather than a hypothesis. It assumes that comments on product pages are necessary rather than identifying a user problem, coming up with an idea that might solve that user problem, and designing a test to see if the idea is true. A more Lean approach is:

    Based on our preliminary research, we believe that allowing users to leave comments on product pages will cause customers to become more engaged and buy more items. How can we figure out if thatís true?

    Now this has been stated in a way that allows the company to validate the hypothesis and easily change the feature if it turns out to be the wrong way to improve the metric.

    That is, we focus on Business Outcomes, not Product Features.

    Lean Startup vs Agile

    Mary Poppendieck provides an interesting comparison between Agile and Lean Startup:

    AgileLean Startup
    Product RoadmapBusiness Model Canvas
    Product VisionProduct Market Fit
    Release PlanMinimum Viable Product
    On-Site Customer"Get out of the Building"
    IterationBuild-Measure-Learn Loop
    Iteration ReviewPersevere or Pivot
    Backlog"To Learn" List
    User StoryHypothesis
    Acceptance TestSplit Test
    Definition of DoneValidated Learning
    Continuous IntegrationContinuous Deployment
    Customer FeedbackCohort-based Metrics
    Product OwnerEntrepreneur
    Certified Scrum MasterCustomer Success Manager

    The February Revolution

    In an attempt to cut through the considerable jargon and dogma from many competing methodologies, such as impact mapping, feature injection, real options, hothousing, user story mapping and similar, Gojko Adzic and others got together to try to distill the essence of these techniques into a simple set of principles. They came up with the following "february revolution".

    Great results happen when:

    • People know why they are doing their work.
    • Organizations focus on delivering outcomes and impacts rather than features.
    • Teams decide what to do next based on immediate and direct feedback from the use of their work.
    • Everyone cares.

    Departmental Silos

    How is it possible that our departmental silos are operating with agility, but our companies are hopelessly rigid and slow? From our far-off vantage point, we have missed something essential. Although our departments may value agility, the interconnections between them are still mired in an antiquated industrial past.

    -- Eric Ries (in the Foreword)

    I'm interested to learn how your company is run. What works, and what doesn't, for you?

    Perl Monks References

    External References

RFC: (Do Not) Modify the System Perl
9 direct replies — Read more / Contribute
by MidLifeXis
on Oct 16, 2015 at 14:39

    Update: Excellent points made in responses. A rewrite is in the works. Keep them coming.

    Perhaps this is a tutorial, or perhaps something that just belongs long term in Meditations, but my intent with this node is to document the arguments related to modifying the system's Perl installation, so that I don't have to lay out the argument every time it comes up in SoPW. There are some pro, and some con, but it seems to be, in my experience, that "Can't touch this", if given the choice, is the correct path to take.

    Some of the previous comments I have made on this topic can be found here: SuperSearch Preload

    So, without further ado, here are some arguments in favor of installing your own Perl (in no particular order):

    • Modifying the system Perl can break the OS.
    • Updating the OS can change the underlying Perl, breaking your application.
    • You don't necessarily have control over the system's Perl.
    • Updating the system's perl for application's needs can go against another application's needs.
    • The system's Perl may not be complete.
    • By packaging Perl with your application stack, you control the installed modules and toolchain.
    • It is easier to target a single Perl version than anything you might find on the OS.
    • Policy may disallow installing a "necessary" module on the system's Perl.
    • Your installed / updated CPAN modules may be overwritten (and downgraded) by OS updates. - Corion
    • You are (safely) limited to the module versions provided in packages by your vendor - Corion

    There are also some cons to installing your own Perl:

    • Your application distribution now requires or includes a separate Perl distribution.
    • Your packaging requirements are now more complex.

    In summary, unless you are writing an OS-level tool specifically for this platform, install a Perl version specifically for your own application's runtime stack.

    Anything else? (ed: updates tagged with author)


Crash-Test Dummies: A Few Thoughts on Website Testing
4 direct replies — Read more / Contribute
by sundialsvc4
on Oct 08, 2015 at 15:34

    In the last few days, an article was published, referenced in another thread, which made Perl look bad.   (The problem had to do with processing CGI parameters, and list vs. array context.)   But, actually, this is a very common problem with many ... dare I say, most? ... web sites.   The problem is that, when subjected to a barrage of nonsensical (or contrived) inputs, many sites fail disastrously and repeatedly.

    Many web sites (and a growing number of mobile apps, with regards to their host interfaces) are, simply, untested with regard to their ability to operate in any path that deviates, however slightly, from what the site’s designers “expected” it to do.   (Maybe) they ran through all the buttons and screens.   (Or, maybe not.)   But what they never did was to seriously beat it up.   Unfortunately, that’s exactly what rogue attackers will do.   (Yes, one of the first things that they will do is ... test your code.)

    HTTP, leave us not forget, is a completely stateless protocol.   The server receives a request consisting of a URI (including any GET parameters), a set of cookies, and possibly POST parameters.   It produces an HTML (or AJAX) result, and promptly forgets.   Everything.   Well, the thing that many developers completely overlook is that these inputs can be anything.   Although you may expect that they consist only of what the corresponding <form> would generate, you must never assume this.   The inputs to your web page ... can ... be ... anything.   Therefore, attackers (or, testers) will subject your site to URIs in unpredictable sequence with unpredictable or deliberately-altered parameters.   They will look to exploit things that you assumed.   And usually they will find them.

    Consider what happens if the rogue simply duplicates a GET string.   In many cases, the variables become multi-valued ... arrays ... since there is now more than one value for the variable.   Or, what if the rogue adds another variable to the string, such as &is_admin=1?   (You’d be shocked how often that turns you into a god ...)   Mispelin a variable-name can cause an error-dump that might include literal SQL text and server-IP addresses.   And so on.

    One of the very first things we do at Sundial, with any new web site that we are asked to evaluate, is to put it into a test-bed and “hit it with both barrels.”   I can count on the fingers of one hand how many sites survived the onslaught entirely unscathed.   And yet, the automated test-tools are readily available (or, can be built in Perl).   The builders of the site could have made the thing bulletproof ... they simply didn’t bother.

    Perl has many unique features, like “taint mode,” that if properly used can greatly strengthen your software.   But these are only as good as your ruthless and unforgiving test plans.   Don’t send your software out into the world unprepared.

Perl 5 Optimizing Compiler, Part 16: RPerl v1.2 Kickstarter Challenge
4 direct replies — Read more / Contribute
by Will_the_Chill
on Sep 25, 2015 at 08:20
Perl 5 Optimizing Compiler, Part 15: RPerl v1.2 Kickstarter Now Live
4 direct replies — Read more / Contribute
by Will_the_Chill
on Sep 22, 2015 at 05:15
    Greetings, Monks!

    I am proud to announce the launch of our next Kickstarter campaign.

    We immediately reached our minimum of $1,701; now our goal is to reach $20K in the next 9 days. We can do it... WITH YOUR HELP!

    STEP 1: Make a generous pledge.
    STEP 2: Get your friends to match your pledge.
    STEP 3: Get your boss to double your pledge.
    STEP 4: Go back and increase your pledge.

    Thanks so much for your continued support of RPerl!

    ~ Will the Chill
Most well-known Perl-powered product?
7 direct replies — Read more / Contribute
by u65
on Sep 21, 2015 at 21:54

    I had the pleasure this afternoon of being interviewed by a local, online publication about our new Perl Mongers group ( Among other things, the interviewer asked me to name a Perl-powered product that would be known by many lay persons. I have found one list here, but I'm afraid most non-programmers I know would not recognize most, if not all, of those. Realizing that the interviewer's audience are local non-techies, how would you respond?

    My off-the-cuff response was big, open-source projects like Linux, Git, and Subversion use Perl behind the scenes, but she has given me a chance to come up with something perhaps more well-known to the average iPad user. So any better suggestions are welcome and will help in a small way to spread the word about Perl.

    Thanks for any input.

SSH to Java based SSH server
No replies — Read more | Post response
by Beatnik
on Sep 16, 2015 at 16:22
    First post in over 10 years. Ugh!
    Recently, I had to work with a Java based SSH server (based on SSHTools, sometimes forked as J2SSH). I tried different options (ignoring the fact that some SSH modules are an absolute pain to install). There were different reasons why one or the other solution didn't work. Public key authentication was not support (don't ask), Expect was at the top of my list either. In the end, I made it work with Net::OpenSSH and the pty mapping to Net::Telnet. From POD:
    my ($pty, $pid) = $ssh->open2pty({stderr_to_stdout => 1}) or die "unable to start remote shell: " . $ssh->error; my $telnet = Net::Telnet->new(-fhopen => $pty, -prompt => '/.*\$ $/', -telnetmode => 0, -cmd_remove_mode => 1, -output_record_separator => "\r"); $telnet->waitfor(-match => $telnet->prompt, -errmode => "return") or die "login failed: " . $telnet->lastline; my @lines = $telnet->cmd("who"); ... $telnet->close; waitpid($pid, 0);
    The Prompt needed to be adjusted as the COTS had its own customized prompt.
    ... I'm belgian but I don't play one on TV.
Should I come back to Perl?
7 direct replies — Read more / Contribute
by jekyll
on Sep 11, 2015 at 07:16


    maybe this is not a good forum to ask this, but on reddit they were rather quiet ... :-)

    I exclusively used Perl 5 and a bit of JavaScript and PHP for my first job, then I somehow focused on PHP completely and started to make money with it. Writing scripts in other languages was never a job choice for me, I just like to learn new things. (Although I guess that knowing more languages will highly increase my job chances anyway.) The occasional Perl here and there (a fun IRC bot in my spare time, a text parser for some of my colleagues at work) was never gone but I didn't invest much time into it.

    Some day I needed a website parser for the PHP tool I had been hired to develop. As I had read about Python's urllib just a short time before, I decided to implement that script in Python, not being aware of the actual difference between Python 2 and Python 3. Another hobby, I thought. When the script was nearly complete, I learned that Python 2 is about to be phased out slooooowly and Python 3 lacks a comparable community yet. I assume Python 4 will cause even more trouble, and it's not really worth all that.

    I have a couple of other projects in my "To do when there's some more spare time left" list, including a rework of the particular Python script and some web development things. I guess some will be in Common Lisp (learning languages by implementing things in them has always worked out for me), but I also will revive my Perl knowledge. I just don't want to switch to Perl just to see it suffering from the same problem too, Perl 5 being slowly phased out and Perl 6 being not widely accepted. If Perl 5 won't have the same "future" as Python 2, I'm happy to join the old Perl club again; otherwise, I (again) don't really know what to do.

    I don't want to rewrite my code every few years just because someone decides that the language I wrote it in is deprecated for no good reason now. Does anyone of you have a deeper, reasonable clue about what will happen with Perl 5 when Perl 6 has gained enough attraction?

    Regards and all that, jkl

Add your Meditation
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?

    What's my password?
    Create A New User
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others studying the Monastery: (4)
    As of 2015-11-28 20:54 GMT
    Find Nodes?
      Voting Booth?

      What would be the most significant thing to happen if a rope (or wire) tied the Earth and the Moon together?

      Results (744 votes), past polls