Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Perl IDE and Programming Environment

Version 1.4 (Sep 012, 2019)

News

Chapter 1

 Recommended Links Defensive programming Perl Style Programming style Perl in
command line

Neatperl -- a simple Perl prettyprinter
Perl Lint Perl Prettyprinting Perl-friendly editors Perl debugger Perl Syntax Error Checklist Perl Xref Tools for detecting changes in sources (diff, sdiff, tkdiff, etc) Directory Syncronization Utilities
Perl POD documentation Literate Programming Html converters KISS Principle Perl options processing Perl one-liners More Complex Perl Regular Expressions  
Unix History Admin Horror Stories Software Engineering Language Design and Programming Quotes Larry Wall Tips Perl humor  Etc

Introduction

Great tools will never convert a bad programmer into a good programmer, but they will certainly make a good programmer better and they can make a bad language acceptable (Java is one such example).

A good, modern IDE should include interface to the following components:

There are two ways of approaching Perl IDE question

All language have quirks, and all inflict a lot of pain before one can adapt to them. Once learned, the quirks become incorporated into your understanding of the language. But there is no royal way to mastering the language. The more different is one's background is, more one needs to suffer. Generally good environment can compensate for some pitfalls of the language. Syntax highlighting is one such feature.

When mastering a new language first you face a level of "cognitive overload" until the quirks of the language become easily handled by your unconscious mind. At that point, all of the sudden the quirky interaction becomes a "standard" way of performing the task. For example regular expression syntax seems to be a weird base for serious programs, fraught with pitfalls, a big semantic mess as a result of outgrowing its primary purpose. On the other hand, in skilled hands its a very powerful tool that can serve as a parser for complex data and a substitute for string functions.

There are three notable steps in adaptation to Perl idiosyncrasies for programmers who got used to other languages:

  1. One early sign is when you start to put $ on all scalar variables automatically.  Most such cases are diagnosed by interpreter but some like $location{city} are not
  2. The next step is to overcome notational difficulties of using different two operations (like "==" for numbers vs eq for strings) for comparison numbers and strings. In case two variables are involved, the interpreter does not provide any warnings so you need to be very careful as if you use other language in parallel with Perl such errors crop into your scripts automatically. If one of the operators of "==" is a string constant automatic diagnostic can be provided.
  3. Conscious use of "==" as equality predicate for numbers, if you previous language allowed to used "=" for checking equality or assignments. The pitfall of using "=" for assignment, which results in side effect of introducing errors in comparisons  if ($a=1)...  instead of if  ($a==1) was understood by designers on Algol 60, which was designed is late 50th. To avoid it they used := for assignment instead of plain =. But designers of Fortran, PL/1 and later C as derivative of PL/1 ignored this lesson (actually Fortran predates Algol 60 so its designer were pioneers and are not guilty). As Fortran and C became dominant programming languages we have what we have.  Now talk about progress in programming language design if the design blunder about which designers knew 65 years ago still is present today ;-). So in all languages that have lexical structure of C it remains the  most rich source of subtle errors for novices. Naturally this list includes Perl.  As it it also present in C and C++, so C programmers are already trained to be aware about  this language pitfall ( if (a=1)... is as bad in C as in Perl) and are less affected.  Protective measures
    1. modify syntax highlighting so that such cases were marked in bold red.
    2. Manually or automatically (simple regex done in the editor can do 99% of cases) reorganoze such comparisons putting the construct on the left part of comparison, like in  if (1==$a)....
    3. Recent versions of Perl interpreter provide warning in this case so checking your script with option -cw also helps if IDE provides capability to display of results of checking of syntax in one of the windows and jumpt to the line in code listed in the error or warning (this is a standard feature of all IDEs and actually this can be done in most editors too). 

Known attempts to create integrated Perl IDE

Currently there is no good Perl IDE. There were several attempts to create one of different quality and sustainability, but none of the projects proved to be sustainable.

With Perl very limited financial support from big corporations (support that both PHP and Python enjoy) it is unrealistic to expect that there will be many offerings. Even open  open source offering has little chances to survive in such an environment,  as there not much volunteers and  money to provide support for the commercial version of IDE. The initial enthusiasm seldom last more the three-five years and after that the product is typically abandoned by the author. Source code remains but 10K of more of source code is in its level of in-comprehensibility as close to binary format as you can get ;-) 

Also Perl now is out of fashion. So commercial versions tend to die like files on the frost. No surprise that Microsoft does not support Perl in Visual Studio. 

That's why many promising projects of Perl IDE are stalled or became abandonware. Here I would like to warn you: a danger of choosing an IDE (or editor) that goes nowhere is real and is one of the most painful mistakes programmer can make. So the key in choosing here is stability and longevity.

that's why I generally recommend to opt for a separate editor, not the editor integrated into IDE. It takes a couple of years to master any editor with macrolanguage (editor without macrolanguage can't be  viewed as a programmer editor anyways)  and this investment should pay dividends the rest of your career. That essentially makes using IDE more risky that integrating your favorite editor into some framework with IDE features. 

For windows products a simple check is to see if the web page discusses compatibility of the product with 64-bit versions of Windows helps to determine if the development is continued. If not, then chances are that the development stopped a long time ago. Two products that are still maintained and updated are Komodo and Perl builder. Komodo has "cut down" free variant called Komodo Editorwhich probably can be viewed as a mininmally feature rish editor for any competent programmer.  It does not have XEDIT-style folding  but you can write plug-ins for it. 

