This section is the place to post your general code offerings.

How to perldebug a Term::ReadLine application
1 direct reply — Read more / Contribute
by LanX
on Dec 01, 2014 at 09:42

    the problem

    I recently heard monks complaining that applications using Term::ReadLine can't be debugged within the perldebugger b/c it's interface relies on Term::Readline.

    the trick

    here one solution (at least for linux) I wanted to have documented (before I forget it again ;)

    call the script you want to debug (here ) from a shell with

    PERLDB_OPTS="TTY=`tty` ReadLine=0" xterm -e perl -d ./

    and a second xterm will be opened running the program.

    how it works

    a second xterm is started running the debugger, but b/c of the TTY setting in PERLDB_OPTS all debugger communication goes via the parent xterm , while the calc app normally displays in the child xterm .

    ReadLine=0 tells the debugger not to rely on a working Term::ReadLine.

    NB: It's important that calling the second xterm blocks the execution in the first xterm till it's finished. Like this keystrokes aren interpreted by two applications in the first xterm. Just put an & at the end to see how things get messed up otherwise if the shell tries to step in.

    how it looks like

    first xterm

    becomes the front end for the debugger

    as you see I get the lines from the app in the second xterm listed can set a breakpoint at the end of the loop and tell twice to continue till next breakpoint.

    second xterm

    runs the application, I'm asked to enter a calculation which is evaluated, interupted twice by a breakpoint at line 9.

    Enter code: 1+2 3 Enter code: 4+4 8

    the test script

    > cat ./ use Term::ReadLine; my $term = Term::ReadLine->new('Simple Perl calc'); my $prompt = "Enter code: "; my $OUT = $term->OUT || \*STDOUT; while ( $_ = $term->readline($prompt) ) { my $res = eval($_); warn $@ if $@; print $OUT $res, "\n" unless $@; $term->addhistory($_) if /\S/; }

    tested with Term::ReadLine::Gnu installed.


    you can use this approach whenever you want the debugger communication separated into a separate term. e.g. Curses::UI comes to mind


    the solution is not "perfect", of course you need to arrange the windows and switch with Alt-Tab between them. (maybe screen could solve this or an emacs inegration)

    Furthermore you won't have a history with arrow navigation within the debugger, cause TRL was disabled.

    another approach is to communicate via sockets with a debugger run within emacs, since emacs has it's own TRL-emulation this shouldn't interfere.

    see also Re: Testing terminal programs within emacs (SOLVED) for an approach to handle all this automatically, by restarting a script with altered environment and different terminal.


    see perldebguts , perldebtut and perldeb,

    Also "Pro Perl Debugging" book and various TK tools on CPAN.

    Cheers Rolf


The hills are alive...
4 direct replies — Read more / Contribute
by Lady_Aleena
on Nov 26, 2014 at 22:25

    ..with The Sound of Music. ;)

    I had @SoM_notes and $SoM sitting around doing nothing, so this evening, I made them do something. In make_SoM_song and get_SoM_def, you enter a string of alphabetical notes (c, d, e, f, g, a, b). The notes can be separated by a comma, semicolon, or a space. The functions will return the note name given by Maria von Trapp in The Sound of Music.

    I wrote random_SoM_note and random_SoM_song because I couldnt' help myself. Most of you know how much I love to randomly generate things. :)

    make_SoM_song, get_SoM_def, and random_SoM_song all return array references.

    Enjoy the code!

    package SoundofMusicSong; use strict; use warnings; use Exporter qw(import); our @EXPORT_OK = qw(make_SoM_song get_SoM_def random_SoM_note random_S +oM_song); my @base_notes = qw(c d e f g a b); my @SoM_notes = qw(do re me fa so la te); my %notes; @notes{@base_notes} = @SoM_notes; my $SoM = { 'do' => 'a deer a female deer', 're' => 'a drop of golden sun', 'me' => 'a name I call myself', 'fa' => 'a long long way to run', 'so' => 'a needle pulling thread', 'la' => 'a note to follow so', 'te' => 'a drink with jam and bread', }; sub make_SoM_song { my ($user_song) = @_; my @song_notes = split(/[ ,;]/, $user_song); my @new_song = map { $_ = $_ =~ /^[a-g]$/ ? $notes{$_} : 'not a note +'; $_ } @song_notes; return \@new_song; } sub get_SoM_def { my ($user_song) = @_; my $notes = make_SoM_song($user_song); my @new_song = map { $_ = $$SoM{$_} ? $_.' '.$$SoM{$_} : 'not a note +'; $_ } @$notes; return \@new_song; } sub random_SoM_note { my $note = $SoM_notes[rand @SoM_notes]; return $note; } sub random_SoM_song { my ($number_of_notes) = @_; my $notes = $number_of_notes ? $number_of_notes : int(rand(100)) + 1 +; my @new_song; push @new_song, random_SoM_note for (1..$notes); return \@new_song; } 1;
    Lady Aleena
CPAN Namespace Navigator
1 direct reply — Read more / Contribute
by Discipulus
on Nov 25, 2014 at 06:23
    CPAN Namespace Navigator is an interactive program that let you to navigate all namespaces on CPAN.
    The idea born when i read that before upload something to CPAN is better to explore existing modules, but when i asked here in the chat how to browse it i discovered that ther is not a real exploration program to do it.

    So the challenge was to hack directly the fomous file 02packages.details.txt that we receive (gzipped) when we search some module with some CPAN client. I used Term::ReadLine not without some headache.

    I decided (unwisely) to eval directly the data received to build up a big HoH with the whole hierarchy of CPAN modules and reletad infos. As suggested (wisely) by ambrus and yitzchak i looked at tye's Data::Diver and on my own at an ancient and unmaintained Data::Walker one.

    I was not able to bind Data::Diver at my will to add to the structure others infos like parent namespace or version, so i reinvented that wheel evaluating everything by myself.

    Surprisingly it worked.

    This is the usage and the navigation commands available during the navigation:
    USAGE: [02packages.details.txt] NAVIGATION: . simple list of contained namespaces .. move one level up + detailed list of contained namespaces * read the readme file of current namespace ** download the current namespace's package ? print this help TAB completion enabled on all sub namespaces by Discipulus as found at
    And here you have the code, finally crafted after 37 steps of development.


    update: take a look also at Re: Autocomplete in perl console application
    There are no rules, there are no thumbs..
