I'm trying to automate input into a command line C program (which I have no control over), it takes arguments, runs some processor intensive code (read takes a minute), then prompts to fill out form like information. I'm not sure what the best way to Input into the prompts once they become available. Are there any CPAN libraries which make this easier? How should I go about this? To clarify I'm trying to wrap this program as a library. Kind of like how Git::Wrapper Wraps git.
Without knowing more about the program you're trying to automate, I'd suggest you start by looking at Expect. It's also possible to do this with IPC::Run's start, pump, and finish functions, but Expect is a higher-level module. (And for a really low-level module, there's IPC::Open3 in core.)
Related
I have a interactive perl shell script that asks the user for some input and accordingly with his choice the script returns another set of options to choose from.
Now, soon I will have a demand to create a web interface for it. No more black terminals with blinking prompt for our users.
I was wondering what is the best way to pull this off with minimum changes to the original script? How to keep the script running and wait for user input? What is the best way to send user input to the script and then return it?
Or should I refactor the script to use CGI? I want to hear some general direction that I should take. I already know just the basic of Perl and CGI.
If you are using CGI these days you might as well be using something modern and fast like Plack. Since Plack will wrap a CGI style application you can even use a CGI application "inside" Plack to get modern features, pluggable middleware, etc., alongside olde-fashioned 1990's traditions.
Depending on how complex your application is there's a number of small frameworks and helper modules that can make working with Plack easier. Converting a console application to use a web interface might be easier if you use something like Squatting or Kelp.
Does anyone know of a scripting language that's included with most platforms (say Mac/Windows/Linux)? I haven't been able to find one. So far javascript in web browsers or compiled java are about it. Jython comes close.
My goal is to be able to download a file from the web or portable storage and just run it, without having to install something first, or have special user permissions, or edit it, or rename it, or give it executable privilages. It would give you access to generally accepted metaphors in computing: input, output, persistent storage, time, spawning tasks, sockets, fixed and floating point math, unicode, etc. Ideally it would abstract away minutia like line endings, endianness, and yielding for other processes.
I don't want to get into why having a universal language/virtual machine is important, or at the very least, useful. I feel that we are missing a middleware above the operating system level, something like POSIX but less esoteric, and without it, we all are forced to spend a disproportionate amount of time reinventing the wheel or writing special cases. For me, availability and a complete feature set are more important than speed (which could come later).
Thanks in advance for any insights you can provide,
Zack Morris
You will be able to run carefully written sh scripts on almost all unix systems.
If you want to add Microsoft systems, then it is more difficult, but still possible to provide a single script file, that will "autodetect" the interpreter it's running on and select between a sh part and a command.com or whatever they have on Microsoft systems.
Once you can run a script on a known system you can further download or unpack and install automatically whatever software you need.
i am new in linux and using ubuntu'10.10'...i basically want to know as what is the significance of learning shell....????...i googled but max time i find tutorial but didnot get any satisfactory answers...
Whenever you want to automate small tasks where using real programming languages is overkill (e.g. batch convert files, rip DVD chapters, synchronize directories, ...) shell scripts often are invaluable.
Moreover, a lot of "plumbing" in the system is done with shell scripts (e.g. daemons start/stop scripts, event scripts), so knowing at least how to read them often can give you a grasp on how some parts of the system work under the hood, and give you a clue about where the problem can lie in case of malfunctions; knowing how to write them can also be useful if you need to customize the system in some way.
That is a nice question to ask. The fact is that studying shell script help you to do a lot of tasks, (well it helped me ). I used shell script whenever i had to perform more than one Linux commands one by one and sometimes when I had to run jobs over and over again with same pattern. Shell really helps in doing such tasks.
And off the syllabus, studying shell for tasks made me more familiar with the OS and commands.
For learning purposes i'm developing a Class generation application in c# and winforms. I think It could be fine to include a command-line mode that allow to use the application in scripts.
It's a good practice to include a command-line mode in my applications? It would be better to have two different programs, one with GUI in one for the command-line?
Actually having a C# application be both console and GUI is problematic. Console applications (/t:exe) are launched and then the command prompt waits for them to finish. GUI applications (/t:winexe) the command shell launches them and then returns immediately. While you can create and run forms from a 'console' application, it will always have a background console displayed. On the other hand 'Forms' application don't have the stdin, stdout and stderr connected and, while they can behave as command line tools and process command arguments, they have problems when embedded in scripts (because the standard input/output is not hooked up).
If you want to expose the functionality from both GUI driven applications and scriptable/pipe-able batch processing too the best way is to compile your functionality into a class library, then built two separate applications (one GUI one console) that leverage that library.
I'm not a C# programmer, but when I program in C++, I find it most useful to:
1.) Create both a shared library with a C as well as C++ API for performing core app functionality.
2.) Create one or more commandline binaries accessible to the shell interpreter.
3.) Create a GUI application for typical end users, implemented with the library (not by invoking the binaries).
This separates the logic of the application from the interface to the application, and enables thirdparty developers to create alternative interfaces for the same application functionality. It also makes it easy to script, while at the same time catering to typical end users who want a nice, shiny GUI.
Yes. If you think the program will be useful in a scripted environment then include a command line mode (without UI) so it can be used in scripts.
It doesn't have to be a separate application, but it can be. Whether you want to do that or not is entirely up to you. I'd imagine that if you had two applications they'd share the same logic assemblies but the interface (one a GUI the other a command line) would just be different.
I agree with michaelsafyan about creating a library with core functionality.
What I would add is that you should check out powershell cmdlets as well.
Much command line activity will be migrating to powershell and it brings a lot to the table.
http://en.wikipedia.org/wiki/Windows_PowerShell
I very often create such a utility as an API. If I need to use it from a simple command-line utility, that's easy - it just calls the API. If the command-line gets too complex, maybe it's time for a Winforms application - which can also call the API. If I wanted to use it from PowerShell, or from an MSBUILD task, those are still easy - they just call the API.
Creating an application on the windows platform that behaves correctly as a console application can be problematic it's an issue with the windows kernel architecture as they're considered two different types of application (they have a different subsystem that you generally specify in the compiler or linker options). You can still manually redirect the IO and open a console from a win32 application by the win32 function AllocConsole() and friends but this also has some issues. See This Old New Thing post for more information.
If you want your utility/prgram run in scripts you can expose it as COM.
Many script languages for windows had the hability to use COM objects directly.
You should include a command line interface in your application,
if it enhances usability and comfort.
For instance, calling a CLI command might be faster then starting the GUI, navigating through several menu layers to reach the same functionality.
You might ask the users of your application, if they would find it useful to have a CLI mode.
Some words on marrying CLI & GUI on Windows:
A windows application is either a GUI application or a Console application, but not both. This is an OS issue and there is probably nothing one can do about it.
The console subsystem in Windows is horrible and PowerShell didn't change that.
Your implementation options on Windows are:
the two files approach:
Provide two files: one .com with console, one .exe with GUI.
Because of the executable probing on the command line, the com file will get executed before the exe.
the console flickering approach:
Compile your GUI application with console mode on, then immediately after the start of the GUI you might call FreeConsole() to close it.
It's a bit annoying, but works. Bad: now you have a flickering console window. Pro: still one file.
I agree with #Remus Rusanu.
you should create a class library of your core functionality and then build GUI app(wrapper) for that.
and one other benefit of it is you might not even need to create a command line app as you can access your .net dll features using powershell..
you can find one example over here
Another great idea is to embed a scripting language. Then your program can be controlled by a script, and you get all the logic, branching, etc from the scripting language "for free."
There are many choices of what you can embed. Lua is one of the most popular and intended for just that purpose and is an excellent choice.
However, for a general purpose app, I'd take a hard look at embedding Python. Python is so popular, you'd have a larger group of people willing to take the effort to write a script for your app.
I package our server releases into zip files using a batch file (Windows), running the command-line version of WinZip. Previously we did this sort of thing "by hand" but I developed the process of automating it with a batch file.
The batch file has become quite complicated because our product is complicated (i.e., Which sections are we releasing this time? Are we releasing the config files as well?) and I'm starting to run into some frustrating limitations with batch files.
Would PowerShell be a good thing to investigate as an "upgrade" to the batch file? Or is that complete overkill given that most of what it would be doing is firing off DOS commands?
Bonus: can PowerShell consume .NET assemblies? As in, could I start doing the zipping with SharpZip?
If you have a working solution, then you don't need to go to powershell. Having said that, if you plan to make changes or improve the process then I would highly recommend powershell as the way to go. Powershell can access .Net assemblies...mostly. Some assemblies are structured in a way that makes it more difficult than others.
You can check here for some resources if you decide to look at powershell.
Initially I was really excited about PowerShell. Finally a powerful native shell on Windows. However, I quickly realized that compared to your favorite unix shell PowerShell is just way too verbose. Even doing simple stuff takes way too much typing compared to what you can do with bash and GNU tools for Win32.
I like the idea, that the shell knows about different types, but if I need to do that much additional work, I prefer just getting the necessary data with the various unix stream editors.
EDIT: I just had another look at PowerShell, and I have to admit, that it does have some really useful features that are not available for the traditional unix style tools.
For one the PowerShell owns all the commands which means that it can provide a much more coherent set of features. Parameters are treated uniformly, you can search for commands, parameters and so forth using wild cards which is really useful.
The second great feature is that PowerShell lets you enumerate sources which are normally not available to stream editors such as the Windows registry, the certificate store and so forth. Of course you can have tools that does this for you and present it as text, but the PowerShell approach is just really elegant IMO.
Take a look at PowerShell Community Extensions (PSCX), its FREE and it has Zip cmdlets:
Write-Zip
Write-BZip2
Write-GZip
http://www.codeplex.com/PowerShellCX
You should watch this presentation/discussion with Jeffrey Snover, PowerShell creator and architect. If you're not amazed by the technical details (lots of "wow" moments to be had), you'll be amazed by Jeffrey's enthusiasm :). Once you get the basics, it's easy to be very productive with PowerShell.
The answer is YES - PowerShell can use .NET assemblies. There is a bit of funny business involved in v1 if you need to wire up delegates and v2 makes that much more clean.
Just call LoadFile / LoadAssembly to get the appropriate libraries in memory and away you go
[Reflection.Assembly]::LoadFile('/path/to/sharpzip.dll')
$zip = new-object ICSharpCode.SharpZipLib.Zip.FastZip
$zip.CreateZip('C:\Sample.zip', 'C:\BuildFiles\', 'true', '^au')
# note - I didn't actually test this code
# I don't have SharpZip downloaded - just read their reference.
Also note that the PowerShell Community Extensions support various compression methods like write-zip.
I've tried to replace one of the lengthy build batch files I use with power shell. I found it a pain: at least at that time, documentation focused on the funny verbiage and what cool, perly things you can do with it, but lacked in the "getting simple things done" category. I got it working, but the error handling was to shaky.
YMMV, try powershell, you might enjoy it. But try it before updating your build batches.
My solution: use a C# console application. I've got serious logging, exception handling, can use my utility functions, and if something doesn't work I have a real debugger. It's the first solution I like to modify.
I'm not sure about powershell, but might I recommend using something like IronPython (if you want to have access to the .NET libraries) or plain python? You get a full-blown programming language with very few limitations.
On the one hand, if it works, just leave it. But it sounds like this is something you'll be adding to over time, and of course your eventual successor/coworker who needs to edit the batch file will also need to understand it. If you're from a programming background then you may well find the power of Powershell makes your script a lot shorter and easier to read/maintain (for example, even just having full if statements and for/while loops). On the other hand if you're not overly familiar with programming, a lot of people find Powershell a bit daunting at first glance.
Regarding the .NET part, Powershell is built on top of .NET so yes, you can access .NET assemblies (but you should always see if there's a cmdlet available first).
I would recommend a book called "The Powershell Cookbook" by Lee Holmes, published by O'Reilly. It provides "recipes" which you can use for common tasks; this will probably speed up your time to implement the script, and it'll teach you Powershell along the way.