As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is still worth learning expect? Because I have not seen any new books on this topic? What would anyone recommend for a good book on this?
expect is best used for controlling scripts that output queries and require a response. Many other languages struggle with this and create deadlocks on stdin/stdout when trying to use both. Expect also overcomes some issues with password entry (like when scripting SSH).
Having said that it isn't necessary to know expect because many other languages have an expect module (tcl and python come to mind) which provide the same behaviour.
I would have to say it depends on your job. If you spend a lot of time interacting with repetitive commandline scripts or FTP then expect is well worth adding to your scripting arsenal.
SpliFF wrote above about "... interacting with repetitive commandline script or FTP ..." While I'm all for automation, and regard Expect as indispensable, Expect is NOT necessary in 2010 for FTP or many other roles where it once was necessary. Fifteen years ago, for example, Expect was an appropriate way to automate FTP; now, most scripting languages already build in capabilities sufficient to replace Expect's use with FTP. Many, many automations can be done with what Perl, Python, Tcl, ... already build in, and Expect is not essential for these applications.
It never hurts to have another tool in your kit. Expect really does fill its niche extremely well.
The quintessential Expect book is Exploring Expect. It's the only Expect book you need.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
We all know that Puppet and Chef are the superstars of the IT automation area, and they are developed in Ruby (though Chef 11 server was rewritten in Erlang).
In my working environment, a very large group of the operations team uses Python as the primary language to develop operation tools or basic system applications.
I want to find why both Puppet and Chef were written in Ruby? What are the advantages? Ruby supports DSLs well. Can Python do such thing?
From Luke Kanies, Puppet’s author:
I was a sysadmin by trade and had mostly developed in perl, but when I
tried to write the prototype I had in mind, I couldn’t get the class
relationships I wanted in perl. I tried Python, because this was
around 2003 and Python was the next new thing and everyone was saying
how great it is, but I just can’t seem to write in Python at all. A
friend had said he’d heard Ruby was cool, so I gave it a try, and in
four hours I went from never having seen a line of it to having a
working prototype. I haven’t looked back since then, and haven’t
regretted the choice.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I would like to learn some scripting to help automate some common tasks. Is ruby a good language to learn for this and what gems will be useful?
I would like to make scripts similar to this bash script
http://nikhgupta.com/code/initialize-gitolite-bash-script/
Which automates setting up a new gitolite repo.
Would you just learn bash, sed grep etc?
Sounds like a job for Ruby and Rake! Check this out.
In my opinion, Python and Ruby are the best languages out there, when it comes to automating tasks in *NIX systems. Being a Windows buff, I'd stick to PowerShell..
For Linux/Unix administration good shell scripting skills is essential. For more advanced automation, it is also good to know python, perl, or ruby. It really doesn't matter which you choose. Once you have become proficient with one, you will find that picking up the others to be an easy task.
Personally, ruby's package management system (gems) has always turned be off from using it from a scripting platform. Others hold different opinions and like it.
Pick one and dive in.
Some years ago I would have recommended to use PERL for things like that.
In my opinion it's always a good idea to have some base knowledge of shell scripting but if you really want to do something "bigger" use a script language (like Python, Ruby or Perl).
In meantime I see no reason to not use ruby for things like that. I really enjoy this language and you can do everything (?) that you could do in PERL in ruby as well (and you will have a real OO language at hand).
CPAN on the other hand is a quite nice argument to use PERL. Ruby gems are similar but I don't think there are that many gems as CPAN-modules available. But please compare by yourself (http://rubygems.org/).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
In what ways are scripting languages (especially bash) is used to manage large C++/C programming projects?
It will be helpful if someone can list some clever uses of scripts in their programming projects at automating certain tasks.
I personally used shell scripting to invoke my program multiple times for different inputs, for loading the necessary modules before I try to run my program, for automatic graph plotting with gnuplot etc. When I was working on huge clusters I also found a script very useful when I had to set/query some runtime settings to launch my tasks on the cluster. I always use GNU Make to build my programs, but if you have extremely small non-critical projects, you can use scripts to even build your code.
I am sure that there are a lot of other innovative ways to use bash scripts, but whatever I just said is from the perspective of an ordinary developer who does a lot of (almost) mundane stuff everyday. And bash scripts have made my life a lot easier, to say the least.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm digging around trying to find a good set of tools for creating console applications, as most of the settings I expect to be using Ruby in the coming months won't be webapps, but server-side scripts.
I know of highline, and I do plan on using that for user and possible password prompts, but I know that the Console application world should be chock-full of other gems to assist and/or enrich your plain 'ol command-line apps.
Does anyone have some good suggestions? I'm not exactly sure what I'm really looking for, but I wouldn't be surprised if there were gems in Ruby to help with colorizing, ascii-like art, user-interaction (similar to bash-completion), man-page similar tools (or generators) or just helpers for making the work of creating a richer console app not come across as being so difficult to understand, or plain and cryptic.
Here's some console related gems I've written you may like:
bond - Custom readline autocompletion of methods, arguments and more.
hirb - Framework for formatting ruby objects. Comes with tables, trees, selection menus and a smart pager.
alias - Creates, manages and saves aliases for class methods, instance methods, constants, delegated methods.
My table_print gem lets you see IRB output in easy-to-scan table format. Super simple, lightweight, customizable. http://tableprintgem.com
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I've recently began using dTrace and have noticed just how awesome it is. Its the perfect tool for profiling without placing the burden on programmers to set up hundreds of probes in their applications.
I've found some nice one liner and sample scripts here and there, but I was wondering about what scripts, tools and links others might want to share.
BTW Anybody tried Chimes?
Here are some links I've found useful
A Powerpoint presentation about dTrace:
http://www.nbl.fi/~nbl97/solaris/dtrace/dtt_present.pdf
200+ useful scripts:
http://www.brendangregg.com/
I attended Theo Schlossnagle's Full Stack Introspection Crash Course talk at OSCON this year. In that presentation he gives several examples of using the D-Trace language and at the above link there are some additional utilities.
It's worth noting that because of the differences in Apple's and Sun's implementations, dtrace scripts from Solaris may not (likely won't) work on Leopard, and vice-versa. I'm not sure about FreeBSD's version.
The main problem is a different set of probes made available by the OS. Sometimes the probes will be provided under a different name. Sometimes they'll be more or less specific from one OS to another. Just a gotcha in case you come across a script that, for some reason, won't work.
Unfortunately dTrace is only implemented in/for Solaris OS. People from sun are recommend me to port all my php applications to Solaris, and "dtrace" them. After optimizing to again port them on my previous OS.