a *very* odd question especially for me. Janina Sajka <janina at rednote.net> wrote

[Janina Sajka]

Thanks for the great post, Martin.


I agree with you that finding just the commands one needs to solve some
particular problem niggling one's mind is the way to learn to script.
The TLDP bash guide I cited is good, but rather dry and dull when
compared to solving a real world issue. After all, it rather formally
begins with stdio and stderr, not all the useful to manage the shopping
list, I think!

I've responded, therefore, to offer two additional strategies I employ
when solving some problem in scripting. Because I, too, prefer the
solving problems approach over the formal study approach.

I often start with, or use early on, another TLDP document, Mendel
Cooper's  "Advanced BASH Scripting Guide:"

http://tldp.org/LDP/abs/html/

I find simply trolling the Table of Contents suggests coding approaches
that may be useful. I usually find the early explanations and examples
all I really need.

The second approach I've found very fruitful is googling with the word
"bash" and some key phrases for the kind of thing I'm trying to do, or
the kind of error I'm encountering. There's lots of useful discussion
archived and available on line.

I love scripting. It's fun, and it solves problems for me.

Janina

martin McCormick writes:
> > Some responses below in line ...
> > 
> > > On Thu, 23 Jul 2015, Karen Lewellen wrote:
> > > How scriptable is Linux?
> > 
> > Eminently scriptable. You can script in any Linux shell. I recommend 
> > bash. You need to learn how to use a text editor like emacs or vim.
> > 
> > Then, start your bash scripting education with:
> > http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html
> 
> 	Good advice though I am not familiar specifically with
> that site but the neat thing about Linux and unix in general is
> that the experience is much like I always imagined that someone
> might feel were they to discover that they were the heir to a
> vast fortune and they could do anything they wanted with the
> riches. Unlike gold or gyms, however, you don't spend the
> fortune. It is all about potential. That's what tools do for one.
> To use another analogy, the tools one finds in unix are the
> shoulders of the giants that Isaac Newton referred to when he made
> the comments that the great discoveries he made were possible
> because he had stood on the shoulders of giants.
> 
> 	On the practical side, we all have big dreams. I noticed,
> here, the discussion of intrusion detection, basically an alarm
> system plus ways to collaboratively produce music, both of which
> have been done by various groups of people, proving it can be
> done.
> 
> 	When I first started working in computing in 1989, I had
> been doing about ten years worth of playing with computing before
> that. I never majored in Computer Science in college but have
> always been interested in how things work and what one can do
> with various tools. A fair question to always ask is, "What else
> can it do?" Just talking about shell scripting is enough fodder
> for a book, career or maybe even a PHD thesis not to mention
> countless labor-saving applications you can write to solve
> specific problems, etc.
> 
> 	When I started working full-time in March of 1990, my
> boss told me that she wanted me to learn unix and C and come up
> with all the automation I could for our group. I worked on that
> for 25 years, never fully learned C but could certainly write
> programs that worked and I made a lot of automation that they are
> still using even after I have retired.
> 
> 	Another thing she told me was to get started by thinking
> of one specific problem to solve that would make life much easier
> for us and concentrate just on that one thing.
> 
> 	That was excellent advice because if you fling off in all
> directions at once, you'll get nothing done, think you are a
> failure, take drugs and dive in to wet cement which is the reason
> for the concrete advice.
> 
> 	Think of something simple such as the way you manage a
> grocery list or keep track of your budget, whatever interests
> you, and see if you can simplify the donkey work in a little
> shell script. Chances are excellent it won't work right but might
> tease you by almost working if you could only get X, Y, or Z, to
> happen or not happen.
> 
> 	You lookup documentation and see why the command you are
> using is blowing up in the way that it is and then try to fix the
> problem with more or better scripting.
> 
> 	This is as specific as I can get with a general topic,
> but this is how you turn a dream in to a reality on the computer,
> many times. You may actually go from a dream to a full nightmare
> first, but you are learning all the way.
> 
> 	In case anybody cares, before I worked in computing, I
> was a repair technician with Oklahoma State University's Audio
> Visual department. I can tell you all kinds of now useless
> knowledge about 16-millimeter sound film projectors and many
> other classroom gadgets they don't use any more these days.
> 
> 	To answer another question, folks who are blind can
> usually tell if a film projector is working correctly because
> many of the nasty things that happen to the picture make
> mechanical sounds that a properly-working projecter should not
> make.
> 
> 	I was going to be a vocational teacher. That job path did
> not pan out but the computing path materialized out of nothing
> and turned out to be a lot of fun.
> 
> Martin
> 
> _______________________________________________
> Blinux-list mailing list
> Blinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/blinux-list

-- 

Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina at asterisk.rednote.net
		Email:	janina at rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats	http://www.w3.org/wai/pf