I am searching for a tool that behaves similarly to Unix's expect tool (or at least, its main function).
I want to automate command-line interactive programs with it.
EDIT:
I am preferring single executables or small apps without big multi megabyte depencies.
Ty.
Take a look at ActiveState's Tcl distribution which has a port of Expect for Windows.
Late answer: Expect.exe, compiled with Go, running Lua-scripts. Fairly new, but does exactly what it is supposed to do. See https://github.com/zetamatta/expect/
Check the closed issues as well.
I guess AutoIt is what you need.
I your familiar with expect, then why not install Cygwin and run it that way?
You could use pexpect, written in Python.
Related
I have a bunch of related Perl scripts that I would like to put together in one convenient place. So I was thinking of building a GUI and incorporating the scripts. I'm using Strawberry Perl on Windows XP and have just installed Tk from cpan about fifteen minutes ago. Before I go for it, I want some sound advice either for or against it.
My other option is to translate the Perl scripts into VB and use Visual Studio 2008, but that might be too much hassle for an outcome that might end up all the same had I just stuck with Perl & Tk.
I haven't looked yet, but maybe there is a module for Visual Studio that would allow me to invoke Perl scripts?
The main requirements are:
It must be able to communicate with MySQL
It must be able to fetch & parse XML files from the internet
It must be transportable, scalable, and sustainable
What direction would you take?
I've built Perl/Tk apps on Windows before and found it just fine, including using PAR to package everything up for distribution to others. It was nice being able to do most of my development on a proper Linux system and have things just magically work on Windows :) The only gotcha I encountered is that Tk doesn't play well with ithreads.
I personally would recommend wxPerl over Tk. It has native looking widgets, at least in my view leads to cleaner code and you can use wxGlade as a GUI designer.
If you haven't programmed with Perl/Tk I would think that Tkx (developed by Activestate) would be a better option. Tkx is a thin layer over Tcl/Tk, which gives it access to the new themed widgets in Tcl/Tk so your application would look better.
Perl/Tk has a lot more documentation around, but the module itself does not seem to be developed anymore. The documentation for Tkx is very sparse but by following the Tkx tutorial files on CPAN, it should be easy to get started.
WxWidgets (available for Perl via wxPerl) is an excellent graphical toolkit, but wxPerl only implements a subset of the available widgets.
PAR is convenient but if you go with Perl/Tk, the result will not run natively on OS X. (Users will need to run X11 first, which is problematic, especially with more recent version of OS X). If you go with Tkx, you can get native application on Mac OSX. Also, ActiveStates's PDK gives you a simple way to package everything to deploy to Windows, Linux, and OS X.
For reference, see the the software (AntConc and AntWordProfiler) at the following site http://www.antlab.sci.waseda.ac.jp/software.html, where AntConc was developed using Perl/Tk and AntWordProfiler was developed using Tkx.
The Process class allows to start new processes from a C# (WPF/Winforms) frontend.
I guess that way you can keep your Perl scripts and use the nice Visual Studio GUI builder.
Is there a good tool to debug Perl-based web applications? Output to stderr or stdout don't count as tool.
Yup, I've got the perfect tool for you.
CGI::Inspect lets you inspect and debug a running Perl web application.
Read more about the module on the developer's website.
Or check out the slides from a presentation about it at YAPC::NA 2009.
The Komodo IDE supports remote debugging for just this sort of thing.
The EPIC plugin for Eclipse will also let you do this.
In CGI, you can
use CGI::Carp qw(fatalsToBrowser);
It will display any fatal message in your browser.
With Mason, leave the default error option, which outputs the call stack in your browser.
Let's not assume, like the first answer, that the module being used is CGI, but rather provide something that will work across anything that is supported by/supports PSGI/Plack.
Perhaps combine Plack::Middleware::Debug (to display information about the active request and response, perhaps adding the Log4perl panel) and Devel::hdb to debug the running code in a separate tab.
Also available (I haven't tried it though) is InteractiveDebugger
Anything you try should be run in a single process, non-forking server like HTTP::Server::PSGI or HTTP::Server::Simple::PSGI for development and debugging instead of something like Starman.
Late to the party on this one, but I felt some other tools should be called out in case anyone else stumbles upon this question.
The Perl command line debugger is perfectly serviceable, but occasionally hard to use, and has a fairly steep learning curve, especially for those who are used to GUI tools.
Devel::hdb is a great tool for this. It integrates with the existing debugging functionality in Perl, so you can start the application with -d:hdb as a flag, and then you can hit a web based endpoint to start stepping through the application easily. It supports breakpoints, watch expressions, and stepping, so it can help you figure out where an issue is on a somewhat live application.
As mentioned earlier, ActiveState's Komodo IDE (not Edit) has a built in graphical debugger, that can work on a local instance or against a remote server. The remote server must have some libraries installed, and activated within the code to work. It's not invasive, but it should be known. Also, Komodo costs money, but they do provide a trial period. It'll work on Windows, OS X or Linux. ActiveState's Perl Dev Kit has an independent debugger as well, but I haven't used it in years.
I'm new to Object-Oriented programming and the perldoc page on CPAN.pm confuses the hell out of me. My program needs to download a couple of modules if they don't already exist. Is this basically just:
CPAN::Shell->install("Module::Name::Here");
or is there more to it? Does that download the package, unarchive it, and install it, or just one or two of those steps? If it's not all three, how do I do the other one (or two)? I would like it to make sure it doesn't try to re-install anything if the package is already there - is this the default behavior of the function or no?
And how can I tell if Perl couldn't connect to CPAN to get the package?
No one else has mentioned it, but you have to load the CPAN config first:
use CPAN;
CPAN::HandleConfig->load;
CPAN::Shell::setup_output;
CPAN::Index->reload;
# now do your stuff
You can also look at the cpan(1) script that comes with CPAN.pm to see a lot of the programmer's interface in action. I also wrote on article for the latest issue of The Perl Review showing examples of the programmer's interface to CPAN.pm.
However, you might not need to do any of this. Why is your program downloading modules on its own? Are you trying to create a distribution that has dependencies? There are better ways to handle that so you don't have to repeat the work that's already done in other tools. For instance, see my article Creating Perl Application Distributions. You treat your program as if it's a module and get the benefit of all the cool module tools so you don't have to reinvent something.
If you tell us more about the problem that you're actually trying to solve, we might have other good answers too. :)
Good luck,
the perldoc page on CPAN.pm confuses the hell out of me.
Yes, documentation of the CPAN API is still a bit lacking. It wasn't every really designed for programmatic use by others. You might have better luck with CPANPLUS, if that's available to you.
My program needs to download a couple of modules if they don't already exist. Is this basically just: CPAN::Shell->install("Module::Name::Here");
Yes, that's pretty much it for the simplest possible thing. In fact, that's pretty much all the 'cpan' command line program does when you type "cpan Module::Name::Here". However, you will need to have CPAN.pm configured in advance.
Does that download the package, unarchive it, and install it?
Yes, all three.
I would like it to make sure it doesn't try to re-install anything if the package is already there - is this the default behavior of the function or no?
Yes, the default behavior is not to install anything if the module is up to date. You can actually check that yourself with the "uptodate()" method like this:
my $mod = CPAN::Shell->expand("Module", "Module::Name::Here");
$mod->install unless $mod->uptodate;
And how can I tell if Perl couldn't connect to CPAN to get the package?
That's hard to do programmatically in a way that would be simple to explain. You either need to look at the output or else just check $mod->uptodate afterwards;
my $mod = CPAN::Shell->expand("Module", "Module::Name::Here");
if ( ! $mod->uptodate ) {
$mod->install;
die "Problems installing" unless $mod->uptodate;
}
Best of luck!
Basically using CPAN is the following:
perl -MCPAN -e shell
if this is the first time you are running it, it will ask you a few questions and save the results in a configuration file.
then to install PGP::Sign just type:
install PGP::Sign
and you're set.
As for you last question, don't worry, it will say to you whether it can connect or not.
As you can tell, most of us use only use CPAN.pm in the interactive mode, however, you're on the right track.
Things I can point out for the moment:
Yes, calling CPAN::Shell->install() will download, compile, test and install a package. It should also do the same for any dependencies the package has, recursively.
The default behaviour is to not install anything which is already installed (unless a newer version is available).
I'm not strictly sure how the error handling works - I'll look into it, and report back.
It might prompt your user, though.
Keltia has it right. I'll add that his first instruction is done from the command prompt, usually as root, but not necessarily so. The second command is done from the CPAN prompt. You can also do it all on the command line, but I usually don't.
If you're using windows, your best bet is to use PPM, but its repositories are annoyingly out of date most times.
I need to create a Zip archive after filtering the list of files I want to include. Preferably I'd like the module to work in both Windows and Linux.
Since I need to filter the list of files, I don't really want to to use an external program. I'd rather not introduce external dependencies either so I can compile the script into a single executable on Windows (using ActiveState PDK).
What I already tried
Until now I've used Archive::Zip found on CPAN but it has a major bug on Windows machine that use non-ASCII filenames: the filenames get corrupted in the archive as they don't get translated into unicode.
There is a bug report filed for that but it hasn't been updated in over 10 months and in the module documentation the developer is rather unhelpful (of the "fix your computer or get rid of Windows" kind).
Update:
Thanks to the clarifications from brian and Alan Haggai Alavi it seems that enough love is being put in Archive::Zip to get these bugs out soon and finally have a fully functioning zip module in Windows.
Although the module documentation says some stupid things about Windows, the current maintainer is Adam Kennedy, the same guy who brought you Strawberry Perl. He's definitely not anti-Windows. He released a version October, so they are working on it. There's also an open grant from The Perl Foundation to fix Archive::Extract bugs.The bug you mention, RT 35334: Filename Encoding by Archive::Zip, maybe just needs someone to show it some love. That could be you. People solve the problems that bother them, so maybe nobody interested in the module needs this just yet.
The module has had problems, and I've been following its progress since I use it in a couple projects. It has gotten a lot better recently and can certainly use some love. Sometimes open source means helping to fix the problems that you encounter. I know this doesn't help you solve your problem immediately, but that's how I think you're going to get this done aside from system() calls.
The above said bug has been solved very lately by the addition of Unicode filename support under Windows. A release featuring the fix will be available in CPAN within a week.
You could try the standard-distribution Archive::Extract. It may not be any better than Archive::Zip, but the documentation says that, if there are problems, it goes under the hood to try to use command-line tools on your system to unzip the file. This is probably most robust on Unix, but Windows has a zip archive utility, and it should be accessible via the command line. Plus, Archive::Extract can handle many other types of compression (theoretically).
Of course, it may turn out that Archive::Extract simply figures out what kind of compression the file uses and then passes it to the appropriate other library, which might be Archive::Zip.
You might also try IO::Uncompress::Unzip and it's counterpart, IO::Compress::Zip, for just unzipping, reading, and rezipping. If absolutely necessary. Again, I don't know how much better these will work, but they are all part of the standard library.
I need to do some quick-and-dirty Perl GUI building. I can't afford a Komodo License.
What would people recommend as a free (as in beer) alternative. I don't care if it is UNIX or Windows or both. I would be using either Win32 Perl or Perl/Tk depending on what has the best solution. I would also look at any PM's that use something else.
For Perl/Tk, there is ZooZ.
Personally, I prefer to use Glade for the GUI design and Gtk2::GladeXML. And as other people mentioned, there's also WxWidget and Qt alternatives.
The Perlmonks post http://www.perlmonks.org/?node_id=627282 might help, as well as the google search for "perl gui builder". Once you see what's available, you might be able to ask a more specific question to get a better answer.
Good luck, :)