Archive by month and extension
No replies — Read more | Post response
by GotToBTru
on Nov 24, 2014 at 16:01

    Created the following to archive data from our applications. We archive by month, and by file extension, so those are built in assumptions in this program.

    Source Code:


    1 Peter 4:10
img - display a small graphic file at the command line
1 direct reply — Read more / Contribute
by sflitman
on Nov 22, 2014 at 21:21

    I do a lot of work in Putty and need to look at icon files sometimes. I thought it would be cool to get Putty to display them in bash directly, rather than using X11 forwarding. This is not meant to be any kind of substitute for real graphics, but is a quick way to see whether a particular image file (like an icon or a web button) is what I think it is. Note that it requires 256 color to be turned on in Putty, that your Terminal setting is putty-256color, and it only handles image formats handled by GD (png, jpg, gif).

    #!/usr/bin/perl # Steve Flitman - released to Public Domain - display a small image on + the console using 256-color mode Putty/Screen # Color output to terminal derived from Todd Larason < +> use strict; use warnings; use GD; unless (@ARGV) { die "img file ...\nDisplay files at command line using ANSI 256 col +or mode\n"; } # set colors 16-231 to a 6x6x6 color cube for (my $red=0; $red<6; $red++) { for (my $green=0; $green<6; $green++) { for (my $blue=0; $blue<6; $blue++) { printf("\x1b]4;%d;rgb:%2.2x/%2.2x/%2.2x\x1b\\", 16 + ($red * 36) + ($green * 6) + $blue, ($red ? ($red * 40 + 55) : 0), ($green ? ($green * 40 + 55) : 0), ($blue ? ($blue * 40 + 55) : 0)); } } } # colors 232-255 are a grayscale ramp, intentionally leaving out black + and white for (my $gray=0; $gray<24; $gray++) { my $level=($gray * 10) + 8; printf("\x1b]4;%d;rgb:%2.2x/%2.2x/%2.2x\x1b\\", 232 + $gray, $level, $level, $level); } my ($file,$x,$y,$r,$g,$b,$color,$index,$image,$width,$height); for $file (@ARGV) { die "Cannot read $file: $!\n" unless -r $file; my $image=GD::Image->new($file); die "Not a recognized image format: $file\n" unless defined $image; my ($width,$height)=$image->getBounds(); for (my $y=0; $y<$height; $y++) { for (my $x=0; $x<$width; $x++) { my $index=$image->getPixel($x,$y); my ($r,$g,$b)=$image->rgb($index); if ($r+$g+$b==0) { # black $color=0; } elsif ($r==255 && $g==255 && $b==255) { # white $color=15; } elsif ($r==$g && $g==$b) { # grayscale $color=232+($r>>3); } else { $color=16+(int($r/42.6)*36)+(int($g/42.6)*6)+int($b/42.6); + # smush 256 color range to 6 levels } print "\x1b[48;5;${color}m "; } print "\x1b[0m\n"; # reset } print "\x1b[0m\n"; # reset } exit;

    Dedicated to the memory of John Todd Larason,



NSA's FoxAcid
2 direct replies — Read more / Contribute
by morgon
on Nov 20, 2014 at 09:49
    According to various top-secret documents provided by Snowden, FoxAcid is the NSA codename for what the NSA calls an "exploit orchestrator," an internet-enabled system capable of attacking target computers in a variety of different ways. It is a Windows 2003 computer configured with custom software and a series of Perl scripts.


    It may stretch the definition of "cool" and may be old news but maybe a few monks will find this amusing...

read file a paragraph at a time and return paragraph OR get specific data from paragraph
3 direct replies — Read more / Contribute
by james28909
on Nov 02, 2014 at 16:10
    i have figured out how to read a file a paragraph at a time :D lol. in this example i will be reading a file a paragraph at a time and then getting only certain data back.

    this will return everything AFTER the pattern up until a newline very quickly for me but prob could be done faster by a seasoned coder. you can modify it to suit your needs hopefully.
    tested with active perl and win7 ultimate x64
    $/ = ""; #set to paragraph mode while(<$file>){ if ($_ =~ /$first_match/ && $_ =~ /$second_match/ && $_ =~ /$third +_match/){ print "$_\n"; my ($needed_data_0) = (/^data_here(.+)/, $_); my ($needed_data_1) = (/^more_data(.+)/, $_); my ($needed_data_2) = (/^other_data(.+)/, $_); print "data0 is: $needed_data_0\n"; print "data1 is: $needed_data_1\n"; print "data2 is: $needed_data_2"; } }
    any input or pointers are welcome.
Random video player
2 direct replies — Read more / Contribute
by james28909
on Oct 29, 2014 at 14:02
    this little script will use file random to get a video file and will use your player of choice to launch it. mediainfo.exe was used to get sleep count.

    if you see anyway i can improve it please make a comment. i am trying to figure out how to push the filename to an array and do a check if it has played it in the last 100 videos/loops(that would help keep it from repeating if it does i think). i would also like to specify how many times to loop before exiting, that way it doesnt just loop forever and ever and the user can specify how many shows they want to watch.

    i wasnt please with the way i had to get duration, but it worked and i was astounded, so if you have of a better was to get duration time, please let me know. the problem i was dealing with while getting duration with any tool was spaces in the path/filenames. Here is the code:
    use strict; use warnings; use diagnostics; use File::Random qw(random_file); my $dir = $ARGV[0]; if ( not defined $dir ) { print "\nUsage: [folder]; exit(0); }else{ random($dir); } sub random{ my ($dir) = @_; while (1){ my $mpc = "C:/Program Files (x86)/K-Lite Codec Pack/Media +Player Classic/mpc-hc.exe"; my $rndm_file = random_file( -dir => $dir, #-check => qr/./, -recursive => 1 ); if ($rndm_file =~ /\.(ini|nfo|db)$/i){ print "$rndm_file\n"; random($dir); } print $rndm_file; #get duration my $t = ("MediaInfo.exe --Output=Video;%Duration% \"F:/TV/ +$rndm_file\""); system(1, $mpc, "F:/TV/$rndm_file"); my $time = qx($t); my $sleep_time = $time/1000; #in seconds because m +ediainfo.exe outputs milliseconds i think. print "\nDuration in seconds: $sleep_time\n"; sleep($sleep_time); random($dir); } }
    this works great if you have a ton of media in a folder and want to randomly watch any given inside in that directory, and you do not have to worry about spaces in path/filenames. and this is also for windows but i think it could be used on any other platform as well with small changes
