in reply to Shell style line-editing without benefit of CPAN modules

Dear Boss,

Hello, how are you? I am doing well. I want to give you an update on my progress.

As you know, part of our product includes a command-line processor, where users can edit their commands, review previous commands, and edit and resubmit previous commands. This is familiar to anyone who's used a capable command-line on a Unix-like operating system, for example.

This is quite possible in Perl. However, I've come to a place of decision and would appreciate your guidance; I have two incompatible alternatives that affect the schedule. Can you advise me on which requirement is more important?

As you know, The Great and Powerful Code Image Builder Who Cannot Be Argued With has selected a small number of Perl modules, beyond which he will not install any more. There are several very capable Perl moduels which provide the command-line history and editing capability our product requires. They are small, well-tested, and well-documented. I estimate that we could integrate one into our product (from me selecting it, understanding its documentation, testing it, and having it installed into our image) in one afternoon.

If keeping the image as it is is more important, I estimate that it will take at least two weeks for me to reimplement this feature by myself. I have some confidence that I can get it working on our major platform, but with each subsequent platform, my confidence wavers. The difficulty of this task relates to historical standards for character sets, user shells, command characters, and terminal settings. For a good time, read through /etc/termcap on a Unix-like OS sometime.

A third option, of course, is to remove this feature.

As you can see, each of these options has positives and negatives which affect the end product. I feel that this is a decision which can best benefit from your input.

Best regards,
Ken

  • Comment on Re: Shell style line-editing without benefit of CPAN modules

Replies are listed 'Best First'.
Re^2: Shell style line-editing without benefit of CPAN modules
by SirBones (Friar) on Nov 18, 2006 at 22:37 UTC

    Yes, yes. ++chromatic

    To be a little more clear about the nature of my utility, it's not going to packaged as part of the final product. The machines themselves are controllers for much larger systems, and will go out to customers in this "plain vanilla" configuration for logistical, legal, and whatever reasons. My Perl code is only being used for engineering debug and bringup, and will be long gone before the machines go out. It's (usually) not the inclination of my boss to make my work more difficult; this is an unusual circumstance.

    So in fairness, there are a lot of complex issues involved, and I didn't mean to over-simplify the Dilbert-nature of my workplace. Not in this case, anyway. ;-)

    -Ken

    "This bounty hunter is my kind of scum: Fearless and inventive." --J.T. Hutt

      That's different, but I still think my point applies. The policy of not installing modules has a sane reason (we both assume), but in this case it has a cost tradeoff greater than a couple of hours. I don't see it as your job to decide how to proceed in such a case. I don't know what the right answer is for your business, but I do think it's worth bringing this up to your boss for advice.

      This is one of those cases where something you didn't forsee in advance has the potential to change the scope of the work or the schedule. That happens. The best thing you can do is to identify it, be honest about the costs of all of the options, and let the person whose job it is to adjust the schedule or the scope do so.

      SirBones:

      In that case, perhaps you could get someone to relent and let you install it in a *local* directory (like ~/perlib), and add that directory to your @INC for your debugging scripts. Then you can remove it all before delivery. That way, it needn't contaminate the normal /usr, /bin, /etc, etc. directories.

      --roboticus