It looks like others are in various stages of abandonment. For open source products this is less critical as there is always a forum and most critical problems eventually get fixed. But if the user community is small, this can be painfully slow and  even trivial fixes might not be implemented for years.  Of course, if you love particular product so much that you are ready to invest time is studying its codebase, you can fix it yourself (this is a somewhat realistic possibility if the IDE is written in Perl like Padre (http://padre.perlide.org/).

One interesting finding during writing of this article is that there is still a variety of products that  can be used as Perl IDE.  In this sense my findings actually surprised me. Not only there are some choices, but  some reasonably good choices do exist. Among them:

See also:

Assembling your own IDE from custom components

There are quality components that constitute IDE and another approach is to integrated them in "poor man IDE" using some suitable approach. there are two simple possibilities:

Use a programmable editor for integration

You can use the programmable editor as the integration framework (most programmable editors allow to invoke external programs as macros and even allow redirecting output of the program into editor windows. SlickEdit, Kedit, Gvim and Emacs are good examples of editors with those capabilities.

Advanced users of Emacs typically use this approach. Execution of script of a selection or total editing buffer is another powerful instrument of creating your own IDE. Both vim and Komodo editor 6 (unfortunately it was removed in Komodo editor 7) permit this. This way it is easy to implement brace counter, simple beautifier, etc. Also if you assemble your own IDE from components you can use the editor you already know and use. Actually the quality of editor is a very important consideration here. If should support syntax highlighting, split view of editing buffer, ability to execute scripting on editor buffer (like !! in vi. see Piping Vim Buffer Through Unix Filters: ! and !! Commands).

I would like to stress that the choice of editor is critical: many programmers are crippled by betting used to a simplistic editor that does not provide enough power for productive development (some pretty gifted programmers use Pico or Notepad or a similar light-weight editor without folding, split screen support, syntax highlighting and checking, ability to execute scripts on the buffer, etc.

Like Talleyrand used to say this is worse that a crime, this is a blunder ;-). And while features listed above are a must, generally a good editor for developer should be able to do more. See below description of SlickEdit and Gvim -- two prominent representatives of families of editors tuned to developers needs.

Perl developers have several options none of which is perfect. Beware guys who advocate primitive lightweight editors. As editor is such an important tool it makes perfect sense to pay a small amount of money for it. But you need to be sure about the longevity of the vendor. Switching editors is a very painful process. That means that free editors do not have an inherent advantage over commercial for developers as long as the price is not too steep, say, less then $100 or $200 depending on the country in which you work. Open source editors do have some advantage because of better staying power, but you can benefit from availability of open source only if you know well the language in which the editor is written and have time to tweak or debug it. Few people do. The real problem is the quality, features, longevity and portability of the editor.

I personally prefer editors that support command line command set. I call this class of editors "orthodox editors" and it has two prominent branches -- eastern (XEDIT, Kedit, THE, SlickEdit, etc, see Eastern Orthodox Editors) and western (vi, vim, gvim, etc). See Orthodox Editors for discussion of this class of editors.

As for longevity here for both free and commercial editors there no guarantee with the possible exception of VIM and THE which have established user populations and most probably will survive another 50 years. Here are some selections that can at least be tried:

VIM and GVIM

One possible "poor man IDE" is VIM and, especially GVIM. VIM has a macro language so it definitely qualities. The key advantage that system administrators already know it, although typically just small, very restricted subset. There are several Youtube presentation on how to use VIM with Perl.

Vim is not as great as specialized IDS but as most system admin know well you can achieve quite a lot by careful customarization. VIM provides syntax highlighting coding for Perl. The most important thing to learn are first additional ctags.

Vim has the following important features:

When using tags it is nice to have two windows split horizontally. Vim supports both vertical and horizontal window splitting. To split current window horizontally execute ":split" while in the normal mode. To split current window vertically, use ":vsplit" instead. If you don't provide any filename as argument to split/vsplit then current filename is used. You further split resulting windows as much as you like. Use Ctrl-w w to cycle through the windows. ":close" will close the current windows. ":only" will close all windows except the current one.

Vim provides facilities for reconciling differences between two "vimdiff main.pl main2.pl" (or "vim -d main.pl main2.pl") from the command line to see difference made to file main.pl in file main2.pl.

Vim will show both files in vertical split window mode. When you will scroll in one window, Vim will automatically scroll another window for you. You can patch the individual differences using do and dp commands. do will get the patch from the neighbor window and apply it to the current buffer, while dp will apply the difference from the current buffer to the neighbor window. If you need more information on this topic, read file /usr/share/doc/vim-common-6.1/docs/diff.txt.

Here is an excellent article of Leonid Mamchenkov Vim for Perl developers (May.10, 2004). Although written more then 5 years ago it is still the best intro into VIM facilities for Perl users. Below is an abbreviated version with some updates:

Text wrapping

As you code, sometimes text flows further than the width of the editor window. Some people like long lines to be wrapped (in other words, continued on the other line), while others prefer them unwrapped. You can configure Vim to behave according to your liking by adding "set wrap" or "set nowrap" to your .vimrc configuration file.

Flexible tabs

Tabulation is one of the hottest topics in programmers discussions when it comes to style. A very nice explanation of what is the problem with tabulations and spaces can be read at http://www.jwz.org/doc/tabs-vs-spaces.html. I must say though, that I don't agree with author's position on the subject. The article does provide you with several options for vi/Vim configuration to control the behavior of the tabs. I will just add/repeat the ones I consider important.

If you need more information on this topic, read file /usr/share/doc/vim-common-6.1/docs/indent.txt.

Line numbering

While Vim always displays your current position in the status line, you might also want to see all lines numbered. To do that, you will need to add "set number" to your .vimrc.

If you need more information on this topic, read file /usr/share/doc/vim-common-6.1/docs/usr_03.txt.

Syntax highlighting

The first thing any developer will notice in Vim is excellent syntax highlighting. All popular languages are supported. Syntax files for less popular are available from Vim web site. Perl is supported out of the box.

Vim identifies keywords, comments, variables, strings, in-line POD and other standard parts of the program and highlights them. Vim supports two color modes: one for terminals with dark background color and another one for terminals with light background color. You can control these modes by specifying command "set bg=dark" and "set bg=light" in your .vimrc.

If you still don't like the appearance of the code, stay tuned until "Color schemes" discussion.

If you need more information on this topic, read file /usr/share/doc/vim-common-6.1/docs/syntax.txt.

Text completion

One of Vim's features I cannot live without is text completion. When editing, press Ctrl-n / Ctrl-p to cycle through the current word completion suggestions. Vim generates suggest list based on the words in the current file. If you need key completion to make suggestions from other files, then Vim by default understand the ctags file. Simply run "ctags *.p?" to generate ctags for all Perl files and modules in the current directory (assuming you are using ".pl" extension for Perl scripts and ".pm" extension for Perl modules). This Vim's feature not only saves a tonne of time on typing, but greatly decreases the error rate, especially with long variable and procedure names in the code.

If you need more information on this topic, read file /usr/share/doc/vim-common-6.1/docs/usr_24.txt.

File Completion

While you are in the command mode, Vim can complete the names of files and directories in case you want to open or save a file. In order to complete a file or a directory name you should start typing it's name on the command prompt and then press the completion key. You can change the completion key to be almost anything you want with "set wildchar=" line in your .vimrc file.

Window splitting

Sometimes I need to see two or more files simultaneously. While I can always start another Vim session in a separate terminal, it is not as comfortable at times as Vim's window splitting feature.

Vim supports both vertical and horizontal window splitting. To split current window horizontally execute ":split" while in the normal mode. To split current window vertically, use ":vsplit" instead. If you don't provide any filename as argument to split/vsplit then current filename is used. You further split resulting windows as much as you like. Use Ctrl-w w to cycle through the windows. ":close" will close the current windows. ":only" will close all windows except the current one.

If you need more information on this topic, read file /usr/share/doc/vim-common-6.1/docs/usr_08.txt.

Diff mode

Vim provides excellent facilities for checking and editing differences between two or more files. Execute "vimdiff main.pl main2.pl" (or "vim -d main.pl main2.pl") from the command line to see difference made to file main.pl in file main2.pl.

Vim will show both files in vertical split window mode. When you will scroll in one window, Vim will automatically scroll another window for you. You can patch the individual differences using do and dp commands. do will get the patch from the neighbor window and apply it to the current buffer, while dp will apply the difference from the current buffer to the neighbor window.

If you need more information on this topic, read file /usr/share/doc/vim-common-6.1/docs/diff.txt.

Text folding

Yet another popular feature found in popular editors and IDEs is text folding. I think that folding is easier shown then explained. Vim supports six folding methods: by indent, by expression, by syntax, by changes in the text, by marker, and manual folding. For the sake of the example, I will show how to configure folding by marker.

In order to tell Vim to use folding by marker add the following lines to your .vimrc:

" Folding configuration
set foldmethod=marker
" Edit and uncomment next line if you want non-default marker
"set foldmarker="{{{,}}}"

If you need more information on this topic, read files /usr/share/doc/vim-common-6.1/docs/usr_28.txt and /usr/share/doc/vim-common-6.1/docs/fold.txt.

Marks

One of Vim's features that speeds up navigation is – marks. You can set a mark anywhere in the text and then quickly jump back to it. You can set several marks. You can set marks in several files and then quickly switch between them. I find myself set mark on the place I am currently working at with mc (m is for "mark", c I use for "current") and then quickly returning to the same place with 'c.

If you need more information on this topic, read file /usr/share/doc/vim-common-6.1/docs/motion.txt.

Vertical Indent Display

For some people indenting text horizontally is not enough. They need some kind of vertical indentation to help them see corresponding parts of the code. While I am not one of those people, I've seen this feature around so often that I decided to add it codemonkey's .vimrc.

All you need to do to have vertical indent display with pipe ("|") character is to add the following two lines to your .vimrc.

" This is for vertical indenting
set list
set listchars=tab:|
" NOTE the space char after last backslash.

":set list" forces Vim to show hidden characters like tabulations, ends of lines, and ends of files. ":set listchars=tab:| " asks Vim to show only tab characters and use a pipe ("|") with a space (" ") to do so, instead of usual "^I" thing that Vim likes to show.

Color schemes

Robert (MetaCosm) downloaded all color schemes and put them into a single archive file which he uploaded back to Vim's web site (http://www.vim.org/scripts/script.php?script_id=625.).

You will most likely notice that some color schemes do not change much colors in your console vim. That is because they are most probably designed for GUI version of Vim, called gvim.

Try executing "gvim +'colorscheme peachpuff' main.pl" to see how gvim looks with selected color scheme.

Now you can try all those color schemes one by one with ":colorscheme something" and choose the one you like best. When you are done choosing, add line "colorscheme something" to your .vimrc.

If you need more information on this topic, read file /usr/share/doc/vim-common-6.1/docs/usr_06.txt.

Block commenting

It is an often need to comment or uncomment blocks of code during the development cycle. While there is a way to do it in Vim without any additional configuration, I try to make life as easy as possible and install the BlockComment plug-in by Chris Russell.

Let's download BlockComment.vim from http://www.vim.org/scripts/script.php?script_id=473 and copy it into .vim/plugin/ directory. This plug-in automatically provides us with two mappings: ".c" for commenting code and ".C" for uncommenting code back.

File and buffer browser

Vim supports editing of several files simultaneously. One can start Vim as "vim main.pl main2.pl" and then use ":next" and ":previous" to navigate through open files (called "buffers"). It is also possible to open files for editing without quiting Vim every time. For that, one should use simple ":e main2.pl" command, where main2.pl is the name of needed file.

There are, as usual, better (more convenient) ways to work with files and buffers. Vim website lists few plug-ins which can handle only files, or only buffers, or both at the same time. One of those plug-ins is winmanager by Srinath Avadhanula. Let's grab winmanager from http://www.vim.org/scripts/script.php?script_id=95.

Vim's winmanager plug-in can make use of bufexplorer plug-in by jeff lanzarotta availalbe from http://www.vim.org/scripts/script.php?script_id=42.

Installation is as usual – saving, unziping, and dos2unixing. Since we don't want to always have file/directory browser turned on, lets add a mapping line to our .vimrc to ":WMToggle" by F2.

" This is for winmanager
map <F2> :WMToggle<CR>

If you need more information on this topic, read file /usr/share/doc/vim-common-6.1/docs/usr_23.txt.

Tag explorer

If you ask me, I am almost happy. The last thing that I am missing is something that will ease up my code browsing. I need a fast way of switching between different parts of my code and hierarchical view of it. Once again I go fishing to Vim web site and get myself a nice looking taglist plug-in by Yegappan Lakshmanan from http://www.vim.org/scripts/script.php?script_id=273. This one is not even an archive! You just need to copy it into your .vim/plug-in directory. Let's map ":Tlist" command to F3 key.

" This is for taglist
map <F3> :Tlist<CR>

One annoying thing that I find about taglist is that it resizes the terminal window when possible. I prefer to switch this feature off by add modifying my .vimrc in the following way.

" This is for taglist
let Tlist_Inc_Winwidth = 0
map <F3> :Tlist<CR>

If you need more information on this topic, read file /usr/share/doc/vim-common-6.1/docs/tagsrch.txt.

Perl syntax checking

..copy perl.vim (developed by Lukas Zapletal) into your .vim/compiler/ directory. Now we need to specify for which files we want Vim to use our new perl compiler scripts. This is easily done by adding the following lines to .vimrc.

" Use perl compiler for all *.pl and *.pm files.
autocmd BufNewFile,BufRead *.p? compiler perl

Now you can use ":make" to check your code for errors. If you do have problems in your code, then Vim will position the cursor on the line with the first problem. You can use ":cnext" and ":cprevious" to go through other error messages. ":clist" will show a list of all errors.

If you need more information on this topic, read file /usr/share/doc/vim-common-6.1/docs/usr_30.txt.

You can also check perl syntax in VIM on each save 

au BufWritePost *.pl,*.pm !perl -c %

With this macro every time you save a .pl or .pm file, it executes perl -c and shows you the output.

Perldoc integration

Yet another feature provided in most IDEs is on-line documentation. Vim helps developers even with that. By default, Vim comes with system manual support on all UNIX boxes. This comes very handy when you use system commands in your scripts and need to check command line parameters. Just position the cursor on the word that you are interested in and press K. Vim will execute "man word", where "word" is the word under the cursor. This is helpful but not as much as we need it.

Let's visit Vim site again and download Perldoc plug-in (developed by Colin Keith) from http://www.vim.org/scripts/script.php?script_id=209. unzip perldoc.zip and run all extracted files through dos2unix. It's a good idea to add a F1 mapping to ":Perldoc" in your .vimrc.

" This is for perldoc.vim
autocmd BufNewFile,BufRead *.p? map <F1> :Perldoc<cword><CR>
autocmd BufNewFile,BufRead *.p? setf perl
autocmd BufNewFile,BufRead *.p? let g:perldoc_program='/usr/bin/perldoc'
autocmd BufNewFile,BufRead *.p? source /home/codemonkey/.vim/ftplugin/perl_doc.vim

If you are using a newer version then I do, then you skip the last line.

Now, whenever you hit F1 while in the perl file, ":Perldoc" will get executed for the word that you have under the cursor, your current window will split horizontally and you'll see appropriate perldoc page.

After installation of this plug-in I have noticed that syntax highlighting in few of my programs broke. After a quick look, I understood that that happened because of my extensive usage of underscore ("_") character in procedure names. I had to fix it by simply adding underscore ("_") character to the list of keyword characters on line 14 in file .vim/ftplugin/perl_doc.vim.

" Adds / and . as used in requires.
" setlocal iskeyword=a-z,A-Z,48-57,:,/,.
" Adds / and . as used in requires. Also adds _ as used in procedure names.
setlocal iskeyword=a-z,A-Z,48-57,:,/,.,_

Komodo Editor

Komodo editor does not have built-in macro language but other then that it is a average editor

The key features include:

Notepad++

Notepad++ is a free simple editor which provides Perl syntax highlighting and basic editing features. I use it personally and its OK for small scripts. For larger scripts you might need more full-fledged editor like SlickEditor.

For Perl Notepad++ provides some useful features:

DzSoft Perl Editor

DzSoft Perl Editor ($49) is a good editor for Perl. It has built-in debugging features, a simple editor with syntax highlighting, a syntax check feature that finds errors in your script. Here is the list of features from the site:

Use of Orthodox File Manager for integration

Another simple way to integrate those components is to use orthodox file manager (OFM) such as Midnight commander in Linux, Far and Total Commander in Windows. Detail depends on capability of particular OFM and your imagination. You can also write you own plug-ins for the purpose. Here is some ideas from my own experience:

Running Perl in diagnostic mode

With OFMs it is possible to run Perl in diagnostic mode (options -cw) with one keystroke. You can bind this command to letter c in user menu. For example for FAR the command would be something like: 

c:\cygwin\bin\perl -cw !.!

Invoking debugger

You can assemble necessary invocation string on OFM command line or add external parameters inside the debugger (it is possible to change values of @ARGV array) 
c:\cygwin\bin\perl -d !.!

Invocation of Perl beautifier

Perl has one good beautifier (perltidy). Also Code2HTML can convert a program source code to syntax highlighted HTML.

Invocation of OFM is simlar to examples above.

Invocation of Lint module and creation of XREF table

Although this is not well known, but Perl interpreter has lint module and can produce cross reference table of all variables used. Here is what authors of Programming Perl wrote about this rarely used capability:

18.6. Code Development Tools

The O module has many interesting Modi Operandi beyond feeding the exasperatingly experimental code generators. By providing relatively painless access to the Perl compiler's output, this module makes it easy to build other tools that need to know everything about a Perl program.

The B::Lint module is named after lint(1), the C program verifier. It inspects programs for questionable constructs that often trip up beginners but don't normally trigger warnings. Call the module directly: 

perl -MO=Lint,all myprog
Only a few checks are currently defined, such as using an array in an implicit scalar context, relying on default variables, and accessing another package's (nominally private) identifiers that start with _. See B::Lint(3) for details.

The B::Xref module generates cross-reference listings of the declaration and use of all variables (both global and lexically scoped), subroutines, and formats in a program, broken down by file and subroutine. Call the module this way: 

perl -MO=Xref myprog > myprof.pxref
For instance, here's a partial report: 
Subroutine parse_argv
  Package (lexical)
    $on               i113, 114
    $opt              i113, 114
    %getopt_cfg       i107, 113
    @cfg_args         i112, 114, 116, 116
  Package Getopt::Long
    $ignorecase       101
    &GetOptions       &124
  Package main
    $Options          123, 124, 141, 150, 165, 169
    %$Options         141, 150, 165, 169
    &check_read       &167
    @ARGV             121, 157, 157, 162, 166, 166
This shows that the parse_argv subroutine had four lexical variables of its own; it also accessed global identifiers from both the main package and from Getopt::Long. The numbers are the lines where that item was used: a leading i indicates that the item was first introduced at the following line number, and a leading & means a subroutine was called there. Dereferences are listed separately, which is why both $Options and %$Options are shown.

The B::Deparse is a pretty printer that can demystify Perl code and help you understand what transformations the optimizer has taken with your code. For example, this shows what defaults Perl uses for various constructs: 

% perl -MO=Deparse -ne 'for (1 .. 10) { print if -t }'
LINE: while (defined($_ = <ARGV>)) {
    foreach $_ (1 .. 10) {
        print $_ if -t STDIN;
    }
}
The -p switch adds parentheses so you can see Perl's idea of precedence: 
% perl -MO=Deparse,-p -e 'print $a ** 3 + sqrt(2) / 10 ** -2 ** $c'
print((($a ** 3) + (1.4142135623731 / (10 ** (-(2 ** $c))))));
You can use -q to see what primitives interpolated strings are compiled into: 
% perl -MO=Deparse,-q -e '"A $name and some @ARGV\n"'
'A ' . $name . ' and some ' . join($", @ARGV) . "\n";
And this shows how Perl really compiles a three-part for loop into a while loop: 
% perl -MO=Deparse -e 'for ($i=0;$i<10;$i++) { $x++ }'
$i = 0;
while ($i < 10) {
    ++$x;
}
continue {
    ++$i
}
You could even call B::Deparse on a Perl bytecode file produced by perlcc -b, and have it decompile that binary file for you. Perl opcodes may be a tough read, but when necessary it can be helpful.

Tools that should be integrated in IDE

There are half dozen of key components of any IDE each of which exist as high quality independent component that can be integrated (with weaker or stronger level of integration, depending on the capabilities of particular IDE) into your own framework.

Beautifiers and Prettyprinters

Perl has one good beautifier (perltidy). The problem with writing a good Perl beautifier is the complexity of lexical structure of the language with such elements as qw, qq, etc.

I wrote my own simple Perl pretty printer called neatperl for use with my custom OFM-based Perl IDE.

Perltidy is an OK choice as it is well debugged and has little chances to mangle your script:

Perltidy is a Perl script which indents and reformats Perl scripts to make them easier to read. If you write Perl scripts, or spend much time reading them, you will probably find it useful.

Here are a few examples of reformatted code snippets:

The formatting can be controlled with command line parameters. The default parameter settings approximately follow the suggestions in the Perl Style Guide.

Perltidy can also output html of both pod and source code. For example, the link below is an html version of the module Conf.pm from SpamAssassin.

Besides reformatting scripts, Perltidy can be a great help in tracking down errors with missing or extra braces, parentheses, and square brackets because it is very good at localizing errors.

Converters for HTML

Also Code2HTML can convert Perl source code to syntax highlighted HTML. Some Perl editors has this capability too.

Perl Lint

Perl has a very useful but almost unknown and very rarely used by developers lint module (you may need to install the B::lint module)

18.6. Code Development Tools

The O module has many interesting Modi Operandi beyond feeding the exasperatingly experimental code generators. By providing relatively painless access to the Perl compiler's output, this module makes it easy to build other tools that need to know everything about a Perl program.

The B::Lint module is named after lint(1), the C program verifier. It inspects programs for questionable constructs that often trip up beginners but don't normally trigger warnings. Call the module directly: 

% perl -MO=Lint,all myprog
Only a few checks are currently defined, such as using an array in an implicit scalar context, relying on default variables, and accessing another package's (nominally private) identifiers that start with _. See B::Lint(3) for details.

Deparse module

The B::Deparse is a pretty printer that can demystify Perl code and help you understand what transformations the optimizer has taken with your code. For example, this shows what defaults Perl uses for various constructs: 

% perl -MO=Deparse -ne 'for (1 .. 10) { print if -t }'
LINE: while (defined($_ = <ARGV>)) {
    foreach $_ (1 .. 10) {
        print $_ if -t STDIN;
    }
}
The -p switch adds parentheses so you can see Perl's idea of precedence: 
% perl -MO=Deparse,-p -e 'print $a ** 3 + sqrt(2) / 10 ** -2 ** $c'
print((($a ** 3) + (1.4142135623731 / (10 ** (-(2 ** $c))))));
You can use -q to see what primitives interpolated strings are compiled into: 
% perl -MO=Deparse,-q -e '"A $name and some @ARGV\n"'
'A ' . $name . ' and some ' . join($", @ARGV) . "\n";
And this shows how Perl really compiles a three-part for loop into a while loop: 
% perl -MO=Deparse -e 'for ($i=0;$i<10;$i++) { $x++ }'
$i = 0;
while ($i < 10) {
    ++$x;
}
continue {
    ++$i
}
You could even call B::Deparse on a Perl bytecode file produced by perlcc -b, and have it decompile that binary file for you. Serialized Perl opcodes may be a tad tough to read, but strong encryption they are not.

Perl::Critic

From PerlCritic - Wikipedia, the free encyclopedia

Perl::Critic is a static code analysis system for the Perl programming language. Perl::Critic is available as a source-code distribution on CPAN. It comes with a commandline tool, perlcritic, which can check Perl source code files and report on the code quality therein. Perl::Critic has an extensible architecture that allows the programmer to choose from many "policies" which enforce different Perl programming styles and tastes. The default policy is largely based on the recommendations in the book Perl Best Practices by Damian Conway.

Perl::Critic is based on the PPI parsing library. For safety, PPI does not execute any code while parsing, unlike the Perl compiler, so it is a close approximation of the real parser rather than an exact representation.

Some new alternatives include Perl::Lint and B::Lint.

Documentation viewer

Typically documentation now is viewed via web using web browser. So there is not real need in separate component here for viewing standard Perl documentation. You can view it via IE of Firefox or whatever browser you prefer.

Perl has another type of documentation that resembles somewhat "literary programming" paradigm. It is called POD. You can incorporate POD into your script text and extract it using POD viewer. So POD viewer here is the just regular viewer and it can added to OFM as such. With editor it is just a special macro.

Top Visited
 Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Dec 19, 2017] Perl IDE and Editor Poll, October 2009 - Which editor(s) or IDE(s) are you using for Perl development

Oct 01, 2009 | perlide.org

In October 2009 we ran a poll asking people Which editor(s) or IDE(s) are you using for Perl development? . The poll was promoted via the blog of Gabor Szabo which is syndicated in several Perl related sites such as the Iron Man Challenge , Perlshpere and Planet Perl . It was also promoted via Twitter , the Perl group in Reddit , the Perl Mongers group in LinkedIn and the Perl Community Adserver to get more people to cast their vote. Request was also sent to the Perl Monger group leaders. Some of them have forwarded the request to their respective groups.

The list of editors was taken from the Perl Development Tools page on Perlmonks and the "randomize answers" checkbox was clicked after filling in the data. No idea if that really randomized the answers. During the poll people could mark other editors and type in the name of and editor. Some of these editors were added to the list of possible answers during the poll. In addition there were people who typed in the name of the editor in the other field even though the name appeared on the list.

At the begining we set the poll to allow multiple choice with up to 3 answers per person but later on we noticed that at one of the updates it became multiple choice unlimited answers. Unfortunatelly the free polling system we used gave details only on the number of answers and not the number of people who answered.

The poll ran between 21-24 October 2009 for about 72 hours. There were 3,234 answers when it was closed.

The results are as follows.
Vim (or vi or gvim) 1097 34%
Emacs (or xemacs, with or without extensions) 430 13%
Ultra Edit (plain or Studio) 224 7%
Eclipse EPIC 210 6%
Other answer... 143 4%
Notepad++ 142 4%
Komodo IDE 128 4%
Komodo Edit 105 3%
TextMate 105 3%
Padre 101 3%
Kate 56 2%
Gedit 55 2%
TextPad 49 2%
nano 40 1%
SciTE 38 1%
Geany 36 1%
NEdit 27 1%
mcedit 26 1%
EditPlus 26 1%
BBEdit 25 1%
JEdit 23 1%
Joe 20 1%
Smultron 16 0%
TextWrangler 14 0%
PSPad 12 0%
Notepad2 12 0%
Open Perl IDE 10 0%
OptiPerl 9 0%
Pico 7 0%
Jed 6 0%
Kephra 6 0%
SlickEdit 6 0%
KDevelop 6 0%
Notepad 5 0%
Crimson 4 0%
Anjuta 3 0%
EngInSite-Perl 3 0%
KEdit 3 0%
Perl Express 2 0%
DzSoft Perl 2 0%
PerlWiz 1 0%
Far 1 0%
Perl Studio 0 0%
Perl Builder 0 0%
Editeur 0 0%
Perl Code Editor 0 0%
ED for Windows 0 0%
PerlEdit 0 0%
FTE 0 0%
visiPerl+ 0 0%
Prof. Notepad 0 0%
Perl Scripting Tool 0 0%

[Dec 19, 2017] Programming in Perl - Debugging

Mar 13, 2007 | cs.rpi.edu

On this page, I will post aides and tools that Perl provides which allow you to more efficently debug your Perl code. I will post updates as we cover material necessary for understanding the tools mentioned.

CGI::Dump
Dump is one of the functions exported in CGI.pm's :standard set. It's functionality is similar to that of Data::Dumper . Rather than pretty-printing a complex data structure, however, this module pretty-prints all of the parameters passed to your CGI script. That is to say that when called, it generates an HTML list of each parameter's name and value, so that you can see exactly what parameters were passed to your script. Don't forget that you must print the return value of this function - it doesn't do any printing on its own. 
use CGI qw/:standard/;
print Dump;
Benchmark
As you know by now, one of Perl's mottos is "There's More Than One Way To Do It" (TMTOWTDI ©). This is usually a Good Thing, but can occasionally lead to confusion. One of the most common forms of confusion that Perl's verstaility causes is wondering which of multiple ways one should use to get the job done most quickly.

Analyzing two or more chunks of code to see how they compare time-wise is known as "Benchmarking". Perl provides a standard module that will Benchmark your code for you. It is named, unsurprisingly, Benchmark . Benchmark provides several helpful subroutines, but the most common is called cmpthese() . This subroutine takes two arguments: The number of iterations to run each method, and a hashref containing the code blocks (subroutines) you want to compare, keyed by a label for each block. It will run each subroutine the number of times specified, and then print out statistics telling you how they compare.

For example, my solution to ICA5 contained three different ways of creating a two dimensional array. Which one of these ways is "best"? Let's have Benchmark tell us:

#!/usr/bin/perl
use strict;
use warnings;
use Benchmark 'cmpthese';

sub explicit {
    my @two_d = ([ ('x') x 10 ],
                 [ ('x') x 10 ],
                 [ ('x') x 10 ],
                 [ ('x') x 10 ],
                 [ ('x') x 10 ]);
}

sub new_per_loop {
    my @two_d;
    for (0..4){
        my @inner = ('x') x 10;
        push @two_d, \@inner;
    }
}

sub anon_ref_per_loop {
    my @two_d;
    for (0..4){
        push @two_d, [ ('x') x 10 ];
    }
}

sub nested {
    my @two_d;
    for my $i (0..4){
        for my $j (0..9){
            $two_d[$i][$j] = 'x';
        }
    }
}
cmpthese (10_000, {
                 'Explicit'           => \&explicit,
                 'New Array Per Loop' => \&new_per_loop,
                 'Anon. Ref Per Loop' => \&anon_ref_per_loop,
                 'Nested Loops'       => \&nested,
             }
      );
The above code will print out the following statistics (numbers may be slightly off, of course): 
Benchmark: timing 10000 iterations of Anon. Ref Per Loop, Explicit, Nested Loops, New Array Per Loop...
Anon. Ref Per Loop:  2 wallclock secs ( 1.53 usr +  0.00 sys =  1.53 CPU) @ 6535.95/s (n=10000)
Explicit:  1 wallclock secs ( 1.24 usr +  0.00 sys =  1.24 CPU) @ 8064.52/s (n=10000)
Nested Loops:  4 wallclock secs ( 4.01 usr +  0.00 sys =  4.01 CPU) @ 2493.77/s (n=10000)
New Array Per Loop:  2 wallclock secs ( 1.76 usr +  0.00 sys =  1.76 CPU) @ 5681.82/s (n=10000)
                     Rate Nested Loops New Array Per Loop Anon. Ref Per Loop Explicit
Nested Loops       2494/s           --               -56%               -62%     -69%
New Array Per Loop 5682/s         128%                 --               -13%     -30%
Anon. Ref Per Loop 6536/s         162%                15%                 --     -19%
Explicit           8065/s         223%                42%                23%       --

The benchmark first tells us how many iterations of which subroutines it's running. It then tells us how long each method took to run the given number of iterations. Finally, it prints out the statistics table, sorted from slowest to fastest. The Rate column tells us how many iterations each subroutine was able to perform per second. The remaining colums tells us how fast each method was in comparison to each of the other methods. (For example, 'Explicit' was 223% faster than 'Nested Loops', while 'New Array Per Loop' is 13% slower than 'Anon. Ref Per Loop'). From the above, we can see that 'Explicit' is by far the fastest of the four methods. It is, however, only 23% faster than 'Ref Per Loop', which requires far less typing and is much more easily maintainable (if your boss suddenly tells you he'd rather have the two-d array be 20x17, and each cell init'ed to 'X' rather than 'x', which of the two would you rather had been used?).

You can, of course, read more about this module, and see its other options, by reading: perldoc Benchmark

Command-line options
Perl provides several command-line options which make it possible to write very quick and very useful "one-liners". For more information on all the options available, refer to perldoc perlrun
-e
This option takes a string and evaluates the Perl code within. This is the primary means of executing a one-liner
perl -e'print qq{Hello World\n};'
(In windows, you may have to use double-quotes rather than single. Either way, it's probably better to use q// and qq// within your one liner, rather than remembering to escape the quotes).
-l
This option has two distinct effects that work in conjunction. First, it sets $\ (the output record terminator) to the current value of $/ (the input record separator). In effect, this means that every print statement will automatically have a newline appended. Secondly, it auto-chomps any input read via the <> operator, saving you the typing necessary to do it.
perl -le 'while (<>){ $_ .= q{testing};  print; }'
The above would automatically chomp $_, and then add the newline back on at the print statement, so that "testing" appears on the same line as the entered string.
-w
This is the standard way to enable warnings in your one liners. This saves you from having to type use warnings;
-M
This option auto- use s a given module.
perl -MData::Dumper -le'my @foo=(1..10); print Dumper(\@foo);'
-n
This disturbingly powerful option wraps your entire one-liner in a while (<>) { ... } loop. That is, your one-liner will be executed once for each line of each file specified on the command line, each time setting $_ to the current line and $. to current line number.
perl -ne 'print if /^\d/' foo.txt beta.txt
The above one-line of code would loop through foo.txt and beta.txt, printing out all the lines that start with a digit. ($_ is assigned via the implicit while (<>) loop, and both print and m// operate on $_ if an explict argument isn't given).
-p
This is essentially the same thing as -n , except that it places a continue { print; } block after the while (<>) { ... } loop in which your code is wrapped. This is useful for reading through a list of files, making some sort of modification, and printing the results.
perl -pe 's/Paul/John/' email.txt
Open the file email.txt, loop through each line, replacing any instance of "Paul" with "John", and print every line (modified or not) to STDOUT
-i
This one sometimes astounds people that such a thing is possible with so little typing. -i is used in conjunction with either -n or -p. It causes the files specified on the command line to be edited "in-place", meaning that while you're looping through the lines of the files, all print statements are directed back to the original files. (That goes for both explicit print s, as well as the print in the continue block added by -p.)
If you give -i a string, this string will be used to create a back-up copy of the original file. Like so:
perl -pi.bkp -e's/Paul/John/' email.txt msg.txt
The above opens email.txt, replaces each line's instance of "Paul" with "John", and prints the results back to email.txt. The original email.txt is saved as email.txt.bkp. The same is then done for msg.txt

Remember that any of the command-line options listed here can also be given at the end of the shebang in non-one-liners. (But please do not start using -w in your real programs - use warnings; is still preferred because of its lexical scope and configurability).

Data::Dumper
The standard Data::Dumper module is very useful for examining exactly what is contained in your data structure (be it hash, array, or object (when we come to them) ). When you use this module, it exports one function, named Dumper . This function takes a reference to a data structure and returns a nicely formatted description of what that structure contains. 
#!/usr/bin/env perl
use strict;
use warnings;
use Data::Dumper;

my @foo = (5..10);
#add one element to the end of the array
#do you see the error?
$foo[@foo+1] = 'last';

print Dumper(\@foo);

When run, this program shows you exactly what is inside @foo:

$VAR1 = [
          5,
          6,
          7,
          8,
          9,
          10,
          undef,
          'last'
        ];

(I know we haven't covered references yet. For now, just accept my assertion that you create a reference by prepending the variable name with a backslash...)

__DATA__ & <DATA>
Perl uses the __DATA__ marker as a pseudo-datafile. You can use this marker to write quick tests which would involve finding a file name, opening that file, and reading from that file. If you just want to test a piece of code that requires a file to be read (but don't want to test the actual file opening and reading), place the data that would be in the input file under the __DATA__ marker. You can then read from this pseudo-file using <DATA>, without bothering to open an actual file: 
#!/usr/bin/env perl
use strict;
use warnings;

while (my $line = <DATA>) {
  chomp $line;
  print "Size of line $.:  ", length $line, "\n";
}

__DATA__
hello world
42
abcde

The above program would print:

Size of line 1: 11
Size of line 2: 2
Size of line 3: 5
$.
The $. variable keeps track of the line numbers of the file currently being processed via a while (<$fh>) { ... } loop. More explicitly, it is the number of the last line read of the last file read.
__FILE__ & __LINE__
These are two special markers that return, respectively, the name of the file Perl is currently executing, and the Line number where it resides. These can be used in your own debugging statements, to remind yourself where your outputs were in the source code: 
  print "On line " . __LINE__ . " of file " . __FILE__ . ", \$foo = $foo\n";

Note that neither of these markers are variables, so they cannot be interpolated in a double-quoted string

warn() & die()
These are the most basic of all debugging techniques. warn() takes a list of strings, and prints them to STDERR. If the last element of the list does not end in a newline, warn() will also print the current filename and line number on which the warning occurred. Execution then proceeds as normal.

die() is identical to warn() , with one major exception - the program exits after printing the list of strings.

All debugging statements should make use of either warn() or die() rather than print() . This will insure you see your debugging output even if STDOUT has been redirected, and will give you the helpful clues of exactly where in your code the warning occurred.

[Dec 19, 2017] Open Perl IDE - User Manual

Dec 19, 2017 | open-perl-ide.sourceforge.net

This section explains how to use Open Perl IDE for debugging.

Important: Open Perl IDE is not able to debug any scripts, if it does not know a path to "perl.exe". If the PATH environment variable contains a valid location, then "perl.exe" will be detected automatically. Otherwise it is necessary to enter a valid location into the "Preferences | General | Directories | Path to perl.exe" field.

There are two methods to debug a script:

After execution is stopped, it is possible to analyse the actual state of the script by Furthermore, it is possible to set/delete breakpoints (see section 5.1 Breakpoints) or to continue/abort the execution of the script. The following table shows the different navigation possibilities:

Table: Debug Navigation

Name Shortcut Description
Run F9 Start/Continue script execution until next breakpoint is reached.
Step Over F8 Execute the current script line, not tracing into subroutines.
Step Into F7 Execute the next command in the current script line, tracing into subroutines.
Abort CTRL-F2 Request termination of debug session.
Force Termination CTRL-ALT-F12 Immediately terminate debug session.
You should only use "Force Termination" if you see no other way to stop script execution. Dont't expect Open Perl IDE to work correctly after using forced termination !

If script execution has finished, then Open Perl IDE automatically switches back from debug mode to edit mode.

EPIC - Eclipse Perl Integration

EPIC is an open source Perl IDE (including editor and debugger) based on the Eclipse platform, compatible with Windows, Linux and Mac OS X. Whether you are into CGI scripting or full-fledged Perl projects with hundreds of modules, EPIC is the most feature-rich and extensible free Perl IDE available today, thanks to a seamless integration with all the major features and GUI conventions of Eclipse.

Syntax highlighting
Configurable coloring of syntactic elements
On-the-fly syntax check
Syntax errors detected and explained as you type or upon saving a file
Content assist
Autocompletion for subroutine and variable names
Quick reference feature
Documentation tooltips for built-in Perl functions
Outline view
Displays used modules and subroutines contained in the edited file
Source formatter
Integrated perltidy and HTML export feature
Perldoc support
Integrated perldoc for quick acccess to documentation
Templating support
Create a library of code snippets to save typing
Persistent breakpoints
Breakpoints stay set between IDE restarts
Single Step/Step Into/Step Over
Tried and true execution control features
Global and local variables inspection
Displays contents of variables (PadWalker module required)
Expression evaluation
Execute user-defined expressions while debugger is paused
RegExp Plug-in
Multiline/ignorecase support

Subexpression highlighting

Single step for debugging

Perl::Critic integration
Helps keep your coding style nice and tidy
...and more!

Open Perl IDE download

Abandonware

SourceForge.net

Open Perl IDE is a visual, integrated development environment for writing and debugging Perl scripts with any standard Perl distribution under Windows 95/98/NT/2000.

Open Perl IDE Web Site

Open Perl IDE is an integrated development environment for writing and debugging Perl scripts with any standard perl distribution under Windows 95/98/NT/2000.

This software is written in Delphi 5 Object Pascal and Perl and it is OpenSource, distributed under Mozilla Public Licence 1.1 and hosted by SourceForge. Please visit our project page to get further information.

Now, take a look at some screenshots, read the User Manual to get a more detailed description of Open Perl IDE or download the latest release (Version 1.0).

The new release 1.0 is the first non-beta version of Open Perl IDE and fixes most of the bugs reported for previous releases. However, some of the changes are much more than simple bugfixes:

  • Better syntax coloring by using a new highlighter component.

  • Important debugger improvements, including better support for huge arrays.

  • Previous instance detection on program start.

  • Several minor HelpViewer and Configuration enhancements.


For any information, questions, remarks or bug reports, please send a message to Jürgen Güntherodt.

[Jul 16, 2012] What's the best Perl IDE

This discussion contain a lot of interesting tidbits. They are slightly outdated (written in 2007)
Sep 17, 2007 | PerlMonks

I wish vi fanbois and emacs die-hards stopped recommending them as Perl IDEs. They are editors, as much as you love them. They don't have debuggers, stack tracers, variable watching, breakpoints, regexp builders, or anything that makes up a real Perl IDE.

That said, Perl IDEs are listed at perlide.org.

There are two serious paid Perl IDEs:

The two serious free Perl IDEs are Padre and Eclipse + the EPIC plugin.

I compared Komodo vs. Eclipse and stuck with Komodo because of its remote debugging capabilities.

Padre is still immature but the good part is that you can improve it, since it's written in Perl, unlike EPIC (written in Java).

[Jan 19, 2011] The Perltidy Home Page

Perltidy is a Perl script which indents and reformats Perl scripts to make them easier to read. If you write Perl scripts, or spend much time reading them, you will probably find it useful.

Here are a few examples of reformatted code snippets:

The formatting can be controlled with command line parameters. The default parameter settings approximately follow the suggestions in the Perl Style Guide.

Perltidy can also output html of both pod and source code. For example, the link below is an html version of the module Conf.pm from SpamAssassin.

Besides reformatting scripts, Perltidy can be a great help in tracking down errors with missing or extra braces, parentheses, and square brackets because it is very good at localizing errors.

prettyprinter.de

This is a Web-based source code beautifier (source code formatter), similiar to indent. Please make a backup before you replace your code!

[Jan 19, 2011] pb

#!/usr/bin/perl

# 'pb' Perl Beautifier

# Written by P. Lutus Ashland, Oregon [email protected] 5/20/96

# This script processes Perl scripts, cleans up and indents, like cb does for C

# Be careful with this script - it accepts wildcards and processes every text file
# that meets the wildcard criteria. This could be a catastrophe in the hands of the unwary.

$tabstring = "  "; # You may place any tab-stop characters you want here

if($ARGV[0] eq "") {
  print "usage: file1 file2 etc. or wildcards (replaces originals in place)\n";
}
else {
  foreach $filename (@ARGV) {
    if(-T $filename) {
      &process($filename);
    }
  }
}

sub process {
  $fn = $_[0];
  undef $/; # so we can grab the entire file at once
  undef @infa; # prevent left-overs
  print STDERR "$fn";
  open (INFILE,$fn);
  @infa = split(/\n/,<INFILE>);
  close INFILE;
  
  $/ = "\n"; # restore default
  
  open (OUTFILE,">$fn");
  $tabtotal = 0;
  for (@infa) {
    
    s/^\s*(.*?)\s*$/$1/; # strip leading and trailing spaces
    
    $a = $_; # copy original string
    $q = $a; # i plan to modify this copy for testing
    $q =~ s/\\\#//g; # remove escaped comment tokens
    $q =~ s/\#.*?$//g; # remove Perl-style comments
    $q =~ s{/\*.*?\*/} []gsx; # remove C-style comments
    $q =~ s/\\\{//g; # remove escaped left  braces
    $q =~ s/\\\}//g; # remove escaped right braces
    $q =~ s/\\\(//g; # remove escaped left  parentheses
    $q =~ s/\\\)//g; # remove escaped right parentheses
    
    $q =~ s/\'.*?\'//g; # remove single-quoted lines
    
# now the remaining braces/parentheses should be structural
    
    $delta = -($q =~ s/\}/\}/g); # subtract closing braces
    $delta += ($q =~ s/\{/\{/g); # add opening braces
    
    $delta -= ($q =~ s/\)/\)/g); # subtract closing parens
    $delta += ($q =~ s/\(/\(/g); # add opening parens
    
    $tabtotal += ($delta < 0)?$delta:0; # subtract closing braces/parentheses
    
    $i = ($tabtotal > 0)?$tabtotal:0; # create tab index
    
    $tabtotal += ($delta>0)?$delta:0; # add opening braces/parentheses for next print
    
    if(substr($a,0,1) ne "#") { # don't tab comments
      print OUTFILE $tabstring x $i; # "tab" out to position
    }
    
    print OUTFILE "$a\n"; # print original line
  } # -- for (@infa)
  
  close OUTFILE;
  
  if($tabtotal != 0) {
    print STDERR " Indentation error: $tabtotal\n";
  }
  else {
    print STDERR "\n";
  }
} # sub process

Beautifier freshmeat.net

Beautifier (previously known as PSH, the PHP Syntax Highlighter) highlights and indents source code using highlight configuration files which are similar to Ultraedit highlighting files. It supports C, C#, Java, Perl, PHP, Pascal, Lisp, Mumps, Eiffel, Euphoria, and x86 Assembler, amongst others. It handles line/block comments, keyword highlighting, correct indentation, string highlighting, language contexts (allowing embedded languages), and selection highlighting. It is available in PHP and Perl versions.

Scintilla and SciTE

SciTE is a SCIntilla based Text Editor. Originally built to demonstrate Scintilla, it has grown to be a generally useful editor with facilities for building and running programs. It is best used for jobs with simple configurations - I use it for building test and demonstration programs as well as SciTE and Scintilla, themselves.

SciTE is currently available for Intel Win32 and Linux compatible operating syshttp://www.scintilla.org/SciTEImage.html">Here is a screenshot of SciTE.

On Windows, there is a companion application Filerx which provides project management and macro features to SciTE.

You can download Scintilla and SciTE.

There are some extra configuration files that can enhance SciTE for various languages and APIs.

The scite-interest mailing list has moved from lyra.org to Google Groups. Questions and comments about SciTE should be directed to the scite-interest mailing list, which is for discussion of SciTE and related projects, their bugs and future features. This is a low traffic list, averaging less than 50 messages per week. To avoid spam, only list members can write to the list. New versions of SciTE are announced on scite-interest and may also be received by SourceForge members by clicking on the Monitor column icon for "scite" on the downloads page. Messages sent to my personal email address that could have been sent to the list may receive no response.
There is a Scintilla project page

Wat's the best free Perl IDE?

why don't you try Eclipse with Epic (an eclipse perl plug in) ;)

Check out Padre, http://padre.perlide.org/

Ulrich Habel wroteon June 17, 2009 at 5:05pm

Personally I like SciTE which is more an editor which is customizable. You can have your own menu entries which might use tools or even Perl scripts in the background. It's very small and very fast.

In order to fulfill the request for the IDE I would suggest looking into Padre. It has some great features like lexical replacement with refactoring, it reads your code and assists you. You'll end up installing full CPAN if you build it on your own.

Padre Perl Application Development and Refactoring Environment

Homepage of Crimson Editor - Free Text Editor, Html Editor, Programmers Editor for Windows

Syntax Highlighting for HTML, C/C++, Perl, Java, Matlab and LaTeX. Also, it can be extended for other programming languages based on custom syntax files.

Perl Code Editor A superior notepad editor for Windows with syntax coloring and line numbers

A Perl code editor for Windows. Allows Perl programmers to develop and edit scripts with a more advanced editor compared to the standard notepad that comes with Windows. Features include: Syntax Coloring, Bookmarks, Auto Indenting, Line Ending Conversion (Unix to Windows), Drag and Drop Support, Goto Line by Line Number, and Handles .pl and .cgi files. Also includes a context/right click menu for fast access to the most commonly used features.

SannySoft Perl Editor

Perl Editor 2005 is a feature-packed Integrated Development Environment for Perl programmers. Why do Perl coders need it? Here is an analogy - you probably have both Notepad and MS Word on your PC. Both are text-editors or word processors. Which tool do you think professional writers prefer?

... Since the program was created by an experienced team of Perl programmers, Perl Editor has every feature Perl coder could possible need and does not have any extraneous options that would make the program complicated, hard to learn or difficult to use.
http://www.perleditor.net/download/SannySoftPerlEditor.zip - 3Mb - Download - Screenshot

DzSoft Perl Editor

DzSoft Perl Editor is a tool for writing, editing, and debugging Perl/CGI scripts. It has a comfortable and intuitive interface both for beginners and advanced programmers. DzSoft Perl Editor is deceptively simple, but it is really a very powerful tool. ... With DzSoft Perl Editor you can run a script and see the result immediately in just one click (you dont even have to run a web server to test a CGI script in the browser)! ... Features Code Explorer, very comfortable editor with syntax highlighting, syntax check, easy debugging of command line and CGI scripts with breakpoints and...
http://www.dzsoft.com/download/dzperl57.exe - 2Mb - Download - Screenshot

Top Perl Studio

Top Perl Studio is an Integrated Development Environment for Perl, providing comprehensive and easy-to-use solution for editing, testing and deploying CGI/Perl based web applications. Top Perl Studio includes a built-in HTTP server which directly runs CGI/Perl code and an internal web browser... Top Perl Studio's powerful code editor supports configurable syntax highlighting for Perl, HTML, XML, SQL... ... Other major features are: built-in FTP client, file/server explorer, syntax checking for Perl code, visual file comparison utility, code snippets for CSS and HTML tags, automatic...
http://www.top-systems.net/Top-Perl-Studio/tperlstudio-trial-en.zip - 2Mb - Download - Screenshot

Perl Express

Abandonware

A free integrated development environment (IDE) for Perl with multiple tools for writing and debugging your scripts. It features multiple CGI scripts for editing, running, and debugging; multiple input files; full server simulation; queries created from an internal Web browser or query editor;... It has a customizable code editor with syntax highlighting, unlimited text size, printing, line numbering, bookmarks, column selection, a search-and-replace engine, multilevel undo/redo operations, and so on.
http://www.perl-express.com/PeSetup25.exe - 3Mb - Download - Screenshot

Perl Builder

Perl Builder is a complete integrated development environment (IDE) for Perl. Key features include a visual editor/debugger that is similar to products such as Visual Basic and Delphi. The CGI Wizard component lets both novices and experienced programmers create powerful scripts visually,... The Perl Builder IDE includes all the features you expect in a professional development tool, including color syntax highlighting, automatic indentation, a full-featured debugger with mouseover variable inspection, single step, watches, and data structure dump.

[Mar 25, 2006] DZsoft Perl Editor Version 5.7.0.7. Shareware $49.

DzSoft Perl Editor has debugging features, a very comfortable editor with syntax highlighting, a syntax check feature that finds errors in your script, and many other features for easy and comfortable Perl development.

[Aug 25, 2005] Perl.com Perl Needs Better Tools By Matisse Enzer

Perl is in danger of becoming a fading language--new programmers are learning Java and Python in college, and companies like Google hardly use Perl at all. If you are afraid that Perl may be in danger of becoming irrelevant for medium-to-large projects, then read on.

The Scary Part

I have discussed the future of Perl with managers from companies that currently use it and find that they worry about the future of Perl. One company I spoke with here in San Francisco is rewriting their core application in Java. Another company worries they will not be able to find new Perl programmers down the road. Yet another uses Perl for major projects, but suffers from difficulty in refactoring their extensive code base.

There are many reasons why companies care about the future of Perl. I offer a part of a solution: better tools for Perl can be a major part of keeping Perl relevant and effective as the primary language for medium and large projects.

Related Reading

Perl Best Practices
By Damian Conway

Table of Contents
Index
 Sample Chapter

When measuring the effectiveness of a development environment (people, language, tools, processes, etc.), a key measure is how expensive and painful it is to make changes to existing code. Once a project or system has grown to thousands of lines of code in dozens (or hundreds) of modules, the cost of making changes can escalate to the point where the team is afraid to make any significant change. Excellent tools are one of the ways to avoid this unhappy situation, or at least reduce its impact. Other factors are excellent processes and, of course, excellent people.

21st-Century Integrated Development Environments for Perl

I propose that more, high-quality development tools will help keep Perl relevant and alive in medium and large project environments. My focus in this article is on IDEs, or Integrated Development Environments, and primarily those with a graphical interface.

An IDE is an integrated set of tools for programming, combining a source code editor with a variety of other tools into a single package. Common features of modern IDEs include refactoring support, version control, real-time syntax checking, and auto-completion of code while typing.

I want to make it clear right at the outset that a team of highly skilled Perl programmers, using only tools that have been around for years (such as emacs, vi, cvs, and make) can and do build large, sophisticated, and successful projects. I am not worried about those programmers. I am worried about the larger population of programmers with one to five years of experience, and those who have not yet begun to program: the next generation of Perl programmers.

Great tools will not make a bad programmer into a good programmer, but they will certainly make a good programmer better. Unfortunately, the tools for Perl are years behind what is available for other languages, particularly Java.

One powerful example is the lack of graphical IDEs for Perl with excellent support for refactoring. Several IDEs for Java have extensive refactoring support. Only one for Perl, the EPIC plugin for Eclipse, supports even a single refactoring action.

For an example of how good IDEs have inspired at least one Perl developer, see Adam Kennedy's Perl.com article on his new PPI module and Scott Sotka's Devel::Refactor module (used in EPIC).

I acknowledge that a graphical IDE is not the be-all of good tools. Just as some writers reject word processors in favor of typewriters or hand-written manuscripts, some programmers reject graphical IDEs and would refuse a job that required them to use one. Not everyone has (nor should have) the same tool set, and there are things a pencil can do that vi and emacs will never do. That said, IDEs have wide use in businesses doing larger projects, and for many programmers and teams they provide major increases in productivity.

Another important point is that while this article discusses over a dozen specific tools or features, having all the tools in a single package produces the biggest value. An IDE that provides all of these features in a single package that people can easily install, easily extend, and easily maintain across an entire development team has far more value than the sum of its parts.

There is a big win when the features provided by an IDE immediately upon installation include all or almost all of the tools and features discussed here and where the features "know" about each other. For example, it is good if you enter the name of a non-existent subroutine and the real-time syntax checker catches this. It is much better if the code-assist feature then pops up a context menu offering to create a stub for the subroutine or to correct the name to that of an existing similar subroutine or method from another class that is available to the current file. (This is standard behavior for some Java IDEs.)

What Would a 21st-Century Perl Tool Set Contain?

Perl needs a few great IDEs--not just one, but more than one so that people have a diverse set to choose from. Perl deserves and needs a few great IDEs that lead the pack and set the standard for IDEs in other languages.

I am well aware that the dynamic nature of Perl makes it harder to have a program that can read and understand a Perl program, especially a large and complex one, but the difficulty in comprehending a Perl program makes the value of such a tool all the greater, and I have faith that the Perl community can overcome some of the built-in challenges of Perl. Indeed, it is among the greatest strengths of Perl that Perl users can adapt the language to their needs.

A great Perl IDE will contain at least the following, plus other features I haven't thought of. (And, of course, there must be many of those!)

Most of the screen shot examples in this article use the EPIC Perl IDE. At present, it has the largest amount of the features on my list (although it certainly doesn't have all of them).

Syntax-Coloring Text Editor

Most of you have probably seen this. It is available under vim, emacs, BBEdit, and TextPad. Just about every decent text editor will colorize source code so that keywords, operators, variables, etc., each have their own color, making it easier to spot syntax errors such as forgetting to close a quote pair.

Real-Time Syntax Checking

real-time syntax check example
Figure 1. Real-time syntax checking

The IDE in Figure 1 shows that line 4 has an error because of the missing ) and that line 5 has an error because there is no declaration of $naame (and use strict is in effect).

A key point here is that the IDE shows these errors right away, before you save and compile the code. (In this example, the EPIC IDE lets you specify how often to run the syntax check, from 0.01 to 10.00 seconds of idle time, or only on demand.)

As nice as this is, it would be even better if the IDE also offered ways to fix the problem, for example, offering to change $naame to $name. Figure 2 shows an IDE that does exactly that; unfortunately, for Java, not Perl.

syntax help from the IDE
Figure 2. Syntax help from the IDE

It would be great if Perl IDEs offered this kind of help.

Version Control Integration

All non-insane large projects use version control software. The most common version control software systems are probably CVS, Perforce, Subversion, and Visual SourceSafe. Figure 3 shows an IDE comparing the local version of a file to an older version from the CVS repository.

Figure 3
Figure 3. Comparing a local file to an older version in CVS--click image for full-size screen shot

CVS integration is available in many modern code editors, including emacs, vim, and BBEdit, as well as graphical IDEs such as Eclipse and Komodo Pro. Subversion integration is available as a plugin for Eclipse; Komodo Pro supports Perforce and Subversion.

A Code-Assist Editor

Suppose that you have just typed in an object reference and want to call a method on the object, but you are not sure what the method name is. Wouldn't it be nice if the editor popped up a menu listing all of the methods available for that object? It might look something like Figure 4.

automatic code completion
Figure 4. Automatic code completion

In this example, the IDE is able to figure out which class the object $q is an instance of and lists the names of the available methods. If you type a p, then the list shows only the method names beginning with p. If you type pa, then the list shows only the param() and parse_params() methods.

Excellent Refactoring Support

The easier it is to do refactoring, the more often people will do it. The following list contains the most common refactorings. Your personal list will probably be a little different. All of these are things you can do "manually," but the idea is to make them into one or two-click operations so that you will do them much more often. (For a extensive list of refactoring operations, see Martin Fowler's alphabetical list of refactorings.)

Extract Subroutine/Method

The IDE should create a new subroutine using the selected code and replace the selected code with a call to the new subroutine, with the proper parameters. Here's an example of using the Extract Subroutine refactoring from Eclipse/EPIC (which uses the Devel::Refactor module).

First, you select a chunk of code to turn into a new subroutine, and then select Extract Subroutine from a context menu. You then get the a dialog box asking for the name of the new subroutine (shown in Figure 5).

code before Extract Subroutine refactoring
Figure 5. Code before Extract Subroutine refactoring

The IDE replaces the selected code with a call to the new subroutine, making reasonable guesses about the parameters and return values (Figure 6). You may need to clean up the result manually.

code after Extract Subroutine refactoring
Figure 6. Code after Extract Subroutine

Figure 7 shows the new subroutine created by the IDE. In this case, it needs no changes, but sometimes you will need to adjust the parameters and/or return value(s).

the new subroutine created by Extract Subroutine
Figure 7. The new subroutine created by Extract Subroutine

Ideally, the editor should prompt you to replace similar chunks of code with calls to the new subroutine.

Rename Subroutine/Method

The IDE should find all the calls to the subroutine throughout your project and offer to change them for you. You should be able to see a preview of all of the places a change could occur, and to accept or reject each one on a case-by-case basis. The action should be undoable.

Rename Variable

Like Rename Subroutine, this feature should find all occurrences throughout the project and offer to make the changes for you.

Change Subroutine/Method Signature

The IDE should be able to make reasonable guesses about whether each subroutine or method call is supplying the proper parameters. Partly this is to enable the real-time syntax checking mentioned above, and partly this is to enable you to select a subroutine declaration and tell the IDE you want to refactor it by adding or removing a parameter. The IDE should then prompt you for the change(s) you want to make, do its best to find all of the existing calls to the subroutine, and offer to correct the subroutine calls to supply the new parameters.

Obviously, this is an especially tricky thing to do in Perl, where subroutines fish their parameters out of @_. So the IDE would have to look carefully at how the code uses shift, @_, and $_[] in order to have a reasonable guess about the parameters the subroutine is expecting. In many common cases, though, a Perl IDE could make a reasonable guess about the parameters, such as in the following two examples, so that if you added or removed one, it could immediately prompt you about making corrections throughout the project:

sub doSomething {
    my $gender = shift;
    my $age    = shift;
    # Not too terribly hard to guess that $gender and $age are params
}

sub anotherThing {
    my ($speed,$direction) = @_;
    # No magic needed to guess $speed and $direction are params.
}
Move Subroutine/Method

This refactoring operation should give you a list or dialog box to choose the destination file in your project. The IDE should allow you to preview all of the changes that it would make to accomplish the move, which will include updating a call to the subroutine/method to use the proper class. At a minimum, the IDE should show you or list all of the calls to the subroutine so you can make the appropriate changes yourself. Ideally, the IDE should make a guess about possible destinations; for example, if $self is a parameter to the method being moved, then the IDE might try assuming the method is an object (instance) method and initially only list destination classes that inherit from the source class, or from which the source class inherits.

Change a Package Name

As with Rename Subroutine and Rename Variable, when changing a package name, the IDE should offer to update all existing references throughout your project.

[Jan 2, 2005] ExecPerl - Utilities for executing perl scripts vim online

Provides the following commands:

:ExecPerl script_name
This will execute script_name using the perl
interpreter.

:ExecPerlMore
This will execute script_name using the perl
interpreter. If the output would scroll past the end
of the screen, execution pauses and waits for a
keystroke before continuing.

:ExecPerlDump
This will ask you for an output file and then
execute script_name using the perl interpreter. The
output from the script is dumped to the file that you
entered when you were prompted. You may press enter
instead of entering a file name to accept the default
filename.

Also, The following keys are mapped by default. You'll have to
comment them if you don't want this behavior:

<F5>: ExecPerl the current file being edited
<C-F5>: ExecPerlMore the current file being edited
<S-F5>: ExecPerlDump the current file being edited

[Jan 2, 2005] perl_synwrite.vim - checks Perl syntax before allowing file write vim online

This plugin causes write attempts to fail if the contents of the buffer produce an error when run through "perl -c"

The plugin uses can use autocommands for the BufWriteCmd and FileWriteCmd events, but by default only provides a :Write command to check-then-write.
install details
Put this file in one of the locations described in :help ftplugin such as "~/.vim/after/ftplugin"; if you want autocommands, which are quirky, define perl_synwrite_au = 1

[Jan 2, 2005] perl.vim - Perl compiler script vim online

This is compiler script that runs perl -Wc and parses all error and warnings. For more information how to use compilers in VIM read help.

This version has workaround with redirecting stderr on windows platform so it can run either on unixes or windows.

Enjoy. Lukas
install details
Just put in the $VIMRUNTIME/compiler directory and run :make.

[Dec 26, 2004] http://ppt.perl.org/ Do you know about the Perl Power Tools, at and mirrored various other places?

It is a great project to implement versions of standard Unix tools in pure Perl, so that they can run anywhere Perl does. Those utilities might be perfect for those who like me I prefer Unix/Linux as the development platforms, but Windows for my desktop. They also might be an alternative to the Cygwin stuff even for those who do not use Perl for own scripting. They should be the alternative for those who does use Perl. Once Perl has been installed the PPT stuff only needs to be copied somewhere and that directory added to the PATH. You can also learn some great Perl coding tricks by reading the PPT utilities. Thanks for the anonymous feedback to the Softpanorama for this info.

perl.com Perl Command-Line Options

Perl has a large number of command-line options that can help to make your programs more concise and open up many new possibilities for one-off command-line scripts using Perl. In this article we'll look at some of the most useful of these.

Which Open Source Wiki Works For You

ONLamp.com

Kwiki

The Kwiki motto is a "A Quickie Wiki that's not Tricky." Installing it is pretty straightforward for a site you admin: just install the Perl package (from CPAN or elsewhere), and then type kwiki-install in a CGI-served directory to create an instance. Installing Kwiki on a server you are not an admin of is more complicated but doable.

I found the Kwiki markup not powerful. Some things are impossible with it, such as hyperlinking an arbitrary piece of text to an email address (mail fooish). I also could not find how to link a Wiki page with a text link different from the Wiki page name (like this link to LinkedWikiWikiPage). There is also no support for attachments, HTML markup as an alternative to the Wiki markup, etc. It is disappointing.

Kwiki can use either RCS or Subversion for version control. (Those who wish to use Subversion should check out the corrected Kwiki version as the CPAN Kwiki does not work with the up-to-date Subversion.) Kwiki is easily customizable and has several Kwiki enhancements available. Generally, however, they are less powerful than TWiki's.

All in all, Kwiki is easy to install and customize, but its formatting rules are lacking.

... ... ...

UseModWiki

UseModWiki is a Wiki engine written in Perl. Anecdotally, Wikipedia used this first before re-implementing their current engine. Other sites also use UseModWiki.

UseModWiki is very simple to set up and upgrade. It has a rich syntax, and allows for arbitrary characters in page names. It also supports using some HTML tags instead of the WikiWiki markup. It has other nice features, including search, a list of recent changes, and page history.

For simple Wikis, UseModWiki is a very good choice. I recommend choosing between it and PmWiki based on the feature list of both Wikis.

Recommended Links

Perl Development Tools

What's the best Perl IDE

Xref Tools

The B::Xref module generates cross-reference listings of the declaration and use of all variables (both global and lexically scoped), subroutines, and formats in a program, broken down by file and subroutine. Call the module this way: 

% perl -MO=Xref myprog > myprof.pxref

For instance, here's a partial report: 

Subroutine parse_argv
  Package (lexical)
    $on               i113, 114
    $opt              i113, 114
    %getopt_cfg       i107, 113
    @cfg_args         i112, 114, 116, 116
  Package Getopt::Long
    $ignorecase       101
    &GetOptions       &124
  Package main
    $Options          123, 124, 141, 150, 165, 169
    %$Options         141, 150, 165, 169
    &check_read       &167
    @ARGV             121, 157, 157, 162, 166, 166

This shows that the parse_argv subroutine had four lexical variables of its own; it also accessed global identifiers from both the main package and from Getopt::Long. The numbers are the lines where that item was used: a leading i indicates that the item was first introduced at the following line number, and a leading & means a subroutine was called there. Dereferences are listed separately, which is why both $Options and %$Options are shown.

[Jul 1, 2005] Perl 5.8 Documentation - BXref - Generates cross reference reports for Perl programs

The B::Xref module is used to generate a cross reference listing of all definitions and uses of variables, subroutines and formats in a Perl program. It is implemented as a backend for the Perl compiler.

The report generated is in the following format: 

    File filename1
      Subroutine subname1
	Package package1
	  object1        line numbers
	  object2        line numbers
	  ...
	Package package2
	...

Each File section reports on a single file. Each Subroutine section reports on a single subroutine apart from the special cases "(definitions)" and "(main)". These report, respectively, on subroutine definitions found by the initial symbol table walk and on the main part of the program or module external to all subroutines.

The report is then grouped by the Package of each variable, subroutine or format with the special case "(lexicals)" meaning lexical variables. Each object name (implicitly qualified by its containing Package) includes its type character(s) at the beginning where possible. Lexical variables are easier to track and even included dereferencing information where possible.

The line numbers are a comma separated list of line numbers (some preceded by code letters) where that object is used in some way. Simple uses aren't preceded by a code letter. Introductions (such as where a lexical is first defined with my) are indicated with the letter "i". Subroutine and method calls are indicated by the character "&". Subroutine definitions are indicated by "s" and format definitions by "f".

Option words are separated by commas (not whitespace) and follow the usual conventions of compiler backend options.

-oFILENAME
Directs output to FILENAME instead of standard output.
-r
Raw output. Instead of producing a human-readable report, outputs a line in machine-readable form for each definition/use of a variable/sub/format.
-d
Don't output the "(definitions)" sections.
-D[tO]
(Internal) debug options, probably only useful if -r included. The t option prints the objl&

HTML converters

GNU Source-highlight - GNU Project - Free Software Foundation (FSF) v1.6 by Lorenzo Bettini

This program, given a source file, produces a document with syntax highlighting.

At the moment this package can handle

as source languages, and

as output format.

NOTICE: now the name of the program is source-highlight: there are no two separate programs, namely java2html and cpp2html, anymore. However there are two shell scripts with the same name in order to facilitate the migration (however their use is not advised).

GNU Source-highlight is free software. Please see the file COPYING for details. For documentation, please read this file.

GNU Source-highlight is a GNU program and its main home page is at GNU site:
http://www.gnu.org/software/src-highlite/source-highlight.html

You can download it from GNU's ftp site:
ftp://ftp.gnu.org/gnu/source-highlight/ or from one of its mirrors (see http://www.gnu.org/prep/ftp.html).

I do not distribute Windows binaries anymore; since, they can be easily built by using Cygnus C/C++ compiler, available at http://www.cygwin.com/. However, if you don't feel like downloading such compiler, you can request such binaries directly to me, by e-mail ([email protected]) and I can send them to you.
An MS-Windows port of Source-highlight is available from http://gnuwin32.sourceforge.net/.

You may also want to check the md5sum of the archives, which are also digitally signed by me (Lorenzo Bettini) with GNU gpg (http://www.gnupg.org). My GPG public key can be found at my home page (see at the end of this doc).

You can also get the patches, if they are available for a particular release (see below for patching from a previous version).

code2html

code2html by Peter Palfrader (Weasel) is a perlscript which converts a program source code to syntax highlighted HTML. It may be called from the command line or as a CGI script. It can also handle include commands in HTML files. Currently supports: Ada 95, C, C++, HTML, Java, JavaScript, Makefile, Pascal, Perl, SQL, AWK, M4, and Groff.

Homepage: http://www.palfrader.org/code2html

Freshmeat page: http://freshmeat.net/projects/code2html/

code2html is a perlscript which converts a program source code to syntax highlighted HTML. It may be called from the command line or as a CGI script. It can also handle include commands in HTML files. It really should be rewitten eventually since the code is so ugly.

License: MIT

This project has the following developers:

Download: http://www.giga.or.at/~weasel/pub/code2html/latest/ (1637 hits)
Alternate Download: http://www.cosy.sbg.ac.at/~ppalfrad/code2html/code2html.pl.gz (193 hits)
Homepage: http://www.cosy.sbg.ac.at/~ppalfrad/code2html/ (2653 hits)
Changelog: http://www.cosy.sbg.ac.at/~ppalfrad/code2html/history.html (97 hits)

Editors

VIM has (limited) support of Perl. See Softpanorama VI Editor Links

***** DzSoft Perl Editor 3.1 Very decent shareware editor with elements of Integrated environment. Contains built-in beautifier ! by Sergey Dzyubenko, Alexander Dzyubenko, DzSoft Ltd.

Perl Scripting Tool PRO Perl Made Easy Win32 editor.

NOTE: This is beta software. If you are not entirely comfortable using beta software, DO NOT install this version on your PC. We strongly recommend that BEFORE you install this software, you make a backup copy of your existing PST folder and put that copy in a separate area. Do not be alarmed if there is a big jump in beta build numbers; gaps exists because we create frequent internal builds. This is one of a series of beta releases of Perl Scripting Tool 2.00. As with any beta software, some features may not be fully implemented. If you find any problems with this software, please send us a bug report to: [email protected] .

Perl Editors

ped A text editor with an emacs/vi-like user interface written in perl.[July 17, 1999]
Jul 08th 1999, 21:24 stable: none - devel: 0.1.2 license: Artistic

TkFileman Home Page

Perl::Tk

ptkpad.0.6.5.tar.gz
This is an implementation of my Tk NotePad only it is done in Perl::Tk. The implementation is progressing quite fast and most of the features have been implemented. Currently the only features that have not been implemented are some keystroke bindings.
Unfortunately there are a few bugs and is considered a beta release now, so please do not complain about bugs> I will welcome bug fixes. It originaly started out as a line by line conversion, but as I learn more about perl I am starting to optimize as well but this is a low priority.
Some features that have been added in addition to what is in my original TkNotePad are the New Window Menu item, as well as a line and column indicator to tell the position of the cursor, and a goto line. I have also added an Options menu for changing a few things like the fonts. Many more features are planned. screenshot

PurePerl.org

EDITOR COST REVIEWS From PBML Posters
Perl Code Editor
from PerlVision		 Free After Wordpad, this was my first Perl editor. Syntax highlighting and line numbering is definitely a step up.
Favorite feature: line numbering.
Submitted by: Bompa
[read more reviews]
Open Perl IDE
by Jürgen Güntherodt		 Free A big step up, yet still light on your cpu. This is the one I use now because it's free and runs nicely even on my 122Mhz laptop.
Favorite feature: A "run" button that runs the script and shows errors in a box at the bottom of the screen, this saves a bunch of testing time.
Submitted by: Bompa
UltraEdit
IDM Computer Solutions, Inc		 $35 Full featured, tons of options, settings, and features.
Favorite feature: being able to "'comment out" whatever code I highlight with just one click, (and the reverse), great for troubleshooting. I loved it and might still cough up the 35 bucks.
Submitted by: Bompa
OptiPerl
Xarka Software		 $59 Full featured, tons of options, settings, and features, but more money than I want to spend at this time.
Submitted by: Bompa
Perl Builder 2.0
from Solutionsoft		 $149 Submit a review.
visiPerl+
from Softpile		 $59 Submit a review.
Komodo
from ActiveState		 $295 Submit a review.
DzSoft Perl Editor
by DzSoft		 $59 Like OptiPerl, full featured, tons of options, settings, and features, but more money than I want to spend at this time.
Submitted by: Bompa
EditPlus
by ES Computing		 $30 Submit a review.

SciTE
Free source project.
Project Admin:Neil Hodgson		 Free Syntax highlighting for many languages, output pane, C-like macros (via FilerX), quick, small and mighty :-)
Submitted by: Jenda
VIM
Bram Moolenaar		 Free Vi and emacs, the great unix editor debate. Personally I like vim, it's quick, works great over slow links and has more features than you can shake a stick at. Once you've grokked enough of the commands to make this little baby run you'll never want to go back. mouse? mouse? i don't want no steeenking mouse. You windows types can even join in the fun too.
Submitted by: Daniel Gardner

Networking

[Oct. 07, 2000] A special module IPC-Run by Barrie Slaymaker([email protected]). After a user's spun up on bash/ksh, it provides useful piping constructs, subprocesses, and either expect-like or event loop oriented I/O capabilities.

www.perl.com Perl Reference/Networking

www.perl.com - You want to find the IP address of a host or turn an IP address into a name. Recipe of the Day

[Feb 20, 2000] pftp pFtp is a ftp client written in perl. It uses the Perl/Tk and Libnet libraries, both available from the CPAN FTP site. Download: pFtp 0.05

[Jan 28, 2000] DDJ EXAMINING PERLDAP by Troy Neeriemer

Netscape's PerLDAP is an important tool for both programmers and administrators because it provides a mechanism for accessing directory information from Perl. Troy presents a high-level overview of PerLDAP, along with details of how you can use it. Additional resources include perldap.txt (listings) and perldap.zip (source code).

File managers

Paw (Perl ASCII Widgets) is a widgetset for generating a GUI on ASCII based terminals. It contains button, radiobutton, label, line, listbox, text_entry, pull-down-menu, filedialog, popup-box and more. Examples are included. This
software requires Perl::Curses.

[Apr 18, 2001] Drall -- Stable version 1.4.0.0. Much better that it was and now supports authentication using the same author's Averist module. Written in Perl (GNU license) Screenshots:

Here is the quote from the author page:

If you like Drall, please express your satisfaction with a donation: send me what you feel Drall has been worth to you. If you are glad that I developed Drall and distribute it as free software, rather than following the obstructive and antisocial practices typical of software developers, reward me. If you would like me to develop more free software, contribute.

Scripts Archives

US Mirrors Europe Mirrors
CPAN [Texas] CPAN [funet.fi]
CPAN [California] cdrom.com CPAN [ruhr-uni-bochum.de]
CPAN [New York] CPAN [pasteur.fr]
CPAN [Massachusetts] CPAN [ruu.nl]
CPAN [sunet.se]
CPAN [sunsite.auc.dk]