Using Data::Compare recursively to better identity differences between hashes
2 direct replies — Read more / Contribute
by Lady_Aleena
on Oct 18, 2014 at 01:49

    Yesterday I wanted to compare two hashes to see if they were the same. I looked around a little bit and found Data::Compare. It was good at telling me the two hashes were different, however, it did not tell me where. So, I wrote a small little subroutine to recursively check my hash of hashes (of hashes). It was able to identity where I had to look to make corrections, almost to the exact spot. (I am unsure how to compare arrays of hashes just yet which is why the following little subroutine will almost take you to the right spot.)

    There are still holes in the script, but it worked for me today.

    #!/usr/bin/perl use strict; use warnings FATAL => qw( all ); use Data::Compare; use Data::Dumper; # You can take out all instances of the subroutine 'line' to print wha +t you want in those places. sub deep_data_compare { my ($tab, $old_data, $new_data, $data) = @_; my $old = $old_data; my $new = $new_data; my $compare = new Data::Compare($old, $new); if ($compare->Cmp == 0) { line($tab,$data) if $data; if (ref($old) eq 'HASH' && ref($new) eq 'HASH') { line($tab+1,'old to new'); for (keys %$old) { deep_data_compare($tab+2,$_,$$old{$_},$$new{$_}); } } # I have not figured out this part yet. # elsif (ref($old) eq 'ARRAY' && ref($new) eq 'ARRAY') { # } else { print Dumper($new); print Dumper($old); } } } sub rline { my ($tab,$line) = @_; return qq(\t) x $tab.qq($line\n); } sub line { print rline(@_); } deep_data_compare(0, \%old_hash, \%new_hash, 'widgets');
    Lady Aleena
Identifying scripts (writing systems)
2 direct replies — Read more / Contribute
by AppleFritter
on Sep 16, 2014 at 17:32

    Dear monks and nuns, priests and scribes, popes and antipopes, saints and stowaways lurking in the monastery, lend me your ears. (I promise I'll return them.) I'm still hardly an experienced Perl (user|programmer|hacker), but allow me to regale you with a story of how Perl has been helping me Get Things Done™; a Cool Use for Perl, or so I think.

    I was recently faced with the problem of producing, given a number of lines each written in a specific script (i.e. writing system; Latin, Katakana, Cyrillic etc.), a breakdown of scripts used and how often they appeared. Exactly the sort of problem Perl was made for - and thanks to regular expressions and Unicode character classes, a breeze, right?

    I started by hardcoding a number of scripts to match my snippets of text against:

    my %scripts; foreach (@lines) { my $script = m/^\p{Script=Latin}*$/ ? "Latin" : m/^\p{Script=Cyrillic}*$/ ? "Cyrillic" : m/^\p{Script=Han}*$/ ? "Han" : # ... "(unknown)"; $scripts{$script}++; }

    Obviously there's a lot of repetition going on there, and though I had a list of scripts for my sample data, I wasn't sure new and uncontemplated scripts wouldn't show up in the future. So why not make a list of all possible scripts, and replace the hard-coded list with a loop?

    my %scripts; LINE: foreach my $line (@lines) { foreach my $script (@known_scripts) { next unless $line =~ m/^\p{Script=$script}*$/; $scripts{$script}++; next LINE; } $scripts{'(unknown)'}++; }

    So far, so good, but now I needed a list of the scripts that Perl knew about. Not a problem, I thought, I'll just check perluniprops; the list of properties Perl knows about was staggering, but I eventually decided that any property of the form "\p{Script: ...}" would qualify, so long as it had short forms listed (which I took as an indication that that particular property was the "canonical" form for the script in question). After some reading and typing and double-checking, I ended up with a fairly long list:

    my @known_scripts = ( "Arabic", "Armenian", "Avestan", "Balinese", "Bamum", "Batak", "Bengali", "Bopomofo", "Brahmi", "Br +aille", "Buginese", "Buhid", "Canadian_Aboriginal", "Carian", "Chakma", "Cham", "Cherokee", "Coptic", "Cuneiform", "Cypriot", "Cyrillic", # ... );

    Unfortunately, when I ran the resulting script, Perl complained:

    Can't find Unicode property definition "Script=Chakma" at (...) line ( +...)

    What had gone wrong? Versions, that's what: I'd looked at the perluniprops page on, documenting Perl 5.20.0, but this particular Perl was 5.14.2 and didn't know all the scripts that the newer version did, thanks to being built against an older Unicode version. Now, I could've just looked at the locally-installed version of the same perldoc page, but - wouldn't it be nice if the script automatically adapted itself to the Perl version it ran on? I sure reckoned it'd be.

    What scripts DID the various Perl versions recognize, anyway? What I ended up doing (perhaps there's an easier way) was to look at lib/unicore/Scripts.txt for versions 5.8, 5.10, ..., 5.20 in the Perl git repo (I skipped 5.6 and earlier, because a) the relevant file didn't exist in the tree yet back then, and b) those versions are ancient, anyway). And by "look at", I mean download (as scripts-58.txt etc.), and then process:

    $ for i in 8 10 12 14 16 18 20; do perl scripts-5$i.txt >5$ +i.lst; done $ for i in 8 10 12 14 16 18; do diff --unchanged-line-format= --new-li +ne-format=%L 5$i.lst 5$((i+2)).lst >5$((i+2)).new; done $ was a little helper script to extract script information (apologies for the confusing terminology, BTW):

    #!/usr/bin/perl use strict; use warnings; use feature qw/say/; my %scripts; while(<>) { next unless m/; ([A-Za-z_]*) #/; $scripts{$1}++; } $, = "\n"; say sort { $a cmp $b } map { $_ = ucfirst lc; $_ =~ s/(?<=_)(.)/uc $1/ +ge; qq/"$_"/ } keys %scripts;

    I admit, I got lazy at this point and manually combined those files (58.lst, as well as, etc.) into a hash holding all the information, instead of having a script output it. Nonetheless, once this was done, I could easily load all the right scripts for a given Perl version:

    # New Unicode scripts added in Perl 5.xx my %uniscripts = ( '8' => [ "Arabic", "Armenian", "Bengali", "Bopomofo", "Buhid", "Canadian_Aboriginal", "Cherokee", "Cyrillic", "Deseret", "Devanagari", "Ethiopic", "Georgian", "Gothic", "Greek", "Guja +rati", "Gurmukhi", "Han", "Hangul", "Hanunoo", "Hebrew", "Hiragana", "Inherited", "Kannada", "Katakana", "Khmer", "Lao", "Latin", "Malayalam", "Mongolian", "Myanmar", "Ogham", "Old_Italic", "O +riya", "Runic", "Sinhala", "Syriac", "Tagalog", "Tagbanwa", "Tamil", "Telugu", "Thaana", "Thai", "Tibetan", "Yi" ], '10' => [ "Balinese", "Braille", "Buginese", "Common", "Coptic", "Cuneif +orm", "Cypriot", "Glagolitic", "Kharoshthi", "Limbu", "Linear_B", "New_Tai_Lue", "Nko", "Old_Persian", "Osmanya", "Phags_Pa", "Phoenician", "Shavian", "Syloti_Nagri", "Tai_Le", "Tifinagh", "Ugaritic" ], '12' => [ "Avestan", "Bamum", "Carian", "Cham", "Egyptian_Hieroglyphs", "Imperial_Aramaic", "Inscriptional_Pahlavi", "Inscriptional_Parthian", "Javanese", "Kaithi", "Kayah_Li", "Lepcha", "Lisu", "Lycian", "Lydian", "Meetei_Mayek", "Ol_Chik +i", "Old_South_Arabian", "Old_Turkic", "Rejang", "Samaritan", "Saurashtra", "Sundanese", "Tai_Tham", "Tai_Viet", "Vai" ], '14' => [ "Batak", "Brahmi", "Mandaic" ], '16' => [ "Chakma", "Meroitic_Cursive", "Meroitic_Hieroglyphs", "Miao", "Sharada", "Sora_Sompeng", "Takri" ], '18' => [ ], '20' => [ ], ); (my $ver = $^V) =~ s/^v5\.(\d+)\.\d+$/$1/; my @known_scripts; foreach (keys %uniscripts) { next if $ver < $_; push @known_scripts, @{ $uniscripts{$_} }; } print STDERR "Running on Perl $^V, ", scalar @known_scripts, " scripts + known.\n";

    The number of scripts Perl supports this way WILL increase again soon, BTW. Perl 5.21.1 bumped the supported Unicode version to 7.0.0, adding another bunch of new scripts as a result:

    # tentative! '22' => [ "Bassa_Vah", "Caucasian_Albanian", "Duployan", "Elbasan", "Gra +ntha", "Khojki", "Khudawadi", "Linear_A", "Mahajani", "Manichaean", "Mende_Kikakui", "Modi", "Mro", "Nabataean", "Old_North_Arabia +n", "Old_Permic", "Pahawh_Hmong", "Palmyrene", "Pau_Cin_Hau", "Psalter_Pahlavi", "Siddham", "Tirhuta", "Warang_Citi" ],

    But that's still in the future. For now I just tested this on 5.14.2 and 5.20.0 (the two Perls I regularly use); it worked like a charm. All that was left to do was outputting those statistics:

    print "Found " . scalar keys(%scripts) . " scripts:\n"; print "\t$_: " , $scripts{$_}, " line(s)\n" foreach(sort { $a cmp $b } + keys %scripts);

    (You'll note that in the above two snippets, I'm using print rather than say, BTW. That's intentional: say is only available from Perl 5.10 on, and this script is supposed to be able to run on 5.8 and above.)

    Fed some sample data that I'm sure Perlmonks would mangle badly if I tried to post it, this produced the following output:

    Running on Perl v5.14.2, 95 scripts known. Found 18 scripts: Arabic: 21 line(s) Bengali: 2 line(s) Cyrillic: 12 line(s) Devanagari: 3 line(s) Georgian: 1 line(s) Greek: 1 line(s) Gujarati: 1 line(s) Gurmukhi: 1 line(s) Han: 29 line(s) Hangul: 3 line(s) Hebrew: 1 line(s) Hiragana: 1 line(s) Katakana: 1 line(s) Latin: 647 line(s) Sinhala: 1 line(s) Tamil: 4 line(s) Telugu: 1 line(s) Thai: 1 line(s)

    Problem solved! And not only that, it's futureproof now as well, adapting to additional scripts in my input data, and easily extended when new Perl versions support more scripts, while maintaining backward compatibility.

    What could still be done? Several things. First, I should perhaps find out if there's an easy way to get this information from Perl, without actually doing all the above.

    Second, while Perl 5.6 and earlier aren't supported right now, they could be. Conveniently, the 3rd edition of Programming Perl documents Perl 5.6; the \p{Script=...} syntax for character classes doesn't exist yet, I think, but one could write \p{In...} instead, e.g. \p{InArabic}, \p{InTamil} and so on. Would this be worth it? Not for me, but the possibility is there if someone else ever had the need to run this on an ancient Perl. (Even more ancient Perls may not have the required level of Unicode support for this, though I wouldn't know for sure.)

    Lastly, since the point of this whole exercise was to identify writing systems used for snippets of text, there's room for optimization. Perhaps it would be faster to precompile a regular expression for each script, especially if @lines is very large. Most of the text I'm dealing with is in the Latin script; as such, I should perhaps test for that before anything else, and generally try to prioritize so that lesser-used scripts are pushed further down the list. Since I'm already keeping a running total of how often each script has been seen, this could even be done adaptively, though whether doing so would be worth the overhead in practice is another question, one that could only be answered by measuring.

    But neither speed nor support for ancient Perls is crucial to me, so I'm done. This was a fun little problem to work on, and I hope you enjoyed reading about it.

Mojolicious starting template
1 direct reply — Read more / Contribute
by neilwatson
on Sep 05, 2014 at 14:03

    I like Mojolicious, but it was hard to learn. More than six months later I still feel I'm just scratching the surface. So, what I'm about to offer may not be great, but it is as far as I've come. You'll still need to study the Mojolicious documentation, but you can start with this rather than nothing.

    Template here.

    And a tip of the hat to Sebastian and his team mates, who have answered my novice questions and have been quick to improve the documentation to help newbies like me.

    Neil Watson

Commodore disk image processor thingy
5 direct replies — Read more / Contribute
by rje
on Sep 01, 2014 at 19:57
    Dear Perlmonks,

    I wrote a Perl library, and I think it's pretty cool, but I'm also asking your opinions about it - is it worth putting on CPAN, for instance.

    It is a pure-Perl library for handing Commodore disk images. For those needing a refresher, these are digital images of diskettes and hard disks used by Commodore computers in the late 1970s thru the 1980s.

    It's hosted inside my network, behind my modem's firewall, by my Raspberry Pi running a cheapo web server I wrote (also in Perl) specifically for the purpose of serving and manipulating Commodore disk images.

    My library handles D64, D71, D81, D67, D80, D82, and X64 image types. Each format is a little package (about 8k) with data specific to that image. I made them packages, although I could have just used parametric data. These packages are essentially parametric data anyhow, and provide context to a generic engine that knows how Commodore disk images work.

    The library is 140k (includes good POD documentation, which is rare for me) split among about 20 files.

    First, is it worth posting to CPAN. It's awfully specialized. Maybe it would be better just to post it as a tarball on a website (or github?).

    Second, it's been nearly 10 years since I've uploaded to CPAN, and I am intimidated by the process. Yes, I've read the rules, but I'm concerned about uploading 20 related files in one batch. Anyone have any advice beyond what PAUSE has to say?

    Thanks for listening.

Duct taping spam-bot protection to a web forum
1 direct reply — Read more / Contribute
by aitap
on Aug 31, 2014 at 10:24

    There is a free web hosting which offers a third-level domain name and an installation of their proprietary CMS. It is somewhat widely known in the ex-USSR countries. They have "Web 2.0" AJAX interface, a lot of modules for nearly everything, from a simple forum to a web shop, and a primitive read-only API. I happen to be moderating one of such forums. Despite not being popular in terms of human population it has recently gained a lot of popularity among spam-sending robots.

    At first they all were making the same mistake of posting messages with titles equal to their nicknames, and so the first version of was born. It employed link parsing routines of WWW::Mechanize and reproduced a sniffed AJAX request by some black magic of parsing JavaScript source for variables. Needless to say, soon it broke, both because JavaScript source slightly changed and because bots became slightly smarter, so the moderators went back to deleting bots manually.

    Yesterday I thought: with PhantomJS, I could mimic the browser and click all these AJAX buttons required to ban a user. As for the spam, maybe it's possible to count unique words in a message and warn if some of them is repeated a lot, and a list of stop-words could help, too... Before I started thinking of ways to automatically build a list of stop words from spam messages I realised that I was reiventing the wheel and searched for spam detection engines.

    My first try was Mail::SpamAssassin, because it's written in Perl and I heard a lot of stories about plugging it into other programs. It turned out to be not so easy to make it work with plain text (non-mail) messages, so I searched for alternatives. It is Mail::SpamAssassin, after all. Bogofilter is not written in Perl, but still was easy to plug in my program, thanks to its -T option, and it happily works with plain text without complaining.

    Interfacing with the site was not so easy. Banning a spam robot (click-click-tab-tab-"spam robot"-tab-space-tab-space) exploded into a mess of ->clicking xpath-found elements; at one time the site refused to register my click no matter how I tried, so I had to call the corresponding JS function manually; in the other place of program I find myself logged out, and the only way to get back in is to load the page I'm going to delete, load the login page, log in, then load the to-be-deleted page again. Kludges. Ew.

    So, here it is: the second version of bot hunter Perl program. I hope it won't break as fast as the first one. Or, at least, will be easier to fix.

LED blinking Morse code from Raspberry Pi
4 direct replies — Read more / Contribute
by rje
on Aug 30, 2014 at 11:23
    With the handy Device::BCM2835 package, I tossed together this little package so I could send "morse code" out on an LED I connected to GPIO Pins #5 and #7.

    (FYI: the Raspberry Pi can run a number of Linux systems, all with Perl. I wrote a tiny HTTP server on it which lets me create and serve Commodore disk images, also allowing me to extract and inject files, in Perl of course. It runs behind my firewall...)

'bld' project - signature(SHA1) based replacement for 'make'
4 direct replies — Read more / Contribute
by rahogaboom
on Aug 22, 2014 at 15:14
    'bld' is entirely in Perl. 'bld' is a replacement for the 'make' command. It is based on determi +ning out of dateness by signatures(SHA1) not dates. For a critique of 'make' and why you woul +d want to do this see: and the FEATURES AND AD +VANTAGES section below (item 13) "'make' and it's difficulties". 'bld' at present has been d +esigned and tested for C/C++/Objective C/Objective C++/ASM; Java or any other languages are n +ot at present used. Installing 'bld' is very simple. Download bld-1.0.0.tar.xz from https +:// Unpack wherever in your home directory and install the + Perl module. Make sure you have access to GNU 'cpp' and 'ldd'. To run the examples +(examples, git, svn, systemd) you'll need gcc(1)/g++(1) ( and clang(1) (http://l That's It! I used the git, svn and systemd projects as complex multi-target examp +les of how bld would be used to re-'make' these projects. They are well known and widely used. An +y other projects might do. Read the bld.README file. Do './bld -h'. Do 'perldoc bld'. Do './bld' to build the exec-c executable "Hello, world!" program. Th +is creates the, bld.warn and Bld.sig files which along with the Bld file + gives an illustration of how to construct Bld files and the output that bld + creates. I plan on adding an App::bld distribution to CPAN. NAME bld VERSION bld version 1.0.0 USAGE usage: bld [-h] -h - this message.(exit) ARGUMENTS None OPTIONS bld [-h] -h help message(exit) ENVIRONMENT VARIABLES None RC CONFIGURATION FILES None DEPENDENCIES Required for execution: - for smartmatch and switch features cpp(1) - gnu cpp cmd is required for dependency determination ldd(1) - used for library dependency determination Required for test: gcc(1)/g++(1) ( clang(1) ( FEATURES AND ADVANTAGES 1. Everything is done with SHA1 signatures. No dates are used anywhe +re. Signatures are a property of the file and not meta data from the system used for the build. Any ti +me issues, whether related to local clocks, networked host clocks or files touched by command activiti +es are eliminated. Modern signature algorithms are strongly randomized even for small file changes - f +or the 160 bit SHA1 hash collisions are unlikely in the extreme. The Digest::SHA module is fast. The exp +ense of signature calculation times is small relative to the expense of programmer time. An investiga +tion of some other make alternatives e.g. scons, cook - will disclose that they too are using signature +s - maybe for exactly for the same reasons. 2. bld is REALLY simple to use. There are no arguments, no options(e +xcept -h), no environment variables and no rc files. The entire bld is controlled from the Bld(and Bld.gv + file) file. Only a minimal knowledge of perl is needed - variable definitions and simple regular expres +sions. 3. Automatic dependency checking - GNU cpp is used to find the header + file dependencies. Optionally, header file checking may be done for user header files only or for simult +aneously both system header and user header files. All header file dependency information associated w +ith each source is saved to the file. 4. There are no built in dependency rules. The Bld file DIRS section + specifications give what is to be built from what and the Bld file EVAL section gives how to assembl +e all the components for the target. 5. bld is not hierarchical. A single Bld file controls the construct +ion of a single target(a target is an executable or library(static or shared)). Complex multi-target pr +ojects use one Bld.gv(global values) file and many Bld files - one to a target. The source directory s +tructure goes under bld.<project>/<version> and each target Bld file(Bld.<project>.<target>) encapsulates all +the build information for all the source directories under bld.<project>/<version>. All the built t +argets and build information files go into the Bld.<project>/<version> directory. See 13 below for reas +ons why recursive make causes problems. 6. Each source file will have three signatures associated with it - o +ne for the source file, one for the corresponding object file and one for the cmds use to rebuild the +source. A change in any of these will result in a rebuild. A change in the target signature will result + in a rebuild. Optionally, the signatures of dynamic libraries may be tracked. If a library sign +ature changes the bld may warn or stop the rebuild. If dynamic libraries are added or deleted from the b +ld this can ignore/warn/fatal. 7. If any files in the bld have the same signature this is warned abo +ut e.g. two header or source files of the same or different names. 8. Complex multi-target projects are built with a standard directory +setup and a standard set of scripts - Directories: Bld.<project>/<version> - has all files controlling <pro +ject> <version>s blds and bld target output files bld.<project>/<version> - source code for <project> <ver +sion>s Files: bld.<project> - for initiating single target, +multi-target or all target blds of a <project> bld.<project>.rm - for initiating single target, +multi-target or all target clean of a <project> bld.<project>.targets - list of all <project> targets bld.<project>.README - <project> README bld.<project>.install - <project> install script bld.<project>.script.<script> - scripts called by the Bld.<pro +ject>.<target> files Bld.<project>.<target> - the Bld file for each <project +> <target> Bld.gv.<project> - global values imported into al +l Bld.<project>.<target> files 9. Security - since the signatures of everything(source, objects, lib +raries, executable) are checked it is more difficult to insinuate an exploit into a source, object, libr +ary or executable during the build process. 10. The capture of the full build process in the, bld.warn a +nd bld.fatal files allows easy access to and saving of this information. For multi-target projects with t +he target names appended to these files it allows quick investigation of the build process of many interr +elated targets at the same time. 11. Perl - since bld is all perl and since all warnings and fatals ha +ve the source line number associated with them, it is very easy to locate in the souce code the exact locat +ion of an error and examine the context about which the error occurred and routine that the error was pro +duced in. 12. Time - programmer time; learning about, maintaining/debugging Mak +efiles and Makefile hierarchies, dependency checking integration and formulation of Makefile strategies, auto +matic Makefile generation with Autotools - these all dominate the programmer time and expense of 'make'. bl +d only requires basic perl variables(in the Bld file EVAL section) and '[R] dir:regex:{cmds}' line specif +ications(in the Bld file DIRS section). 13. 'make' and it's difficulties: a detailed critique of make and some alternatives a description of the scons architecture and in particular + the reasons for the use of signatures instead of dates +.html#SEC3 a brief critique of make and how GNU automake from the GN +U Build System contributes an article "Recursive Make Considered Harmful" by Peter M +iller from the Australian UNIX Users Group an in depth critique of make PROJECT STATE State: 1. The code is mostly done - unless someone finds a bug or suggests a +n enhancement. 2. The in code documentation is done. 3. The testing is 80%-90% done. 4. The usage msg is done - the perldoc is 50%-60% done, needs a lot o +f work. Needed: 1. The code is in very good shape unless someone discovers a bug or s +uggests an enhancement. My current focus is on the documentation and testing. 2. The git, svn and systemd projects need work. I ran ./configure be +fore each bld. I used no options. How options affect the generated code and thus the Bl +d files is important. Anyone willing to investigate configure options and how these opti +ons affect the Bld files is welcome. 3. The bld.<project>.install scripts all need to be done. I'd prefer + to partner with someone knowledgeable about the installation of git, svn and systemd. 4. All the Bld.gv.<project> files should be vetted by a <project> kno +wledgeable builder. 5. The git, svn and systemd projects will all be creating new version +s eventually. Anyone that would like to add bld.<project>/<version> and Bld.<project>/< +version> directories with the new versions is welcome. 6. I need someone with substantial experience building the linux kern +el to advise me or partner with me on the construction of 3.15 or later. 7. If you successfully bld a new project and wish to contribute the b +ld, please do so. I'm interested in how others construct/organize/document/debug project +s and their Bld files. DESCRIPTION bld(1.0.0) is a simple flexible non-hierarchical program that builds +a single C/C++/Objective C /Objective C++/Assembler target(executable or library(static or share +d)) and, unlike 'make', uses SHA1 signatures(no dates) for building software and GNU cpp for automatic +header file dependency checking. The operation of bld depends entirely on the construction +of the Bld(bld specification) and Bld.gv(bld global values) files. See the bld.README file. There + are no cmd line arguments or options(except for -h(this msg)) or $HOME/.bldrc or ./.bldrc files an +d no environment variables are used. Complex multi-target projects are bld't with the use of a Bld. +<project> (Bld files and target bld output files) directory, bld.<project>(project source) dir +ectory, bld.<project>(target construction) script, bld.<project>.rm(target and bld.<info|warn|fata +l>.<target> file removal) script, Bld.<project>.gv(project global values) file, bld.<project>.i +nstall(target and file install) script and bld.<project>.README(project specific documentati +on) file. Current example projects: Bld.git - the git project Bld.svn - the subversion project Bld.systemd - the systemd project +/Software/systemd/ Bld.example - misc examples intended to show how to create Bld an +d Bld.gv files bld is based upon taking the SHA1 signature of anything that, when ch +anged, would require a rebuild of the executable/library. It is not, like 'make', based in +any way on dates. This means that source or header files may be moved about, and if the file +s do not change then nothing needs to, or will, be rebuilt. bld is not hierarchical; all +of the information to rebuild the executable is contained in the Bld(and Bld.gv) file. The + rebuild is based on Perl's regex engine to specify source file patterns along with the Perl eval +{} capability to bring variable definitions from the Bld file into the source. bld reads the Bld file which describes the build. This example Bld f +ile serves for the following discussion: Program description and Bld file explanatory comments go here.(and + are ignored by bld) EVAL DIRS The Bld file has three sections , a starting comment section to docum +ent the Bld, an EVAL and DIRS. Variables to be used for interpolation into build commands are define +d in the EVAL section. The variables are all Perl variables. The entire EVAL section is eva +l{}'ed in bld. Any errors will terminate the run. The DIRS section has three field(: 0) + lines which are the directory, the matched files to a Perl regular expression, and a +build command for the line matched files. EVAL section variable definitions are interpolated in +to the build commands. bld will execute "$cmd $dir/$s"; for each source file, with $cmd from + the interpolated third field, $dir from the first field, and $s from the matched source seco +nd field of the DIRS section lines. Rebuilds will happen only if: 1. a source file is new or has changed 2. the corresponding object file is missing or has changed 3. the command that is used to compile the source has changed 4. a dependent header file has changed 5. the command to link the executable or build the library archive + has changed 6. the executable or library has changed or is missing The Bld.sig file, automatically built, holds the source/object/header +/executable/library file names and the corresponding signatures used to determine if a source +should be rebuilt the next time bld is run. Normally, system header files are included in +the rebuild criteria. However, with the -s switch, signature testing of these files can be +disabled to improve performance. It is unusual for system header files to change except +after a new OS installation. add description of directory structure - o dir - build dir QUICK START 1. Bld'ing the systemd project - +ware/systemd/ a. cd Bld.systemd/systemd-208 # puts you into the systemd(systemd- +208) project directory b. ./bld.systemd --all # bld's all of the systemd targets a +nd bld target output files - the<target>, the bld.warn.systemd.<target>, the bld.fatal.systemd.<target> +, files c. ./bld.systemd.rm --all # cleans up everything 2. Bld'ing the svn project - a. cd Bld.svn/subversion-1.8.5 # puts you into the svn(subversion- +1.8.5) project directory b. ./bld.svn --all # bld's all of the svn targets and +bld target output files - the<target>, the bld.warn.svn.<target>, the bld.fatal.svn.<target>, files c. ./bld.svn.rm --all # cleans up everything 3. Bld'ing the git project - a. cd Bld.git/git-1.9.rc0 # puts you into the git(git-1.9.rc0) pro +ject directory b. ./bld.git --all # bld's all of the git targets and bld t +arget output files - the<target>, the bld.warn.git.<target>, the bld.fatal.git.<target>, files c. ./bld.git.rm --all # cleans up everything 4. Bld'ing any single target a. cd bld # the main bld directory - cd here when you unpack + the bld.tar.xz file b. Install the source code in a sub-directory of the bld directory c. Create a Bld file - the Bld file entirely controls the target b +ld - see example below d. ./bld -h # the bld usage msg e. ./bld # do the bld f. ./bld.rm # clean up g. vi Bld.sig # examine the bld signature file h. vi # detailed info about the stages of the bld i. vi bld.warn # warning msgs from the bld j. vi bld.fatal # fatal msgs that terminated the bld - should be e +mpty if bld is successful FILES ~/bld directory files: bld - the bld perl script bld.rm - script to clean the bld directory bld.README - for first point of contact quick start Bld - the bld file which controls bld and the construction of +a target Bld.gv - the file of global values imported into the Bld file(unu +sually used only for multi-target builds) Bld.sig - the signature(SHA1) file created from the Bld file - information about the bld bld.warn - warnings from the bld bld.fatal - the fatal msg that ended the bld ~/bld directories: Bld.<project>/<version> - has all files controlling <project> <versio +n>s blds and bld target output files bld.<project>/<version> - source code for <project> <version>s aux - template scripts for <project> blds ~/bld/aux files: aux/bld.<project> - template copied to Bld.<project>/<version> +directories to bld multi-target projects aux/bld.<project>.rm - template copied to Bld.<project>/<version> +directories to clean multi-target projects ~/bld/Bld.<project>/<version> files: bld.<project> - for initiating single target, multi-t +arget or all target blds of a <project> bld.<project>.rm - for initiating single target, multi-t +arget or all target clean of a <project> bld.<project>.targets - list of all <project> targets bld.<project>.README - <project> README bld.<project>.install - <project> install script bld.<project>.script.<script> - scripts called by the Bld.<project>.< +target> files Bld.<project>.<target> - the Bld file for each <project> <targ +et> Bld.gv.<project> - global values imported into all Bld.< +project>.<target> files Bld.sig.<project>.<target> - the signature(SHA1) file for each <pr +oject> <target><project>.<target> - the file for each <project> +<target> bld.warn.<project>.<target> - the bld.warn file for each <project> +<target> bld.fatal.<project>.<target> - the bld.fatal file for each <project> + <target> bld.<project>.targets - all of the <project> targets PRIMARY PROGRAM DATA STRUCTURES TBD NOTES 1. bld assumes that a source will build a derived file e.g. .o files +in the same directory and have the same root name as the source. 2. bld assumes that all targets in multi-target bld's will be uniquel +y named - all targets go into the same project directory. 3. Some projects violate either or both of these target naming or obj +ect file naming/location requirements, but reconstructing these projects with bld should be + relatively easy e.g. systemd. 4. bld executes cmd fields({}) in the bld directory and then moves al +l created files to the source directory. ... Bld FILE FORMAT The Bld file(and Bld.gv) controls the entire target bld. It is divid +ed into three sections - Comment(s), EVAL and DIRS: Add comments before the EVAL line EVAL # mandatory defined variables $bld=""; $bldcmd = ""; $lib_dirs = ""; $opt_s = ""; $opt_r = ""; $opt_lib = ""; DIRS # {cmds} cmd blocks or '[R] dir:regex:{cmds}' specifications {cmds} '[R] dir:regex:{cmds}' '[R] dir:regex:{cmds}' ... 1. a comment section 2. An EVAL(starts a line) section - this is perl code that is eval'ed + in bld. Six variables are required. These are: e.g. EVAL # mandatory defined variables # the target to built e.g. executable, libx.a, $bld="exec-c"; # cmd used in perl system() call to build $bld target - re +quires '$bld'(target) and '$O'(object files) internally $bldcmd = "$CC -lm -o \$bld \$O"; # space separated list of directories to search for librar +ies $lib_dirs = "example/lib /usr/lib /lib /usr/local/lib"; # use system header files in dependency checking("system" +or "nosystem") $opt_s = "system"; # inform about any files that will require rebuilding, but + do not rebuild("rebuild" or "norebuild") $opt_r = "rebuild"; # do dependency checking on libraries("libcheck", "nolibch +eck", "warnlibcheck" or "fatallibcheck") $opt_lib = "fatallibcheck"; Any other simple perl variables can be defined in the EVAL sec +tion and used in the DIRS section. Environment variables may be set. 3. A DIRS(starts a line) section - this section will have either {cmd +s} cmd blocks or '[R] dir:regex:{cmds}' specifications. The {cmds} blocks are just a group of shell cmds, always executed. + A dir specification is a source directory relative to the bld directory. The regex specification is a perl regular e +xpression that will pick up one or more of the source files in dir. The {cmds} specification describes how to bu +ild the selected source files. Any number of cmds, ';' separated, may be specified within the {} brackets. Example Bld Files: Simplest(Bld.example/example/Bld.example.helloworld-c): The 'Hello World!' program with only the minimal required defi +nitions. Comment(s) EVAL $CC = "gcc"; # mandatory defined variables # the target to built e.g. executable, libx.a, $bld="helloworld-c"; # cmd used in perl system() call to build $bld target - re +quires '$bld'(target) and '$O'(object files) internally $bldcmd = "$CC -o \$bld \$O"; # space separated list of directories to search for librar +ies $lib_dirs = "/usr/lib /lib /usr/local/lib"; # use system header files in dependency checking("system" +or "nosystem") $opt_s = "system"; # inform about any files that will require rebuilding, but + do not rebuild("rebuild" or "norebuild") $opt_r = "rebuild"; # do dependency checking on libraries("libcheck", "nolibch +eck", "warnlibcheck" or "fatallibcheck") $opt_lib = "warnlibcheck"; DIRS bld.example/example : ^helloworld\.c$ : { $CC -c $s; } Complex(Bld.example/example/Bld.example.exec-c): A well commented example of all of the features of a Bld file. + The code routines are all just stubs designed to illustrate a Bld file. Comment(s) EVAL # this section will define perl variables to be interpolated i +nto DIRS section cmd fields # the compiler $CC = "clang"; # mandatory defined variables # the target to built e.g. executable, libx.a, $bld="exec-c"; # cmd used in perl system() call to build $bld target - re +quires '$bld'(target) and '$O'(object files) internally $bldcmd = "$CC -lm -o \$bld \$O"; # space separated list of directories to search for librar +ies $lib_dirs = "example/lib /usr/lib /lib /usr/local/lib"; # use system header files in dependency checking("system" +or "nosystem") $opt_s = "system"; # inform about any files that will require rebuilding, but + do not rebuild("rebuild" or "norebuild") $opt_r = "rebuild"; # do dependency checking on libraries("libcheck", "nolibch +eck", "warnlibcheck" or "fatallibcheck") $opt_lib = "fatallibcheck"; # some examples of variables that will be interpolated into DI +RS section cmd fields $INCLUDE = "-I bld.example/example/include"; $LSOPTIONS = "-l"; # "a" or "b" to conditionally compile main.c $COND = "a"; DIRS # this section will have either {cmds} cmd blocks or '[R] dir: +regex:{cmds}' specifications # example of use of conditional compilation bld.example/example/C : ^main\.c$ : { # can have comments here too if [ "$COND" == 'a' ]; then $CC -S $INCLUDE $s; fi if [ "$COND" == 'b' ]; then $CC -O4 -S $INCLUDE $s; fi } # example of execution of a bare block of cmds - '{' and '}' m +ay be on separate lines { ls $LSOPTIONS; } # the cmd field may be put on another line(s) and indented bld.example/example/C : ^g\.x\.C$ : { $CC -c $INCLUDE $s; } # all three fields - dir, regex and cmd - may be put on separa +te lines(even with extra blank lines). # directories may have embedded blanks('a b'). bld.example/example/C/a b : ^m\.c$ : {$CC -c $INCLUDE $s;} # example of regex field that captures multiple source files(h +.c and i.c) and example of a # cmd field with multiple cmds - white space is irrelevant(a c +hange should not cause a rebuild) # example of cmd fields with multiple cmds(ls and $CC) bld.example/example/C : ^(h|i)\.c$ : { ls -l $s; $CC +-c $INCLUDE $s; } # example of assembler source # Note: the $CC compile produces .o output by changing the c t +o an o. # the as output needs to be specified by the -o option. bld.example/example/C : ^main\.s$ : {as -c -o main.o $s;} bld.example/example/C/ww : ^u\.c$ : {$CC -c $INCLUDE $s;} # example of use of recursive directory search - the same rege +x and cmd fields # are applied to all subdirectories of the specified dir field +(right after the 'R') R bld.example/example/C/y : ^.*\.c$ : {$CC -c $INCLUDE $s;} bld.example/example/C/x : ^t\.c$ : {$CC -c $INCLUDE $s;} bld.example/example/C/z : ^(w|w1)\.c$ : {$CC -c $INCLUDE +$s;} # cmd blocks may execute multiple cmds(ls and pwd) { ls -lfda; pwd; ls; } DIAGNOSTICS Warnings(Warning ID(WID)): ... Fatals(Fatal ID(FID)): ... TODO/CONTEMPLATE/INVESTIGATE/EXAMINE/CHECKOUT/THINK ABOUT/HACK ON ... INCOMPATIBILITIES None Known BUGS AND LIMITATIONS None Known SEE ALSO bld.README Critique of 'make': - a detailed critique of make and some alternatives +l#SEC3 - a brief critique of make and how GNU automake from the GNU Bu +ild System contributes - an article "Recursive Make Considered Harmful" by Peter Mille +r from the Australian UNIX Users Group GITHUB RELEASES bld-1.0.0.tar.gz - initial release bld.git.git-1.9.rc0.tar.gz bld.svn.subversion-1.8.5.tar.gz bld.systemd.systemd-208.tar.gz AUTHOR Richard A Hogaboom LICENSE and COPYRIGHT and (DISCLAIMER OF) WARRANTY ...

Add your CUFP
and:  <code> code here </code>

  • Please read these before you post! —
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;