Softpanorama

Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)

Best books about Bash and Korn Shell

News

Selected Computer Books

Best Introductory Books

Best Intermediate Books

Best Advanced Books

 Reference

Classic Computer Books Classic Unix books Best Books about Unix Tools Best Red Hat Books for Preparation to Certification Humor Etc

Introduction

Unix shells such as bash 4.x are far from being simple and to find a good book on later version of bash(say 3.0 and up) is very difficult.  also such notion as the best book depends on your background.  So there is no single "best" book on shell for any level, be it introductory, intermediate or advanced. People with different background can benefit most from different books. In any case you need several, because the first one might be far from optimal for you and your level of technical sophistication in bash and Unix. Still some general recommendations apply.

Bash and ksh93 are burdened by legacy of 30 years development and mistakes made of early stages of development of such shells as Bourne shell (with its numerous warts and complete absence of the lexical level of the language). Still they are very important members of scripting languages family and newer scripting languages such as Perl, Python and Ruby still are unable to displaced them.

Bash is widely used in Unix/Linux environment and leaning programming in it it is a must language for any system administrator who respects himself/herself. Bourne shell and C-shell also influenced the creation of more modern scripting languages such as Perl.   One recommendation is to keep your Bash scripts short. If the  script exceeds, say, 300 lines, consider rewriting it in Perl, or other scripting language (Python or Ruby, if you know them well).   That does not mean that long Bash script are a problem. But you need strict coding discipline to make them maintainable.

Only few books treat bash as a programming language. Among  them only three definitely worth  exploring (assuming  that you are a sysadmin, who need to write small and medium size scripts):

In a way shells are  underestimated members of the scripting language family. They still are higher level languages then any other scripting language. Moreover ksh93 and  zsh are in some respects (coroutines and operations with pipes is one example) more modern and powerful then Perl.  On the negative side they suffer from bizarre syntax, absence of lexical level,  fuzzy semantic and, first of all, the huge burden of compatibility with older versions. 

Due to this situation it is very difficult, almost impossible to write a good shell book. That's probably why there very few of them.  Most shell books are "pulp fiction" where the author just repeat basic syntax information with few examples of usage without touching more complex issues of shell integration into Unix and its role in Unix way of thinking.

Also development of shells is very uneven. For example Bash 3.2 and later versions are still weaker that ksh93 as a scripting language (but in any case in Linux writing complex scripts moved to Perl), but is a much better interactive shell. It is also standard de facto on Linux, where it completely displaced ksh93 (I think only Oracle still using it in its scripts).  I would like to stress again, that being superior scripting language for more-or-less complex scripts Perl is now competing with shell (both bash and ksh93). Perl interpreter now is available by default in all major version of Linux and Unix. As loading time of modern servers of Perl interpreter became negligible; so it is gradually displacing AWK for one liners. It is simpler to know one language instead of two. 

One important advantage of bash that is has a downloadable debugger which is a nice thing and an improvement in the right direction.

You need several books, not one

If you want to learn shell programming, not just writing  scripts that contain less then a dozen lines, you need several books on the subject as well as study available with OS example of shell programming. 

Various books stresses different aspects of the language and  complex issues of interaction with classic shell utilities  such as grep, sed, awk, vi, find, etc are best covered  in books different then those that cover the language on introductory or intermediate level.

For example a simple question of environment inheritance that is important for writing complex scripts. Or string processing capabilities of shell (see also String Operations in Shell ) or nuances shell arithmetic operations ( ((..)) operation . BTW most shells ( ksh93 is an exception) operate only with integers. See also Arithmetic Expressions in BASH)

See also my Unix Shells page.

Best Introductory Books

Among introductory I would say that one of the few that is worth the money is Unix Shell Programming, Third Edition by Stephen Kochan & Patrick Wood.  It  should probably be used with Bash Cookbook: while presentation of key topics is adequate, they lack good, practical examples, the examples which can be found in Bash Cookbook

Many introductory shell books that try cover both ksh and C shell end with covering none well. One exception (for Solaris users only) is probably A Practical Guide to Solaris  which managed to have weak coverage of three shells (and that's a rather strange idea to cover all three in the intro book) but as a compensation contains a good coverage of  grep, sed and awk -- very useful utilities for shell scripting. 

Another, more recent, but still decent intro book is Linux Command Line and Shell Scripting Bible

This is an average or slightly above average introductory book, oriented on newcomers to shell scripting. Looks like the author just added (( )) type of arithmetic expressions as a afterthought, while it should be taught as a primary construct. Similar situation with C-style loop available now in bash as well. One of the few books on shell scripting published after 2005.  Unix Shell Programming, Third Edition by Stephen Kochan & Patrick Wood is a much better book. For everybody but absolute beginners, Classic Shell Scripting (May 1, 2005) might also be a better book, although it belong to intermediate level.  But this is definitely a good alternative to Sobel's A Practical Guide to Linux Commands, Editors, and Shell Programming (3rd Edition) published in 2012.
BTW it somebody pretend to write a scripting bible he/she should be a scripting god. Neither author qualifies ; -).  They are pretty average run of the mill instructors. 
Notable quotes:
"... It has one of the best explanations for sed and gawk I have ever seen. ..."

You can also use introductory Linux book such as "average" quality books by Sobel. for example A Practical Guide to Fedora and Red Hat Enterprise Linux (7th Edition) which as of November 2015 costs around $11 used (not a bad price for 1300 pages ;-).

Best Intermediate Books

The litmus test on intermediate book is the level of pipes/redirection and coroutines coverage as well as coverage on Unix signals and exec.  There are two intermediate book that I can recommend:

  1. Classic Shell Scripting by Arnold Robbins, Nelson H.F. Beebe

    This is a great intermediate book on shell scripting. See my review Classic Shell Scripting. Can serve as a valuable add on to "Learning Korn shell" from O'Reilly (1st edition) -- which is also a very strong book on shell scripting.

    The authors provide a lot of interesting and useful information that is difficult to find in other books. They devoted Ch 5 to piping and in 5.4 "Word List" they discuss famous Doug McIlroy alternative solution to Donald Knuth program of creating the list of the n most-frequent words, with counts of their frequency of occurrence, sorted by descending count from an arbitrary text file.

    The authors discuss many Unix tools that are used with shell (Unix toolbox). They provide a very good (but too brief) discussion of grep and find. Discussion of xargs (which is usually a sign on a good book on scripting) includes /dev/null trick, but unfortunately they do not mention an option -0n with which this trick makes the most sense.

    One of the best chapters of the book is Ch. 13 devoted to process control. Also good is Chapter 11 that provides a solution to pretty complex and practically important for many system administrators task of merging passwd files in Unix. It provides a perfect insight into solving real sysadmins problems using AWK and shell.

    Shortcomings are few. in "5.2. Structured Data for the Web" the authors should probably list AWK instead of SED. Also XML processing generally requires using a lexical analyzer, not regular expressions. Therefore a tag list example would be better converted to something simpler, for example generating C-tags for vi.

  2. Linux Shell Scripting with Bash by Ken O. Burtch (2004)
  3. Learning the Korn Shell (1nd Edition) is another good intermediate book, but the content is somewhat outdates. It still has value for those who already have some exposure to Unix (the second edition is OK too, but I like the first edition better). BTW ksh93 source code was released on March 1, 2000 so from this point this is an open source shell. For more details see the comp.os.unix.shell FAQ posting on shell comparisons.

Best Advanced Books

There are no good advanced books on shell. The only one that probably might qualify is essentially a reference book that covers the most interesting features that are present in ksh93 (especially coroutines). In this respect nothing can replace the author view on the language as in The New Kornshell : Command and Programming Language.

My Reviews

Classic Shell Scripting

Dr. Nikolai Bezroukov

 


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Apr 30, 2018] New Book Describes Bluffing Programmers in Silicon Valley

Notable quotes:
"... Live Work Work Work Die: A Journey into the Savage Heart of Silicon Valley ..."
"... Older generations called this kind of fraud "fake it 'til you make it." ..."
"... Nowadays I work 9:30-4:30 for a very good, consistent paycheck and let some other "smart person" put in 75 hours a week dealing with hiring ..."
"... It's not a "kids these days" sort of issue, it's *always* been the case that shameless, baseless self-promotion wins out over sincere skill without the self-promotion, because the people who control the money generally understand boasting more than they understand the technology. ..."
"... In the bad old days we had a hell of a lot of ridiculous restriction We must somehow made our programs to run successfully inside a RAM that was 48KB in size (yes, 48KB, not 48MB or 48GB), on a CPU with a clock speed of 1.023 MHz ..."
"... So what are the uses for that? I am curious what things people have put these to use for. ..."
"... Also, Oracle, SAP, IBM... I would never buy from them, nor use their products. I have used plenty of IBM products and they suck big time. They make software development 100 times harder than it could be. ..."
"... I have a theory that 10% of people are good at what they do. It doesn't really matter what they do, they will still be good at it, because of their nature. These are the people who invent new things, who fix things that others didn't even see as broken and who automate routine tasks or simply question and erase tasks that are not necessary. ..."
"... 10% are just causing damage. I'm not talking about terrorists and criminals. ..."
"... Programming is statistically a dead-end job. Why should anyone hone a dead-end skill that you won't be able to use for long? For whatever reason, the industry doesn't want old programmers. ..."
Apr 30, 2018 | news.slashdot.org

Long-time Slashdot reader Martin S. pointed us to this an excerpt from the new book Live Work Work Work Die: A Journey into the Savage Heart of Silicon Valley by Portland-based investigator reporter Corey Pein.

The author shares what he realized at a job recruitment fair seeking Java Legends, Python Badasses, Hadoop Heroes, "and other gratingly childish classifications describing various programming specialities.

" I wasn't the only one bluffing my way through the tech scene. Everyone was doing it, even the much-sought-after engineering talent.

I was struck by how many developers were, like myself, not really programmers , but rather this, that and the other. A great number of tech ninjas were not exactly black belts when it came to the actual onerous work of computer programming. So many of the complex, discrete tasks involved in the creation of a website or an app had been automated that it was no longer necessary to possess knowledge of software mechanics. The coder's work was rarely a craft. The apps ran on an assembly line, built with "open-source", off-the-shelf components. The most important computer commands for the ninja to master were copy and paste...

[M]any programmers who had "made it" in Silicon Valley were scrambling to promote themselves from coder to "founder". There wasn't necessarily more money to be had running a startup, and the increase in status was marginal unless one's startup attracted major investment and the right kind of press coverage. It's because the programmers knew that their own ladder to prosperity was on fire and disintegrating fast. They knew that well-paid programming jobs would also soon turn to smoke and ash, as the proliferation of learn-to-code courses around the world lowered the market value of their skills, and as advances in artificial intelligence allowed for computers to take over more of the mundane work of producing software. The programmers also knew that the fastest way to win that promotion to founder was to find some new domain that hadn't yet been automated. Every tech industry campaign designed to spur investment in the Next Big Thing -- at that time, it was the "sharing economy" -- concealed a larger programme for the transformation of society, always in a direction that favoured the investor and executive classes.

"I wasn't just changing careers and jumping on the 'learn to code' bandwagon," he writes at one point. "I was being steadily indoctrinated in a specious ideology."


Anonymous Coward , Saturday April 28, 2018 @11:40PM ( #56522045 )

older generations already had a term for this ( Score: 5 , Interesting)

Older generations called this kind of fraud "fake it 'til you make it."

raymorris ( 2726007 ) , Sunday April 29, 2018 @02:05AM ( #56522343 ) Journal
The people who are smarter won't ( Score: 5 , Informative)

> The people can do both are smart enough to build their own company and compete with you.

Been there, done that. Learned a few lessons. Nowadays I work 9:30-4:30 for a very good, consistent paycheck and let some other "smart person" put in 75 hours a week dealing with hiring, managing people, corporate strategy, staying up on the competition, figuring out tax changes each year and getting taxes filed six times each year, the various state and local requirements, legal changes, contract hassles, etc, while hoping the company makes money this month so they can take a paycheck and lay their rent.

I learned that I'm good at creating software systems and I enjoy it. I don't enjoy all-nighters, partners being dickheads trying to pull out of a contract, or any of a thousand other things related to running a start-up business. I really enjoy a consistent, six-figure compensation package too.

brian.stinar ( 1104135 ) writes:
Re: ( Score: 2 )

* getting taxes filled eighteen times a year.

I pay monthly gross receipts tax (12), quarterly withholdings (4) and a corporate (1) and individual (1) returns. The gross receipts can vary based on the state, so I can see how six times a year would be the minimum.

Cederic ( 9623 ) writes:
Re: ( Score: 2 )

Fuck no. Cost of full automation: $4m Cost of manual entry: $0 Opportunity cost of manual entry: $800/year

At worse, pay for an accountant, if you can get one that cheaply. Bear in mind talking to them incurs most of that opportunity cost anyway.

serviscope_minor ( 664417 ) writes:
Re: ( Score: 2 )

Nowadays I work 9:30-4:30 for a very good, consistent paycheck and let some other "smart person" put in 75 hours a week dealing with hiring

There's nothing wrong with not wnting to run your own business, it's not for most people, and even if it was, the numbers don't add up. But putting the scare qoutes in like that makes it sound like you have huge chip on your shoulder. Those things re just as essential to the business as your work and without them you wouldn't have the steady 9:30-4:30 with good paycheck.

raymorris ( 2726007 ) writes:
Important, and dumb. ( Score: 3 , Informative)

Of course they are important. I wouldn't have done those things if they weren't important!

I frequently have friends say things like "I love baking. I can't get enough of baking. I'm going to open a bakery.". I ask them "do you love dealing with taxes, every month? Do you love contract law? Employment law? Marketing? Accounting?" If you LOVE baking, the smart thing to do is to spend your time baking. Running a start-up business, you're not going to do much baking.

If you love marketing, employment law, taxes

raymorris ( 2726007 ) writes:
Four tips for a better job. Who has more? ( Score: 3 )

I can tell you a few things that have worked for me. I'll go in chronological order rather than priority order.

Make friends in the industry you want to be in. Referrals are a major way people get jobs.

Look at the job listings for jobs you'd like to have and see which skills a lot of companies want, but you're missing. For me that's Java. A lot companies list Java skills and I'm not particularly good with Java. Then consider learning the skills you lack, the ones a lot of job postings are looking for.

Certifi

goose-incarnated ( 1145029 ) , Sunday April 29, 2018 @02:34PM ( #56524475 ) Journal
Re: older generations already had a term for this ( Score: 5 , Insightful)
You don't understand the point of an ORM do you? I'd suggest reading why they exist

They exist because programmers value code design more than data design. ORMs are the poster-child for square-peg-round-hole solutions, which is why all ORMs choose one of three different ways of squashing hierarchical data into a relational form, all of which are crappy.

If the devs of the system (the ones choosing to use an ORM) had any competence at all they'd design their database first because in any application that uses a database the database is the most important bit, not the OO-ness or Functional-ness of the design.

Over the last few decades I've seen programs in a system come and go; a component here gets rewritten, a component there gets rewritten, but you know what? They all have to work with the same damn data.

You can more easily switch out your code for new code with new design in a new language, than you can switch change the database structure. So explain to me why it is that you think the database should be mangled to fit your OO code rather than mangling your OO code to fit the database?

cheekyboy ( 598084 ) writes:
im sick of reinventors and new frameworks ( Score: 3 )

Stick to the one thing for 10-15years. Often all this new shit doesn't do jack different to the old shit, its not faster, its not better. Every dick wants to be famous so make another damn library/tool with his own fancy name and feature, instead of enhancing an existing product.

gbjbaanb ( 229885 ) writes:
Re: ( Score: 2 )

amen to that.

Or kids who can't hack the main stuff, suddenly discover the cool new, and then they can pretend they're "learning" it, and when the going gets tough (as it always does) they can declare the tech to be pants and move to another.

hence we had so many people on the bandwagon for functional programming, then dumped it for ruby on rails, then dumped that for Node.js, not sure what they're on at currently, probably back to asp.net.

Greyfox ( 87712 ) writes:
Re: ( Score: 2 )

How much code do you have to reuse before you're not really programming anymore? When I started in this business, it was reasonably possible that you could end up on a project that didn't particularly have much (or any) of an operating system. They taught you assembly language and the process by which the system boots up, but I think if I were to ask most of the programmers where I work, they wouldn't be able to explain how all that works...

djinn6 ( 1868030 ) writes:
Re: ( Score: 2 )
It really feels like if you know what you're doing it should be possible to build a team of actually good programmers and put everyone else out of business by actually meeting your deliverables, but no one has yet. I wonder why that is.

You mean Amazon, Google, Facebook and the like? People may not always like what they do, but they manage to get things done and make plenty of money in the process. The problem for a lot of other businesses is not having a way to identify and promote actually good programmers. In your example, you could've spent 10 minutes fixing their query and saved them days of headache, but how much recognition will you actually get? Where is your motivation to help them?

Junta ( 36770 ) writes:
Re: ( Score: 2 )

It's not a "kids these days" sort of issue, it's *always* been the case that shameless, baseless self-promotion wins out over sincere skill without the self-promotion, because the people who control the money generally understand boasting more than they understand the technology. Yes it can happen that baseless boasts can be called out over time by a large enough mass of feedback from competent peers, but it takes a *lot* to overcome the tendency for them to have faith in the boasts.

It does correlate stron

cheekyboy ( 598084 ) writes:
Re: ( Score: 2 )

And all these modern coders forget old lessons, and make shit stuff, just look at instagram windows app, what a load of garbage shit, that us old fuckers could code in 2-3 weeks.

Instagram - your app sucks, cookie cutter coders suck, no refinement, coolness. Just cheap ass shit, with limited usefulness.

Just like most of commercial software that's new - quick shit.

Oh and its obvious if your an Indian faking it, you haven't worked in 100 companies at the age of 29.

Junta ( 36770 ) writes:
Re: ( Score: 2 )

Here's another problem, if faced with a skilled team that says "this will take 6 months to do right" and a more naive team that says "oh, we can slap that together in a month", management goes with the latter. Then the security compromises occur, then the application fails due to pulling in an unvetted dependency update live into production. When the project grows to handling thousands instead of dozens of users and it starts mysteriously folding over and the dev team is at a loss, well the choice has be

molarmass192 ( 608071 ) , Sunday April 29, 2018 @02:15AM ( #56522359 ) Homepage Journal
Re:older generations already had a term for this ( Score: 5 , Interesting)

These restrictions is a large part of what makes Arduino programming "fun". If you don't plan out your memory usage, you're gonna run out of it. I cringe when I see 8MB web pages of bloated "throw in everything including the kitchen sink and the neighbor's car". Unfortunately, the careful and cautious way is a dying in favor of the throw 3rd party code at it until it does something. Of course, I don't have time to review it but I'm sure everybody else has peer reviewed it for flaws and exploits line by line.

AmiMoJo ( 196126 ) writes: < mojo@@@world3...net > on Sunday April 29, 2018 @05:15AM ( #56522597 ) Homepage Journal
Re:older generations already had a term for this ( Score: 4 , Informative)
Unfortunately, the careful and cautious way is a dying in favor of the throw 3rd party code at it until it does something.

Of course. What is the business case for making it efficient? Those massive frameworks are cached by the browser and run on the client's system, so cost you nothing and save you time to market. Efficient costs money with no real benefit to the business.

If we want to fix this, we need to make bloat have an associated cost somehow.

locketine ( 1101453 ) writes:
Re: older generations already had a term for this ( Score: 2 )

My company is dealing with the result of this mentality right now. We released the web app to the customer without performance testing and doing several majorly inefficient things to meet deadlines. Once real load was put on the application by users with non-ideal hardware and browsers, the app was infuriatingly slow. Suddenly our standard sub-40 hour workweek became a 50+ hour workweek for months while we fixed all the inefficient code and design issues.

So, while you're right that getting to market and opt

serviscope_minor ( 664417 ) writes:
Re: ( Score: 2 )

In the bad old days we had a hell of a lot of ridiculous restriction We must somehow made our programs to run successfully inside a RAM that was 48KB in size (yes, 48KB, not 48MB or 48GB), on a CPU with a clock speed of 1.023 MHz

We still have them. In fact some of the systems I've programmed have been more resource limited than the gloriously spacious 32KiB memory of the BBC model B. Take the PIC12F or 10F series. A glorious 64 bytes of RAM, max clock speed of 16MHz, but not unusual to run it 32kHz.

serviscope_minor ( 664417 ) writes:
Re: ( Score: 2 )

So what are the uses for that? I am curious what things people have put these to use for.

It's hard to determine because people don't advertise use of them at all. However, I know that my electric toothbrush uses an Epson 4 bit MCU of some description. It's got a status LED, basic NiMH batteryb charger and a PWM controller for an H Bridge. Braun sell a *lot* of electric toothbrushes. Any gadget that's smarter than a simple switch will probably have some sort of basic MCU in it. Alarm system components, sensor

tlhIngan ( 30335 ) writes:
Re: ( Score: 3 , Insightful)
b) No computer ever ran at 1.023 MHz. It was either a nice multiple of 1Mhz or maybe a multiple of 3.579545Mhz (ie. using the TV output circuit's color clock crystal to drive the CPU).

Well, it could be used to drive the TV output circuit, OR, it was used because it's a stupidly cheap high speed crystal. You have to remember except for a few frequencies, most crystals would have to be specially cut for the desired frequency. This occurs even today, where most oscillators are either 32.768kHz (real time clock

Anonymous Coward writes:
Re: ( Score: 2 , Interesting)

Yeah, nice talk. You could have stopped after the first sentence. The other AC is referring to the Commodore C64 [wikipedia.org]. The frequency has nothing to do with crystal availability but with the simple fact that everything in the C64 is synced to the TV. One clock cycle equals 8 pixels. The graphics chip and the CPU take turns accessing the RAM. The different frequencies dictated by the TV standards are the reason why the CPU in the NTSC version of the C64 runs at 1.023MHz and the PAL version at 0.985MHz.

Wraithlyn ( 133796 ) writes:
Re: ( Score: 2 )

LOL what exactly is so special about 16K RAM? https://yourlogicalfallacyis.c... [yourlogicalfallacyis.com]

I cut my teeth on a VIC20 (5K RAM), then later a C64 (which ran at 1.023MHz...)

Anonymous Coward writes:
Re: ( Score: 2 , Interesting)

Commodore 64 for the win. I worked for a company that made detection devices for the railroad, things like monitoring axle temperatures, reading the rail car ID tags. The original devices were made using Commodore 64 boards using software written by an employee at the one rail road company working with them.

The company then hired some electrical engineers to design custom boards using the 68000 chips and I was hired as the only programmer. Had to rewrite all of the code which was fine...

wierd_w ( 1375923 ) , Saturday April 28, 2018 @11:58PM ( #56522075 )
... A job fair can easily test this competency. ( Score: 4 , Interesting)

Many of these languages have an interactive interpreter. I know for a fact that Python does.

So, since job-fairs are an all day thing, and setup is already a thing for them -- set up a booth with like 4 computers at it, and an admin station. The 4 terminals have an interactive session with the interpreter of choice. Every 20min or so, have a challenge for "Solve this problem" (needs to be easy and already solved in general. Programmers hate being pimped without pay. They don't mind tests of skill, but hate being pimped. Something like "sort this array, while picking out all the prime numbers" or something.) and see who steps up. The ones that step up have confidence they can solve the problem, and you can quickly see who can do the work and who can't.

The ones that solve it, and solve it to your satisfaction, you offer a nice gig to.

ShanghaiBill ( 739463 ) , Sunday April 29, 2018 @01:50AM ( #56522321 )
Re:... A job fair can easily test this competency. ( Score: 5 , Informative)
Then you get someone good at sorting arrays while picking out prime numbers, but potentially not much else.

The point of the test is not to identify the perfect candidate, but to filter out the clearly incompetent. If you can't sort an array and write a function to identify a prime number, I certainly would not hire you. Passing the test doesn't get you a job, but it may get you an interview ... where there will be other tests.

wierd_w ( 1375923 ) writes:
Re: ( Score: 2 )

BINGO!

(I am not even a professional programmer, but I can totally perform such a trivially easy task. The example tests basic understanding of loop construction, function construction, variable use, efficient sorting, and error correction-- especially with mixed type arrays. All of these are things any programmer SHOULD now how to do, without being overly complicated, or clearly a disguised occupational problem trying to get a free solution. Like I said, programmers hate being pimped, and will be turned off

wierd_w ( 1375923 ) , Sunday April 29, 2018 @04:02AM ( #56522443 )
Re: ... A job fair can easily test this competency ( Score: 5 , Insightful)

Again, the quality applicant and the code monkey both have something the fakers do not-- Actual comprehension of what a program is, and how to create one.

As Bill points out, this is not the final exam. This is the "Oh, I see you do actually know how to program-- show me more" portion of the process. This is the part that HR drones are not capable of performing, due to Dunning-Krueger. Those that are actually, REALLY competent will do more than just satisfy the requirements of the challenge, they will provide actually working solutions to the challenge that properly validate their input, and return proper error states if the input is invalid, etc-- You can learn a LOT about a potential hire by observing their work. *THAT* is what this is really about. The triviality of the problem is a necessity, because you ***DON'T*** try to get free solutions out of people.

I realize that may be difficult for you to comprehend, but you *DON'T* do that. The job fair is to let people know that you have a position available, and try to curry interest in people to apply. A successful pre-screening is confidence building, and helps the potential hire to feel that your company is actually interested in actually hiring somebody, and not just fucking off in the booth, to cover for "failing to find somebody" and then "Getting yet another H1B". It gives them a chance to show you what they can do. That is what it is for, and what it does. It also excludes the fakers that this article is about-- The ones that can talk a good talk, but could not program a simple boolean check condition if their life depended on it.

If it were not for the time constraints of a job fair (usually only 2 days, and in that time you need to try and pre-screen as many as possible), I would suggest a tiered challenge, with progressively harder challenges, where you hand out resumes to the ones that make it to the top 3 brackets, but that is not the way the world works.

luis_a_espinal ( 1810296 ) writes:
Re: ( Score: 2 )
This in my opinion is really a waste of time. Challenges like this have to be so simple they can be done walking up to a booth are not likely to filter the "all talks" any better than a few interview questions could (imperson so the candidate can't just google it).

Tougher more involved stuff isn't good either it gives a huge advantage to the full time job hunter, the guy or gal that already has a 9-5 and a family that wants to seem them has not got time for games. We have been struggling with hiring where I work ( I do a lot of the interviews ) and these are the conclusions we have reached

You would be surprised at the number of people with impeccable-looking resumes failing at something as simple as the FizzBuzz test [codinghorror.com]

PaulRivers10 ( 4110595 ) writes:
Re: ... A job fair can easily test this competenc ( Score: 2 )

The only thing fuzzbuzz tests is "have you done fizzbuzz before"? It's a short question filled with every petty trick the author could think ti throw in there. If you haven't seen the tricks they trip you up for no reason related to your actual coding skills. Once you have seen them they're trivial and again unrelated to real work. Fizzbuzz is best passed by someone aiming to game the interview system. It passes people gaming it and trips up people who spent their time doing on the job real work.

Hognoxious ( 631665 ) writes:
Re: ( Score: 2 )
they trip you up for no reason related to your actual codung skills.

Bullshit!

luis_a_espinal ( 1810296 ) , Sunday April 29, 2018 @07:49AM ( #56522861 ) Homepage
filter the lame code monkeys ( Score: 4 , Informative)
Lame monkey tests select for lame monkeys.

A good programmer first and foremost has a clean mind. Experience suggests puzzle geeks, who excel at contrived tests, are usually sloppy thinkers.

No. Good programmers can trivially knock out any of these so-called lame monkey tests. It's lame code monkeys who can't do it. And I've seen their work. Many night shifts and weekends I've burned trying to fix their shit because they couldn't actually do any of the things behind what you call "lame monkey tests", like:

    pulling expensive invariant calculations out of loops using for loops to scan a fucking table to pull rows or calculate an aggregate when they could let the database do what it does best with a simple SQL statement systems crashing under actual load because their shitty code was never stress tested ( but it worked on my dev box! .) again with databases, having to redo their schemas because they were fattened up so much with columns like VALUE1, VALUE2, ... VALUE20 (normalize you assholes!) chatting remote APIs - because these code monkeys cannot think about the need for bulk operations in increasingly distributed systems. storing dates in unsortable strings because the idiots do not know most modern programming languages have a date data type.

Oh and the most important, off-by-one looping errors. I see this all the time, the type of thing a good programmer can spot on quickly because he or she can do the so-called "lame monkey tests" that involve arrays and sorting.

I've seen the type: "I don't need to do this shit because I have business knowledge and I code for business and IT not google", and then they go and code and fuck it up... and then the rest of us have to go clean up their shit at 1AM or on weekends.

If you work as an hourly paid contractor cleaning that crap, it can be quite lucrative. But sooner or later it truly sucks the energy out of your soul.

So yeah, we need more lame monkey tests ... to filter the lame code monkeys.

ShanghaiBill ( 739463 ) writes:
Re: ( Score: 3 )
Someone could Google the problem with the phone then step up and solve the challenge.

If given a spec, someone can consistently cobble together working code by Googling, then I would love to hire them. That is the most productive way to get things done.

There is nothing wrong with using external references. When I am coding, I have three windows open: an editor, a testing window, and a browser with a Stackoverflow tab open.

Junta ( 36770 ) writes:
Re: ( Score: 2 )

Yeah, when we do tech interviews, we ask questions that we are certain they won't be able to answer, but want to see how they would think about the problem and what questions they ask to get more data and that they don't just fold up and say "well that's not the sort of problem I'd be thinking of" The examples aren't made up or anything, they are generally selection of real problems that were incredibly difficult that our company had faced before, that one may not think at first glance such a position would

bobstreo ( 1320787 ) writes:
Nothing worse ( Score: 2 )

than spending weeks interviewing "good" candidates for an opening, selecting a couple and hiring them as contractors, then finding out they are less than unqualified to do the job they were hired for.

I've seen it a few times, Java "experts", Microsoft "experts" with years of experience on their resumes, but completely useless in coding, deployment or anything other than buying stuff from the break room vending machines.

That being said, I've also seen projects costing hundreds of thousands of dollars, with y

Anonymous Coward , Sunday April 29, 2018 @12:34AM ( #56522157 )
Re:Nothing worse ( Score: 4 , Insightful)

The moment you said "contractors", and you have lost any sane developer. Keep swimming, its not a fish.

Anonymous Coward writes:
Re: ( Score: 2 , Informative)

I agree with this. I consider myself to be a good programmer and I would never go into contractor game. I also wonder, how does it take you weeks to interview someone and you still can't figure out if the person can't code? I could probably see that in 15 minutes in a pair coding session.

Also, Oracle, SAP, IBM... I would never buy from them, nor use their products. I have used plenty of IBM products and they suck big time. They make software development 100 times harder than it could be. Their technical supp

Lanthanide ( 4982283 ) writes:
Re: ( Score: 2 )

It's weeks to interview multiple different candidates before deciding on 1 or 2 of them. Not weeks per person.

Anonymous Coward writes:
Re: ( Score: 3 , Insightful)
That being said, I've also seen projects costing hundreds of thousands of dollars, with years of delays from companies like Oracle, Sun, SAP, and many other "vendors"

Software development is a hard thing to do well, despite the general thinking of technology becoming cheaper over time, and like health care the quality of the goods and services received can sometimes be difficult to ascertain. However, people who don't respect developers and the problems we solve are very often the same ones who continually frustrate themselves by trying to cheap out, hiring outsourced contractors, and then tearing their hair out when sub par results are delivered, if anything is even del

pauljlucas ( 529435 ) writes:
Re: ( Score: 2 )

As part of your interview process, don't you have candidates code a solution to a problem on a whiteboard? I've interviewed lots of "good" candidates (on paper) too, but they crashed and burned when challenged with a coding exercise. As a result, we didn't make them job offers.

VeryFluffyBunny ( 5037285 ) writes:
I do the opposite ( Score: 2 )

I'm not a great coder but good enough to get done what clients want done. If I'm not sure or don't think I can do it, I tell them. I think they appreciate the honesty. I don't work in a tech-hub, startups or anything like that so I'm not under the same expectations and pressures that others may be.

Tony Isaac ( 1301187 ) writes:
Bigger building blocks ( Score: 2 )

OK, so yes, I know plenty of programmers who do fake it. But stitching together components isn't "fake" programming.

Back in the day, we had to write our own code to loop through an XML file, looking for nuggets. Now, we just use an XML serializer. Back then, we had to write our own routines to send TCP/IP messages back and forth. Now we just use a library.

I love it! I hated having to make my own bricks before I could build a house. Now, I can get down to the business of writing the functionality I want, ins

Anonymous Coward writes:
Re: ( Score: 2 , Insightful)

But, I suspect you could write the component if you had to. That makes you a very different user of that component than someone who just knows it as a magic black box.

Because of this, you understand the component better and have real knowledge of its strengths and limitations. People blindly using components with only a cursory idea of their internal operation often cause major performance problems. They rarely recognize when it is time to write their own to overcome a limitation (or even that it is possibl

Tony Isaac ( 1301187 ) writes:
Re: ( Score: 2 )

You're right on all counts. A person who knows how the innards work, is better than someone who doesn't, all else being equal. Still, today's world is so specialized that no one can possibly learn it all. I've never built a processor, as you have, but I still have been able to build a DNA matching algorithm for a major DNA lab.

I would argue that anyone who can skillfully use off-the-shelf components can also learn how to build components, if they are required to.

thesupraman ( 179040 ) writes:
Ummm. ( Score: 2 )

1, 'Back in the Day' there was no XML, XMl was not very long ago.
2, its a parser, a serialiser is pretty much the opposite (unless this weeks fashion has redefined that.. anything is possible).
3, 'Back then' we didnt have TCP stacks...

But, actually I agree with you. I can only assume the author thinks there are lots of fake plumbers because they dont cast their own toilet bowels from raw clay, and use pre-build fittings and pipes! That car mechanics start from raw steel scrap and a file.. And that you need

Tony Isaac ( 1301187 ) writes:
Re: ( Score: 2 )

For the record, XML was invented in 1997, you know, in the last century! https://en.wikipedia.org/wiki/... [wikipedia.org]
And we had a WinSock library in 1992. https://en.wikipedia.org/wiki/... [wikipedia.org]

Yes, I agree with you on the "middle ground." My reaction was to the author's point that "not knowing how to build the components" was the same as being a "fake programmer."

Tony Isaac ( 1301187 ) , Sunday April 29, 2018 @01:46AM ( #56522313 ) Homepage
Re:Bigger building blocks ( Score: 5 , Interesting)

If I'm a plumber, and I don't know anything about the engineering behind the construction of PVC pipe, I can still be a good plumber. If I'm an electrician, and I don't understand the role of a blast furnace in the making of the metal components, I can still be a good electrician.

The analogy fits. If I'm a programmer, and I don't know how to make an LZW compression library, I can still be a good programmer. It's a matter of layers. These days, we specialize. You've got your low-level programmers that make the components, the high level programmers that put together the components, the graphics guys who do HTML/CSS, and the SQL programmers that just know about databases. Every person has their specialty. It's no longer necessary to be a low-level programmer, or jack-of-all-trades, to be "good."

If I don't know the layout of the IP header, I can still write quality networking software, and if I know XSLT, I can still do cool stuff with XML, even if I don't know how to write a good parser.

frank_adrian314159 ( 469671 ) writes:
Re: ( Score: 3 )

I was with you until you said " I can still do cool stuff with XML".

Tony Isaac ( 1301187 ) writes:
Re: ( Score: 2 )

LOL yeah I know it's all JSON now. I've been around long enough to see these fads come and go. Frankly, I don't see a whole lot of advantage of JSON over XML. It's not even that much more compact, about 10% or so. But the point is that the author laments the "bad old days" when you had to create all your own building blocks, and you didn't have a team of specialists. I for one don't want to go back to those days!

careysub ( 976506 ) writes:
Re: ( Score: 3 )

The main advantage is that JSON is that it is consistent. XML has attributes, embedded optional stuff within tags. That was derived from the original SGML ancestor where is was thought to be a convenience for the human authors who were supposed to be making the mark-up manually. Programmatically it is a PITA.

Cederic ( 9623 ) writes:
Re: ( Score: 3 )

I got shit for decrying XML back when it was the trendy thing. I've had people apologise to me months later because they've realized I was right, even though at the time they did their best to fuck over my career because XML was the new big thing and I wasn't fully on board.

XML has its strengths and its place, but fuck me it taught me how little some people really fucking understand shit.

Anonymous Coward writes:
Silicon Valley is Only Part of the Tech Business ( Score: 2 , Informative)

And a rather small part at that, albeit a very visible and vocal one full of the proverbial prima donas. However, much of the rest of the tech business, or at least the people working in it, are not like that. It's small groups of developers working in other industries that would not typically be considered technology. There are software developers working for insurance companies, banks, hedge funds, oil and gas exploration or extraction firms, national defense and many hundreds and thousands of other small

phantomfive ( 622387 ) writes:
bonfire of fakers ( Score: 2 )

This is the reason I wish programming didn't pay so much....the field is better when it's mostly populated by people who enjoy programming.

Njovich ( 553857 ) , Sunday April 29, 2018 @05:35AM ( #56522641 )
Learn to code courses ( Score: 5 , Insightful)
They knew that well-paid programming jobs would also soon turn to smoke and ash, as the proliferation of learn-to-code courses around the world lowered the market value of their skills, and as advances in artificial intelligence allowed for computers to take over more of the mundane work of producing software.

Kind of hard to take this article serious after saying gibberish like this. I would say most good programmers know that neither learn-to-code courses nor AI are going to make a dent in their income any time soon.

AndyKron ( 937105 ) writes:
Me? No ( Score: 2 )

As a non-programmer Arduino and libraries are my friends

Escogido ( 884359 ) , Sunday April 29, 2018 @06:59AM ( #56522777 )
in the silly cone valley ( Score: 5 , Interesting)

There is a huge shortage of decent programmers. I have personally witnessed more than one phone "interview" that went like "have you done this? what about this? do you know what this is? um, can you start Monday?" (120K-ish salary range)

Partly because there are way more people who got their stupid ideas funded than good coders willing to stain their resume with that. partly because if you are funded, and cannot do all the required coding solo, here's your conundrum:

  • top level hackers can afford to be really picky, so on one hand it's hard to get them interested, and if you could get that, they often want some ownership of the project. the plus side is that they are happy to work for lots of equity if they have faith in the idea, but that can be a huge "if".
  • "good but not exceptional" senior engineers aren't usually going to be super happy, as they often have spouses and children and mortgages, so they'd favor job security over exciting ideas and startup lottery.
  • that leaves you with fresh-out-of-college folks, which are really really a mixed bunch. some are actually already senior level of understanding without the experience, some are absolutely useless, with varying degrees in between, and there's no easy way to tell which is which early.

so the not-so-scrupulous folks realized what's going on, and launched multiple coding boot camps programmes, to essentially trick both the students into believing they can become a coder in a month or two, and also the prospective employers that said students are useful. so far it's been working, to a degree, in part because in such companies coding skill evaluation process is broken. but one can only hide their lack of value add for so long, even if they do manage to bluff their way into a job.

quonset ( 4839537 ) , Sunday April 29, 2018 @07:20AM ( #56522817 )
Duh! ( Score: 4 , Insightful)

All one had to do was look at the lousy state of software and web sites today to see this is true. It's quite obvious little to no thought is given on how to make something work such that one doesn't have to jump through hoops.

I have many times said the most perfect word processing program ever developed was WordPefect 5.1 for DOS. Ones productivity was astonishing. It just worked.

Now we have the bloated behemoth Word which does its utmost to get in the way of you doing your work. The only way to get it to function is to turn large portions of its "features" off, and even then it still insists on doing something other than what you told it to do.

Then we have the abomination of Windows 10, which is nothing but Clippy on 10X steroids. It is patently obvious the people who program this steaming pile have never heard of simplicity. Who in their right mind would think having to "search" for something is more efficient than going directly to it? I would ask the question if these people wander around stores "searching" for what they're looking for, but then I realize that's how their entire life is run. They search for everything online rather than going directly to the source. It's no wonder they complain about not having time to things. They're always searching.

Web sites are another area where these people have no clue what they're doing. Anything that might be useful is hidden behind dropdown menus, flyouts, popup bubbles and intriately designed mazes of clicks needed to get to where you want to go. When someone clicks on a line of products, they shouldn't be harassed about what part of the product line they want to look at. Give them the information and let the user go where they want.

This rant could go on, but this article explains clearly why we have regressed when it comes to software and web design. Instead of making things simple and easy to use, using the one or two brain cells they have, programmers and web designers let the software do what it wants without considering, should it be done like this?

swb ( 14022 ) , Sunday April 29, 2018 @07:48AM ( #56522857 )
Tech industry churn ( Score: 3 )

The tech industry has a ton of churn -- there's some technological advancement, but there's an awful lot of new products turned out simply to keep customers buying new licenses and paying for upgrades.

This relentless and mostly phony newness means a lot of people have little experience with current products. People fake because they have no choice. The good ones understand the general technologies and problems they're meant to solve and can generally get up to speed quickly, while the bad ones are good at faking it but don't really know what they're doing. Telling the difference from the outside is impossible.

Sales people make it worse, promoting people as "experts" in specific products or implementations because the people have experience with a related product and "they're all the same". This burns out the people with good adaption skills.

DaMattster ( 977781 ) , Sunday April 29, 2018 @08:39AM ( #56522979 )
Interesting ( Score: 3 )

From the summary, it sounds like a lot of programmers and software engineers are trying to develop the next big thing so that they can literally beg for money from the elite class and one day, hopefully, become a member of the aforementioned. It's sad how the middle class has been utterly decimated in the United States that some of us are willing to beg for scraps from the wealthy. I used to work in IT but I've aged out and am now back in school to learn automotive technology so that I can do something other than being a security guard. Currently, the only work I have been able to find has been in the unglamorous security field.

I am learning some really good new skills in the automotive program that I am in but I hate this one class called "Professionalism in the Shop." I can summarize the entire class in one succinct phrase, "Learn how to appeal to, and communicate with, Mr. Doctor, Mr. Lawyer, or Mr. Wealthy-man." Basically, the class says that we are supposed to kiss their ass so they keep coming back to the Audi, BMW, Mercedes, Volvo, or Cadillac dealership. It feels a lot like begging for money on behalf of my employer (of which very little of it I will see) and nothing like professionalism. Professionalism is doing the job right the first time, not jerking the customer off. Professionalism is not begging for a 5 star review for a few measly extra bucks but doing absolute top quality work. I guess the upshot is that this class will be the easiest 4.0 that I've ever seen.

There is something fundamentally wrong when the wealthy elite have basically demanded that we beg them for every little scrap. I can understand the importance of polite and professional interaction but this prevalent expectation that we bend over backwards for them crosses a line with me. I still suck it up because I have to but it chafes my ass to basically validate the wealthy man.

ElitistWhiner ( 79961 ) writes:
Natural talent... ( Score: 2 )

In 70's I worked with two people who had a natural talent for computer science algorithms .vs. coding syntax. In the 90's while at COLUMBIA I worked with only a couple of true computer scientists out of 30 students. I've met 1 genius who programmed, spoke 13 languages, ex-CIA, wrote SWIFT and spoke fluent assembly complete with animated characters.

According to the Bluff Book, everyone else without natural talent fakes it. In the undiluted definition of computer science, genetics roulette and intellectual d

fahrbot-bot ( 874524 ) writes:
Other book sells better and is more interesting ( Score: 2 )
New Book Describes 'Bluffing' Programmers in Silicon Valley

It's not as interesting as the one about "fluffing" [urbandictionary.com] programmers.

Anonymous Coward writes:
Re: ( Score: 3 , Funny)

Ah yes, the good old 80:20 rule, except it's recursive for programmers.

80% are shit, so you fire them. Soon you realize that 80% of the remaining 20% are also shit, so you fire them too. Eventually you realize that 80% of the 4% remaining after sacking the 80% of the 20% are also shit, so you fire them!

...

The cycle repeats until there's just one programmer left: the person telling the joke.

---

tl;dr: All programmers suck. Just ask them to review their own code from more than 3 years ago: they'll tell you that

luis_a_espinal ( 1810296 ) writes:
Re: ( Score: 3 )
Who gives a fuck about lines? If someone gave me JavaScript, and someone gave me minified JavaScript, which one would I want to maintain?

I don‚(TM)t care about your line savings, less isn‚(TM)t always better.

Because the world of programming is not centered about JavasScript and reduction of lines is not the same as minification. If the first thing that came to your mind was about minified JavaScript when you saw this conversation, you are certainly not the type of programmer I would want to inherit code from.

See, there's a lot of shit out there that is overtly redundant and unnecessarily complex. This is specially true when copy-n-paste code monkeys are left to their own devices for whom code formatting seems

Anonymous Coward , Sunday April 29, 2018 @01:17AM ( #56522241 )
Re:Most "Professional programmers" are useless. ( Score: 4 , Interesting)

I have a theory that 10% of people are good at what they do. It doesn't really matter what they do, they will still be good at it, because of their nature. These are the people who invent new things, who fix things that others didn't even see as broken and who automate routine tasks or simply question and erase tasks that are not necessary. If you have a software team that contain 5 of these, you can easily beat a team of 100 average people, not only in cost but also in schedule, quality and features. In theory they are worth 20 times more than average employees, but in practise they are usually paid the same amount of money with few exceptions.

80% of people are the average. They can follow instructions and they can get the work done, but they don't see that something is broken and needs fixing if it works the way it has always worked. While it might seem so, these people are not worthless. There are a lot of tasks that these people are happily doing which the 10% don't want to do. E.g. simple maintenance work, implementing simple features, automating test cases etc. But if you let the top 10% lead the project, you most likely won't be needed that much of these people. Most work done by these people is caused by themselves, by writing bad software due to lack of good leader.

10% are just causing damage. I'm not talking about terrorists and criminals. I have seen software developers who have tried (their best?), but still end up causing just damage to the code that someone else needs to fix, costing much more than their own wasted time. You really must use code reviews if you don't know your team members, to find these people early.

Anonymous Coward , Sunday April 29, 2018 @01:40AM ( #56522299 )
Re:Most "Professional programmers" are useless. ( Score: 5 , Funny)
to find these people early

and promote them to management where they belong.

raymorris ( 2726007 ) , Sunday April 29, 2018 @01:51AM ( #56522329 ) Journal
Seems about right. Constantly learning, studying ( Score: 5 , Insightful)

That seems about right to me.

I have a lot of weaknesses. My people skills suck, I'm scrawny, I'm arrogant. I'm also generally known as a really good programmer and people ask me how/why I'm so much better at my job than everyone else in the room. (There are a lot of things I'm not good at, but I'm good at my job, so say everyone I've worked with.)

I think one major difference is that I'm always studying, intentionally working to improve, every day. I've been doing that for twenty years.

I've worked with people who have "20 years of experience"; they've done the same job, in the same way, for 20 years. Their first month on the job they read the first half of "Databases for Dummies" and that's what they've been doing for 20 years. They never read the second half, and use Oracle database 18.0 exactly the same way they used Oracle Database 2.0 - and it was wrong 20 years ago too. So it's not just experience, it's 20 years of learning, getting better, every day. That's 7,305 days of improvement.

gbjbaanb ( 229885 ) writes:
Re: ( Score: 2 )

I think I can guarantee that they are a lot better at their jobs than you think, and that you are a lot worse at your job than you think too.

m00sh ( 2538182 ) writes:
Re: ( Score: 2 )
That seems about right to me.

I have a lot of weaknesses. My people skills suck, I'm scrawny, I'm arrogant. I'm also generally known as a really good programmer and people ask me how/why I'm so much better at my job than everyone else in the room. (There are a lot of things I'm not good at, but I'm good at my job, so say everyone I've worked with.)

I think one major difference is that I'm always studying, intentionally working to improve, every day. I've been doing that for twenty years.

I've worked with people who have "20 years of experience"; they've done the same job, in the same way, for 20 years. Their first month on the job they read the first half of "Databases for Dummies" and that's what they've been doing for 20 years. They never read the second half, and use Oracle database 18.0 exactly the same way they used Oracle Database 2.0 - and it was wrong 20 years ago too. So it's not just experience, it's 20 years of learning, getting better, every day. That's 7,305 days of improvement.

If you take this attitude towards other people, people will not ask your for help. At the same time, you'll be also be not able to ask for their help.

You're not interviewing your peers. They are already in your team. You should be working together.

I've seen superstar programmers suck the life out of project by over-complicating things and not working together with others.

raymorris ( 2726007 ) writes:
Which part? Learning makes you better? ( Score: 2 )

You quoted a lot. Is there one part exactly do you have in mind? The thesis of my post is of course "constant learning, on purpose, makes you better"

> you take this attitude towards other people, people will not ask your for help. At the same time, you'll be also be not able to ask for their help.

Are you saying that trying to learn means you can't ask for help, or was there something more specific? For me, trying to learn means asking.

Trying to learn, I've had the opportunity to ask for help from peop

phantomfive ( 622387 ) writes:
Re: ( Score: 2 )

The difference between a smart programmer who succeeds and a stupid programmer who drops out is that the smart programmer doesn't give up.

complete loony ( 663508 ) writes:
Re: ( Score: 2 )

In other words;

What is often mistaken for 20 years' experience, is just 1 year's experience repeated 20 times.
serviscope_minor ( 664417 ) writes:
Re: ( Score: 2 )

10% are just causing damage. I'm not talking about terrorists and criminals.

Terrorists and criminals have nothing on those guys. I know guy who is one of those. Worse, he's both motivated and enthusiastic. He also likes to offer help and advice to other people who don't know the systems well.

asifyoucare ( 302582 ) , Sunday April 29, 2018 @08:49AM ( #56522999 )
Re:Most "Professional programmers" are useless. ( Score: 5 , Insightful)

Good point. To quote Kurt von Hammerstein-Equord:

"I divide my officers into four groups. There are clever, diligent, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and diligent -- their place is the General Staff. The next lot are stupid and lazy -- they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the intellectual clarity and the composure necessary for difficult decisions. One must beware of anyone who is stupid and diligent -- he must not be entrusted with any responsibility because he will always cause only mischief."

gweihir ( 88907 ) writes:
Re: ( Score: 2 )

Oops. Good thing I never did anything military. I am definitely in the "clever and lazy" class.

apoc.famine ( 621563 ) writes:
Re: ( Score: 2 )

I was just thinking the same thing. One of my passions in life is coming up with clever ways to do less work while getting more accomplished.

Software_Dev_GL ( 5377065 ) writes:
Re: ( Score: 2 )

It's called the Pareto Distribution [wikipedia.org]. The number of competent people (people doing most of the work) in any given organization goes like the square root of the number of employees.

gweihir ( 88907 ) writes:
Re: ( Score: 2 )

Matches my observations. 10-15% are smart, can think independently, can verify claims by others and can identify and use rules in whatever they do. They are not fooled by things "everybody knows" and see standard-approaches as first approximations that, of course, need to be verified to work. They do not trust anything blindly, but can identify whether something actually work well and build up a toolbox of such things.

The problem is that in coding, you do not have a "(mass) production step", and that is the

geoskd ( 321194 ) writes:
Re: ( Score: 2 )

In basic concept I agree with your theory, it fits my own anecdotal experience well, but I find that your numbers are off. The top bracket is actually closer to 20%. The reason it seems so low is that a large portion of the highly competent people are running one programmer shows, so they have no co-workers to appreciate their knowledge and skill. The places they work do a very good job of keeping them well paid and happy (assuming they don't own the company outright), so they rarely if ever switch jobs.

The

Tablizer ( 95088 ) , Sunday April 29, 2018 @01:54AM ( #56522331 ) Journal
Re:Most "Professional programmers" are useless. ( Score: 4 , Interesting)
at least 70, probably 80, maybe even 90 percent of professional programmers should just fuck off and do something else as they are useless at programming.

Programming is statistically a dead-end job. Why should anyone hone a dead-end skill that you won't be able to use for long? For whatever reason, the industry doesn't want old programmers.

Otherwise, I'd suggest longer training and education before they enter the industry. But that just narrows an already narrow window of use.

Cesare Ferrari ( 667973 ) writes:
Re: ( Score: 2 )

Well, it does rather depend on which industry you work in - i've managed to find interesting programming jobs for 25 years, and there's no end in sight for interesting projects and new avenues to explore. However, this isn't for everyone, and if you have good personal skills then moving from programming into some technical management role is a very worthwhile route, and I know plenty of people who have found very interesting work in that direction.

gweihir ( 88907 ) writes:
Re: ( Score: 3 , Insightful)

I think that is a misinterpretation of the facts. Old(er) coders that are incompetent are just much more obvious and usually are also limited to technologies that have gotten old as well. Hence the 90% old coders that can actually not hack it and never really could get sacked at some time and cannot find a new job with their limited and outdated skills. The 10% that are good at it do not need to worry though. Who worries there is their employers when these people approach retirement age.

gweihir ( 88907 ) writes:
Re: ( Score: 2 )

My experience as an IT Security Consultant (I also do some coding, but only at full rates) confirms that. Most are basically helpless and many have negative productivity, because people with a clue need to clean up after them. "Learn to code"? We have far too many coders already.

tomhath ( 637240 ) writes:
Re: ( Score: 2 )

You can't bluff you way through writing software, but many, many people have bluffed their way into a job and then tried to learn it from the people who are already there. In a marginally functional organization those incompetents are let go pretty quickly, but sometimes they stick around for months or years.

Apparently the author of this book is one of those, probably hired and fired several times before deciding to go back to his liberal arts roots and write a book.

DaMattster ( 977781 ) writes:
Re: ( Score: 2 )

There are some mechanics that bluff their way through an automotive repair. It's the same damn thing

gweihir ( 88907 ) writes:
Re: ( Score: 2 )

I think you can and this is by far not the first piece describing that. Here is a classic: https://blog.codinghorror.com/... [codinghorror.com]
Yet these people somehow manage to actually have "experience" because they worked in a role they are completely unqualified to fill.

phantomfive ( 622387 ) writes:
Re: ( Score: 2 )
Fiddling with JavaScript libraries to get a fancy dancy interface that makes PHB's happy is a sought-after skill, for good or bad. Now that we rely more on half-ass libraries, much of "programming" is fiddling with dark-grey boxes until they work good enough.

This drives me crazy, but I'm consoled somewhat by the fact that it will all be thrown out in five years anyway.

[Nov 18, 2017] Largest FREE Microsoft eBook Giveaway! I'm Giving Away MILLIONS of FREE Microsoft eBooks again, including Windows 10, Office

Nov 18, 2017 | msdn.microsoft.com

Before we get to this year's list of FREE eBooks, a few answers to common questions I receive during my FREE EBOOK GIVEAWAY:

  1. How many can you download?
    • ANSWER: As many as you want! This is a FREE eBook giveaway, so please download as many as interest you.
  2. Wow, there are a LOT listed here. Is there a way to download all of them at once?
    • ANSWER: Yes, please see the note below on how to do this.
  3. Can I share a link to your post to let others know about this giveaway?
    • ANSWER: Yes, please do share the good news with anyone you feel could benefit from this.
  4. I know you said they are "Free," but what's the catch?
    • ANSWER: There is no catch. They really are FREE . This consider it a, "Thank you," for being a reader of my blog and a customer or partner of Microsoft.
  5. Ok, so if they are free and you're encouraging us to share this with others, can I post a link to your post here on sites like Reddit, FatWallet, and other deal share sites to let them know, or is that asking too much?
    • ANSWER: Please do. In fact, I would encourage you to share a link to this post on any deal site you feel their users could benefit from the FREE eBooks and resources included below. Again, I WANT to give away MILLIONS of FREE eBooks!
  6. Are these "time-bombed" versions of the eBooks that stop working after a certain amount of time or reads?
    • ANSWER: No, these are the full resources for you to use.

Ok, ready for some FREE eBooks? Below is the collection I am posting this year (which includes a ton of new eBooks & resources, as well as some of the favorites from previous years):

... ... ...

PowerShell Microsoft Dynamics GP 2015 R2 PowerShell Users Guide PDF
PowerShell PowerShell Integrated Scripting Environment 3.0 PDF
PowerShell Simplify Group Policy administration with Windows PowerShell PDF
PowerShell Windows PowerShell 3.0 Examples PDF
PowerShell Windows PowerShell 3.0 Language Quick Reference PDF
PowerShell WINDOWS POWERSHELL 4.0 LANGUAGE QUICK REFERENCE PDF
PowerShell Windows PowerShell 4.0 Language Reference Examples PDF
PowerShell Windows PowerShell Command Builder User's Guide PDF
PowerShell Windows PowerShell Desired State Configuration Quick Reference PDF
PowerShell WINDOWS POWERSHELL INTEGRATED SCRIPTING ENVIRONMENT 4.0 PDF
PowerShell Windows PowerShell Web Access PDF
PowerShell WMI in PowerShell 3.0 PDF
PowerShell WMI in Windows PowerShell 4.0 PDF

[Jun 23, 2017] Linux Command Line and Shell Scripting Bible by Richard Blum & Christine Bresnahan

***+ This is an average or slightly above average introductory book, oriented on newcomers to shell scripting. Looks like the author just added (( )) type of arithmetic expressions as a afterthought, while it should be taught as a primary construct. Similar situation with C-style loop available now in bash as well. One of the few books on shell scripting published after 2005. Unix Shell Programming, Third Edition by Stephen Kochan & Patrick Wood is a much better book. For everybody but absolute beginners, Classic Shell Scripting (May 1, 2005) might also be a better book, although it belong to intermediate level.
But this is definitely a good alternative to Sobel's A Practical Guide to Linux Commands, Editors, and Shell Programming (3rd Edition) published in 2012.
BTW it somebody pretend to write a scripting bible he/she should be a scripting god. Neither author qualifies ; -). They are pretty average, run of the mill instructors.
Notable quotes:
"... When is a subshell made, what are the implications of that, how does variable scoping come into play. ..."
"... It has one of the best explanations for sed and gawk I have ever seen. ..."
"... the authors give you ample examples to demonstrate the point. ..."
"... Great examples and clearly described concepts. ..."
Jan 20, 2015 | Amazon.com
Michael , on May 17, 2015
By the time I bought this book, I had already read a lot of online resources about bash scripting, and I had already been using linux for two years. I had even read most of the A-plus certification book on Linux. Despite that, I was constantly struggling to write bash scripts that worked, this is because so much of the free online documentation on bash scripting is confusing and incomplete. Even when consulting co-workers, they too could not explain why so many things I tried to code in a bash script did not work. That's when I decided to buy this book.

The "Linux Command Line and Shell Scripting Bible" cleared up a lot of problems that have been plaguing me for a long time now. I wish that I had started to learn bash scripting with this book, it could have saved me a lot of time. I would highly recommend this for anybody who will use linux.

Let me list some things this book explained to me that I struggled with for years prior:
- When is a subshell made, what are the implications of that, how does variable scoping come into play.
- how can you create, manipulate, and pass around arrays in bash
- how does the "return" statement behave in functions, how to use that in an if statement
- how can you do math in bash
- the differences between [ ] and [[ ]]

Here are some other things I love about this book:
- it has an excellent explanation of how you could parse a command line that follows a complicated pattern like " mycommand --longopt -a -bcf input.txt -- foo bar zop ". Before I picked up this book I thought that would be too difficult to do in a bash script.
- It explains how to easily create GUI interfaces for your script.
- It has one of the best explanations for sed and gawk I have ever seen.

Throughout the entire book, everything said is clear and easy to understand, and the authors give you ample examples to demonstrate the point. While the thickness of the book is a bit intimidating, you will find that you can read it pretty fast because a lot of those pages are full of clear examples that you can read quickly.

Metro CA on September 8, 2015

Four Stars

Great examples and clearly described concepts.

[Jun 23, 2017] Linux Shell Scripting with Bash by Ken O. Burtch

This is a good book with pretty modern coverage of bash, despite the fact that it was published in 2004.
M.Vidrioon November 2, 2016
4.0 out of 5 starsThis Edition Is Under-rated

I am surprised by the harsh reviews. I thought the material was well organized.

I am not a bash newbie. I am a seasoned sysadmin with a programming background. While I don't think the authors (this was a revised book with a second author collaborating) did the best job of demonstrating how bash could be approached as a programming language, I did feel the material covered many of the finer points of bash.

The minor details of the shell language are very important. I think the book could have included more examples, but it was well written.

Perhaps a third edition could be restructured so that bash is portrayed outside of a scripting glue language and portrayed as a semi-programming language (it has programming features.

For example the bash shell actually has a main function that is undeclared, like a C program).

Bash, in my opinion is still a glue language because it isn't efficient when used as a standalone. For example, using bash to match text in a file is a heck of a lot slower than using grep.

I will agree that bash scripts can be approached logically as a C/C++ file if you organize it as such, but nothing in the language syntax forces such a structures approach.

I agree that bash scripts would be easier to read and troubleshot if bash scripting was approached this way.

[Jun 23, 2017] Practical Guide to Linux Commands by Mark G. Sobell

This is a third edition, but not much was changed in comparison with the second edition which is much cheaper. Content is partially outdated, but still Sobel does an average, if not good job of explaining off this multitude of utilities in Linux/Unix. He milks his franchise well in this sense ;-)
The fact that he is publishing his books for 20 years or so helps. And as book is in its third editions typos probably are at least partially eliminated (while Sobel's blunder as for content, of course, remain ;-). You can buy earlier edition and save some money.
It is important to understand that Sobel is an old school guy and it shows. Large part of the book is outdated and some parts are irrelevant to modern Linux env. See very good and objective review of Alex Gezerlison below for additional considerations.

compare with the prev edition

Alex Gezerlison June 5, 2011

3.5 out of 5 stars So-so as a tutorial, pretty good as a reference

Mark Sobell's "A Practical Guide to Linux Commands, Editors, and Shell Programming, Second Edition" follows a number of other "Practical Guides" that Sobell has authored on different flavors of Unix and Linux. Its title is quite descriptive, as it does not contain any material on GUIs, networking, printing, and so on.

The Good: this is basically two books for the price of one. The 300-page reference section toward the end of the book is very good: it contains tables of command arguments in a visually pleasing layout, specific notes, and on top of that it also includes exactly what the man pages sorely lack: detailed examples! Thus, the command reference in Part V alone is worth buying the book for. Sobell covers 100 utilities, ranging from one-page pointers (e.g. cal, renice, strings, wc) to mini-tutorials (e.g. find, grep, make, pax, sort). The early part of the book is 600 pages long and is intended to be both a tutorial and a reference. Sobell is explicitly trying to be novice-friendly: he has included chapter summaries, exercises (with answers to even-numbered exercises provided on his website), a glossary in an appendix, as well as numerous tables summarizing lessons learned (or about to be introduced). Such tables are scattered throughout the text and in the case of a few chapters (notably the ones on vim and emacs) they are also repeated in the form of very useful chapter summaries. Sobell is very good both at cross-referencing material and at collecting all the relevant information in one place. The first 5 chapters deal with the basics of interactive shell usage and are pedagogically sound, probably more so than the chapters that follow.

After that, the author covers two different text editors and two different shells. Though Sobell doesn't seem to favor vim over emacs (or vice versa), in the case of shell programming he is unambiguous: "Do not use tcsh as a programming language ... If you are going to learn only one shell programming language, learn bash." (p. 350). On a different note, Sobell also includes various asides which are perhaps not necessary but are fun to read about, e.g. on the tee or the pstree utilities.

The Bad: this book tries to be two things at the same time, tutorial and reference, and succeeds more in the latter than in the former. This is unfortunate: this volume is too elementary for advanced Linux users, yet it may be too difficult for those with limited experience. A few examples of suboptimal pedagogy: a) Sobell seems to have a mix-and-match approach to writing new books, e.g. in chapter 4 the use of fstab and mount comes out of nowhere and is never really explained -- though it is explained in chapter 12 of Sobell's book on Ubuntu. b) Chapter 6 is nominally about the vim text editor, but in reality it's lacking pretty basic stuff (e.g. gg).

Sobell seems to be more interested in old-school vi, ignoring vim capabilities like folding, keyword completion, and (most importantly) vim's visual mode. c) The organization of the material is not always sound: e.g. to understand the introduction to bash in chapter 8 one has to read portions of chapter 10 on bash programming. Unfortunately, the same also holds for the first half of chapter 10 itself, in which Sobell repeatedly uses concepts that are introduced in the second half. d) When the author introduces a new tool from scratch (see chapters 12, 13, and 14 on awk, sed, and rsync, respectively) the results are underwhelming: pages upon pages of tables and definitions with all examples postponed until later. e) Even though the book contains a number of errata, as of this writing none of them have been corrected on the author's website. Some of these are potentially grave: for example, on p. 305 Sobell describes (()) by saying that it expands an arithmetic expression, but then on p. 461 he includes a tip box highlighting the distinction between arithmetic expansion, $(()), and arithmetic evaluation, (()). What's even worse, using this book as a reference is also somewhat complicated: since it's purportedly aimed at beginners it is far from complete (e.g. Sobell has nothing to say about the printf builtin), but that doesn't change the fact that one still has to lug around a 1000-page volume.

In a nutshell, this an OK introduction to interactive shell usage, but not to shell programming. O' Reilly's tutorial volumes "Learning the bash shell" and "Classic shell scripting" (both of which can be read linearly) are much better when it comes to programming. Even so, the meticulous cross-referencing and the abundance of tables make Sobell's book a decent reference. All in all, 3.5 stars.

[Jun 23, 2017] The Linux Command Line A Complete Introduction by William E. Shotts Jr

Not a bad into book. But pretty basic. too many positive reviews is an alarm sign ;-)

[Jun 23, 2017] Mastering Linux Shell Scripting by Andrew Mallett

Jeff Semelkaon June 8, 2017

3.0 out of 5 stars READ THIS REVIEW PRIOR TO STUDYING THIS BOOK

though i have only read and studied the first few chapters and previewed the remainder of the book, and the fact that i rank myself a few notches above novice in shell scripting, as i have read and studied the entire Mark Sobell book on shells and shell scripting with Linux, which IMHO is one of or the best books on the subject at my level, this book doesnt come close to Sobell's book... as i am looking for another BASH/SHELL book to reinforce what i already know and possibly take it a notch higher, this book is not it. i feel like i am reading the author's abbreviated notes on the subject and rather then feeling like i am being taught, i feel like i am being spoon fed some information on shell scripting... it seems the author could improve his book by filling in the cracks that lead up to a topic rather then just assuming you understand what he is saying, like your his co-worker asking for a quick answer to a question. therefore, as this might be somewhere like my second review ever as im not much into writing reviews, i had to comment on this book as i wasted precious time on this entire experience of searching for that right book.

[Jun 23, 2017] Linux Shell Scripting Essentials by Sinny Kumari

A short, but good and well written book

[Jun 23, 2017] Pro Bash Programming Scripting the GNU-Linux Shell, Second Edition by Chris F. A. Johnson; Jayant Varma

This is a good book, one of the few that treat Bash as a programming language. Although newer bash constructs are omitted from the book despite the fact that this is 2015 edition. I did not found any mention of C-style for loop, for example.
But still the authors knows the subject of the level deeper that average college instructor and that shows.

[Dec 26, 2016] Ask Slashdot: Have You Read The Art of Computer Programming?

Dec 26, 2016 | ask.slashdot.org
Posted by EditorDavid on Sunday December 04, 2016 @09:09PM from the truth-from-Knuth dept.

In 1962, 24-year-old Donald Knuth began writing The Art of Computer Programming, publishing three volumes by 1973, with volume 4 arriving in 2005. (Volume 4A appeared in 2011 , with new paperback fascicles planned for every two years, and fascicle 6, "Satisfiability," arriving last December).

"You should definitely send me a resume if you can read the whole thing," Bill Gates once said, in a column where he described working through the book . "If somebody is so brash that they think they know everything, Knuth will help them understand that the world is deep and complicated."

But now long-time Slashdot reader Qbertino has a question: I've had The Art of Computer Programming on my book-buying list for just about two decades now and I'm still torn...about actually getting it. I sometimes believe I would mutate into some programming demi-god if I actually worked through this beast, but maybe I'm just fooling myself...

Have any of you worked through or with TAOCP or are you perhaps working through it? And is it worthwhile? I mean not just for bragging rights. And how long can it reasonably take? A few years?

Share your answers and experiences in the comments. Have you read The Art of Computer Programming ?

[Jun 3, 2008] Mastering Unix Shell Scripting: Bash, Bourne, and Korn Shell Scripting for Programmers, System Administrators, and UNIX Gurus by Randal K. Michael (Author)

This is one of the few books with some AIX bias. For example, Chapter 11 is about AIX Logical Volume Manager. That author also wrote a great book on AIX administration

From foreword:

We urge everyone to study this entire book. Every chapter hits a different topic using a different approach. The book is written this way to emphasize that there is never only one technique to solve a challenge in UNIX. All the shell scripts in this book are real-world examples of how to solve a problem. Thumb through the chapters, and you can see that we tried to hit most of the common (and some uncommon!) tasks in UNIX. All the shell scripts have a good explanation of the thinking process, and we always start out with the correct command syntax for the shell script targeting a specific goal. I hope you enjoy this book as much as I enjoyed writing it. Let's get started!

Bindlestiff(rixtertech.com)

4.0 out of 5 stars A must-have for all levels of *nix users. , August 1, 2004

The breadth of real-world examples make the difference between this book and most reference texts. It's true that it's written for korn, but I've had little trouble adapting for Bash; many of the scripts run almost unchanged and the ones that don't provide a useful opportunity for exercise in adaptation. The authors prose is clear. His attitude is a bit challenging; he says early on that that his intention is to teach you how to -solve problems- by shell scripting, NOT to present a ream of canned solutions. This is NOT a reference text for any particular shell, you'll still need plenty of O'Reilly books, a web browser & etc.

This book has enabled me to write a major project using scripting as the glue to hold together a hefty mass of file-moving daemons, fax/paging engines, python UI code, PostGreSQL database engine, networking/email, SSH, and Expect scripts on a Gnu Linux platform. I absolutely could not have done it without this book and I'm very grateful to Mr Michael for his work. If a later edition could more closely serve the needs of the masses by presenting more Bash examples and maybe throwing in a CD it would be a 5-star text.

Quote

Command readability and step-by-step comments are just the very basics of a well-written script. Using a lot of comments will make our life much easier when we have to come back to the code after not looking at it for six months, and believe me; we will look at the code again. Comment everything! This includes, but is not limited to, describing what our variables and files are used for, describing what loops are doing, describing each test, maybe including expected results and how we are manipulating the data and the many data fields. A hash mark, #, precedes each line of a comment.

The script stub that follows is on this book's companion web site at www.wiley.com/go/michael2e. The name is script.stub. It has all the comments ready to get started writing a shell script. The script.stub file can be copied to a new filename. Edit the new filename, and start writing code. The script.stub file is shown in Listing 1-1.

#!/bin/Bash
#
# SCRIPT: NAME_of_SCRIPT
# AUTHOR: AUTHORS_NAME
# DATE: DATE_of_CREATION
# REV: 1.1.A (Valid are A, B, D, T and P)
# (For Alpha, Beta, Dev, Test and Production)
#
# PLATFORM: (SPECIFY: AIX, HP-UX, Linux, OpenBSD, Solaris
# or Not platform dependent)
#
# PURPOSE: Give a clear, and if necessary, long, description of the
# purpose of the shell script. This will also help you stay
# focused on the task at hand.
#
# REV LIST:
# DATE: DATE_of_REVISION
# BY: AUTHOR_of_MODIFICATION
# MODIFICATION: Describe what was modified, new features, etc--
#
#
# set -n # Uncomment to check script syntax, without execution.
# # NOTE: Do not forget to put the comment back in or
# # the shell script will not execute!
# set -x # Uncomment to debug this shell script
#
##########################################################
# DEFINE FILES AND VARIABLES HERE
##########################################################
 
##########################################################
# DEFINE FUNCTIONS HERE
##########################################################
##########################################################
# BEGINNING OF MAIN
##########################################################
# End of script

Listing 1-1 (continued)

The shell script starter shown in Listing 1-1 gives you the framework to start writing the shell script with sections to declare variables and files, create functions, and write

the final section, BEGINNING OF MAIN, where the main body of the shell script is

written.

[Mar 01, 2007] Bash Cookbook: Solutions and Examples for bash Users By Cameron Newham, JP Vossen, Carl Albing

***** A good book, one of the few that cover bash 3.2.
calvinnme "Texan refugee"

5.0 out of 5 stars Solutions to problems for bash users of all skill levels, June 25, 2007

This book covers the GNU Bourne Again Shell, which is a member of the Bourne family of shells that includes the original Bourne shell sh, the Korn shell ksh, and the Public Domain Korn Shell pdksh. This book is for anyone who uses a Unix or Linux system, as well as system administrators who may use several systems on any given day. Thus, there are solutions and useful sections for all levels of users including newcomers. This book is full of recipes for creating scripts and interacting with the shell that will allow you to greatly increase your productivity.

All in all this is a very handy reference for a vast number of the tasks that you'll come across when scripting with the bash shell along with well-commented code. Highly recommended.

[Jul 11, 2005] A Practical Guide to Linux(R) Commands, Editors, and Shell Programming by Mark G. Sobell

*** This is a typical Sobel's book (one of a dozen that he published): Not that great, but with a lot of material on the topic. There is also 2012 edition of the same book, which is more expensive. With the price below $2 for used book it is a good value for 1K pages. It is more of a reference then a textbook. The alternative is Unix Shell Programming, Third Edition by Stephen Kochan, Patrick Wood -- a much better book -- but which covers only Bourne shell.

Galactuson May 22, 2013

Terrible Tutorial

I had to buy this book for a Unix/Linux class in College. To keep it short: it's a mess.

There are exercises at the end of each chapter to which you will not find much help in the preceding chapter.

There is no real didactic concept. Everything is all over the place. You get constantly referenced to parts that are several hundred pages ahead of where you actually are and then there is still no explanation. Lack of useful examples galore.

A lot of terms you want to find help about are not even listed in the index.

I am a programming major and I do very well and I have brilliant books for other classes - but this one is a huge downer.

Very frustrating.

So if not required for your schoolwork, I hardly recommend to find a different book!

Edmon Begolion April 17, 2008

A book that will help you become a Linux command line guru

This is a book that I have been looking for for a long time. I have been looking for a book that takes me into the command line world of Linux but in a methodical way describing all the little options, tips, tricks but also the principles that make Linux shell so powerful.

Book begins with a brief history of Linux and very informative, relevant overview of the system architecture. It proceeds with the in depth, hands on walkthrogugh the environment, shells, and command line utilities. There is a very useful and every-day practical exercise at the end of the each chapter.

Book continues with in depth chapters on Linux filesystem, the shell, editors (emacs and vi) and the programming environment including (g)awk and sed.

Book concludes with excellent command reference section (300 pages) and Appendix on regular expressions (superb), getting help with Linux and keeping the system up to date (using yum and bit torrent).

I could go on at length to describe what this book is but trust me, a promotion for the book that you see on Amazon is accurate. This book is as good as it sounds. It is reviewed by 42 reviewers on Amazon and average score is 4.5 stars out of 5. I give it 5.

[Mar 29, 2005] Learning the bash Shell by Cameron Newham

This is slightly obsolete book contains reasonably good description of the shell as a language. Examples are the weakest part and you probably need a Bash Cookbook in addition to that book.
4.0 out of 5 stars Good chapter on debugging., November 16, 2006
By Computer_Geek - See all my reviews
Good chapter on debugging. Good overview of the Bash shell, but I wish it had more examples. For a book with lots of examples, you might want to consider "Bash Shell: Essential Programs for Your Survival at Work" by Larry L. Smith.

[Feb 1, 2005] Classic Shell Scripting by Arnold Robbins, Nelson H.F. Beebe

***** Best Intermediate book. This is a great intermediate book on shell scripting. See my review Classic Shell Scripting. Can serve as a valuable add on to "Learning Korn shell" from O'Reilly (1st edition) -- which is also a very strong book on shell scripting.
The authors provide a lot of interesting and useful information that is difficult to find in other books. They devoted Ch 5 to piping and in 5.4 "Word List" they discuss famous Doug McIlroy alternative solution to Donald Knuth program of creating the list of the n most-frequent words, with counts of their frequency of occurrence, sorted by descending count from an arbitrary text file.
The authors discuss many Unix tools that are used with shell (Unix toolbox). They provide a very good (but too brief) discussion of grep and find. Discussion of xargs (which is usually a sign on a good book on scripting) includes /dev/null trick, but unfortunately they do not mention an option -0n with which this trick makes the most sense.
One of the best chapters of the book is Ch. 13 devoted to process control. Also good is Chapter 11 that provides a solution to pretty complex and practically important for many system administrators task of merging passwd files in Unix. It provides a perfect insight into solving real sysadmins problems using AWK and shell.
Shortcomings are few. in "5.2. Structured Data for the Web" the authors should probably list AWK instead of SED. Also XML processing generally requires using a lexical analyzer, not regular expressions. Therefore a tag list example would be better converted to something simpler, for example generating C-tags for vi.

[Jan 29, 2004] Linux Shell Scripting with Bash by Ken O Burtch

**+ This is an average or below average book on bash. But like in many books of Linux wanna-bees errors are rampant and understanding of shell is lacking. Here is one glaring example of both author oversight and editor neglect ( page 22):
"The tilde (~) represents you current directory.
.... Although .. and .. work with all Linux programs, ~ and - are features of Bash and only work with Bash and Bash scripts.
I wonder since when "The tilde (~) represents you current directory". And since when "~ and - are features of Bash and only work with Bash and Bash scripts. "

cbbrowne (see more about me) from Scarborough, Ontario, Canada

This is pretty comprehensive book that guides the reader on how to use Bash for a wide variety of purposes.

4 out of 5 stars Well-motivated guide to use of Bash for scripting, February 20, 2004

It is very well-motivated; each chapter introduces the area it examines with an interesting anecdote, and presents a reasonably rich set of examples of how to use Bash along with other Unix tools to solve the problem at hand.

It is not solely about Bash; it shows the use of process control tools like ps, kill, and such, text manipulation tools like grep, sort, cut, sed, and such, and version control using CVS. This is all well and proper: One of the major uses of shell scripting is to paste together other programs, and these examples support that.

Well done...

[Feb 27, 2003] Unix Shell Programming, Third Edition by Stephen Kochan, Patrick Wood

***** This is a very solid introductory book from the authors that were in the field for more then 20 years. The first edition was published in 1985 I still have it. It looks like a Guinness record for a computer book: twenty years in print ;-)
Although the content is rock solid this is still Bourne shell so it's OK only as an introduction. Might have value when you need to use Bourne shell when both Bash and ksh93 have a disadvantage of being too complex and fat

Ramy V. "Ramy" (New York, NY) - See all my reviews

Great beginners' text, November 1, 2004

A clear and concise intro text for beginners. Wording is kept short clear and to-the-point. Examples are very clear. Exercises are not tricky and test your plain knowledge of what you covered. Chapters are short. It is clearly a beginner oriented text and is not intended for advanced users.

A Williams "honestpuck" (Neutral Bay, NSW Australia) - See all my reviews
Good guide for beginners, April 6, 2004

Back when dinosaurs roamed the earth and NCR made Unix computers I first started to program for a living. Back then when someone said `script' they meant a shell script, generally for a Bourne shell.

Now that we have languages such as Perl and Python, much of shell scripting has been forgotten. The need still arises for the times and places where running Perl would be just that little bit too much overhead; cron jobs, process start and stop scripts, even machine start and stop scripts. For these we could best go back to the old ways. Combining the power of the common Unix tools, pipes and scripts in a fairly obscure and slightly arcane syntax is not easy to pick up, though the language's simplicity does, in some ways, make it easier than more complex ones such as Perl. Unix Shell Programming, Third Edition does a good job at introducing shell programming and I found it an excellent book when I needed a refresher.

I don't want to sell this volume short: you won't just learn about shell programming. The first ninety or so pages provide an excellent guide to getting the best out of the shell, and the last chapter is devoted to the features specific to an interactive shell such as command-line editing and using the history.

The authors have chosen to use the POSIX standard Bourne shell (`bash', available on many *nix systems, is a superset of the POSIX standard). That seems the right decision, given that it is so universally available and usually the default shell.

The book is well structured, starting out with a brief look at *nix operating systems before introducing the shell followed by some basic tools; cut, paste, sed, tr, grep, sort and uniq. One minor quibble, the book explains how to redirect STDOUT to a file and STDERR to a file, but not how to redirect both to the same file. That aside, these few chapters provide a good introduction to the shell.

The text goes on to systematically explore shell programming starting with variables and arithmetic. The chapters are kept short, in a good order and have a number of exercises at the end of each. The structure of the book and the order each new concept is introduced is well thought out; at each stage small examples are given that only use material already introduced and are complete in performing a task. In early chapters they are fairly trivial but by the end there is a fairly complete rolodex program written in shell script that would be a good model for anything you wished to do.

There is also a good summary of the shell syntax and common commands in Appendix A and good `Further Information' in Appendix B. Kudos must go to the authors for a list of books for further reading that is not ashamed of mentioning other publishers, indeed they say "One of the best sources of books on Unix-related topics is O'Reilly and Associates" and list volumes from them before mentioning their own publishers.

There are some small typographic errors in the text but I did not find any in the script examples I tried. I found it to be well written and readable throughout, perhaps an advantage of a third edition in a slow moving technology.

I would recommend everyone read this book once or twice, it provides a comprehensive, well written tutorial on one of the most basic (and often overlooked) tools at your disposal. Even Windows users could install Cygwin and gain the benefit of a good POSIX compliant shell and this book. It also has the advantage that once purchased it will be useful for many, many years to come - the language has not changed noticeably in twenty five years and should not change in another twenty five.

[Jan 31, 2003] Books Mastering UNIX Shell Scripting by Randal K. Michael

*** This book should probably be called "Shell by example" but this title was already taken. It looks like it is slightly AIX biased but many scripts are multiplatform and take into account all major enterprise flavors of Unix including Solaris, HP-olX and Linux.
The book deals with POSIX shell not ksh93 as previous reviewer assumed (for example Solaris the default shell is POSIX shell and ksh93 is available only as dtksh, the Desktop KornShell)
The books starts with very brief, badly written and superficial reference of shell, that should probably be published as an Appendix.
The other 24 chapters demonstrate "shell by example" approach: each is devoted to one useful, semi-useful or completely useless example.
Chapter 2 is amusing. The author shows 12 ways of piping the file into the while loop. Half of them completely useless and added just to impress the reader. Moreover the author seems does not understand that
cat $FILENAME | while LINE=`line`
and
cat $FILENAME | while LINE=$(line)
are absolutely identical :-)
Chapter 3 is semi-useful and is devoted to programming of various type of progress indicators in shell. All example are pretty straightforward.
Chapter 4 is devoted to monitoring filesystem space. For an intermediate book it's sad that the author definitely does not understand that he need to use AWK or Perl here.
Chapter 5 is good and shows simple and useful swap space monitoring framework.
Chapter 7 contains very questionable approach to a trivial problem. Instead of parsing uptime string with AWK or Perl from the right the author split hears about variations of time formats used in the command.
Chapter 8 demonstrates co-routine approach to solving a problem and that's probably the most interesting example that I have found. But the code in Listing 8.9 to long and can benefit form refactoring.
Chapter 10 is useless other then example of some shell constructs and the author does not demonstrate deep understanding of the issues involved with security of passwords in general and with the randomization of passwords in particular.
Chapter 11 is AIX specific.
Chapters 12 and 13 are pretty useful, but in both cases there are better approaches and they can benefit from Webliography inclusion (the author actually pretty much ignore the fact of existence of Internet including various free code databases like freshmeat).
All-in-all the book is a mixed bag. Examples are OK as shell programming demonstrations but they fall short of demonstrating the mastery of both ksh and UNIX tools involved.
the_haawk (see more about me) from Irving, TX United States
2 out of 5 stars Good for advance user not for beginners, July 23, 2003

This is not a greatest book for learning Shell Scripting. This book does not cover regular expressions in detail even though regular expression is the heart to learning shell scripting.

It could be a good book for users already familiar with Shell scripting and want to learn advance techniques in administering their application or the UNIX system.

I will definitely not recommend this for users that are looking to learn and understand Shell scripting.

[Mar 1, 2002] Learning the Korn Shell (2nd Edition) by Bill Rosenblatt, Arnold Robbins

***+ Paradoxically it is weaker then the first edition. I think this is due to the fact that Arnold Robbins is a co-author who inherited the book after the initial authors left the field/lost interest and despite his best efforts this edition was unable to update this edition to the level that preserved its integrity and corresponds to the current shell development level. The book looks like a mix of old and new material.

ISBN: 0596001959

Paperback - 400 pages 2nd edition (March 2002)
O'Reilly & Associates; ISBN: 0596001959

unixnut (see more about me) from Overland Park, KS

4 out of 5 stars Great book, but has some flaws, August 13, 1999

I have owned this book since 1996 and I used it as my introduction to Korn shell programming. To the credit of the book, I was able to become very adept at Korn shell and I have written some amazing scripts. However, I must admit that some sections of this book are misleading, confusing and downright incomprehensible. It took many re-readings of some chapters before the author's lesson was brought to light. I would recommend this book as a Korn shell reference, but it is probably not the best place to start for a Korn shell beginner. I am finding this to be true for a lot of the books by O'Reilly & Associates.

bon_jour (see more about me) from Dallas, TX

5 out of 5 stars A great book about Korn shell programming, December 3, 2001

I gave it 5 stars partially because it was given just 1 star unjustly by a few reviewers. From a number of complaining reviews, one realizes that the book title is little misleading. It's not a book for a true beginner wanting to read about "simple" examples of shell programs and looking for detailed explanations line by line. This book is concise, to the point, and really explains "Korn" shell's features. Even as early as chapter 4 about Korn shell basics, things are explained that a long-time shell programmers may not know. If you do and have done serious, real world Korn shell programming, you'll appreciate it.

There were also complains about hard to find things in the book. But from my experience, it's not the case if one really reads it from cover to cover and understands the topics presented chapter by chapter. I agree that the book may not be a great reference book, but it was not written as one.

fishgeeks_dot_com (see more about me) from FishGeeks.com

An excellent book for the beginner - advanced ksh programmer, March 29, 2001

This is a great book for someone new to ksh programmer. It should be treated as a work manual and not as a reference book. Read this book through from cover to cover and you'll soon be writing ksh scripts with ease.

The book takes you though Korn shell basics from answer what a shell is to using files, I/O, and character quoting.

From there it goes into command line editing, customizing your environment, and into basic programming. Once through that you learn flow control, arrays, advanced I/O, and process handling.

Finally you learn how to debug the script you just wrote.

As a reference manual this book is average. It's not meant to be a typical "nutshell" book and shouldn't be treated as one.

The bottom line? Buy this book if you are truly interested in learning how to program in the Korn shell

[Mar 1, 2002] Learning the Korn Shell (1nd Edition) by Bill Rosenblatt, Arnold Robbins

*** IMHO this is one of the best ksh93 intermediate books, that can also serve as the first book on shell programming for people with some exposure to Unix or programming. It concentrates more on the language than on typical examples of shell scripting. See reviews in a Introductory Shell Programming section). It contains the code for a Korn shell debugger: a non-trivial exercise...

Bill Rosenblatt, Arnold Robbins

ISBN: 0596001959

Paperback - 400 pages 2nd edition (March 2002)
O'Reilly & Associates; ISBN: 0596001959

[Jan 5, 2001] Korn Shell, The: Linux and Unix Shell Programming Manual by Anatole Olczak. Paperback

This is a good book. It provides some details on Korn shell that are difficult to find in other books.

Paperback - 464 pages 3rd Bk&cdr edition (January 5, 2001)
Addison Wesley Professional; ISBN: 0201675234 ; Dimensions (in inches): 1.06 x 9.21 x 7.42

[Jun 15, 2000] Linux Shells by Example (with CD-ROM) by Ellie Quigley

*** This is a weaker version of the Unix shell by examples book. See my review . For Linux book it's a rather expensive book but still it has more than 100 additional pages in comparison with Unix edition for the same price ;-).
This book unfortunately covers bash instead of ksh93 which is probably OK for novice Linux users, but still not a wise choice for a decent university course. Originals are much better then copies and ksh93 is so much superior free shell even on Linux than you should not even think about teaching bash in a decent university ;-).
The decision to cover several shells in one book raise doubts about the wisdom of the author, but book is still decent ;-). Again you probably should think about it as a weak system administration book and in this respect Sobel's books are much better deal. If you replace bash chapter with a decent ksh93 tutorial that book can be used for Solaris8 too as Solaris8 includes GNU utilities.
The main problem with this book is that there is not much Unix and too much shell junk in it. Very weak artificial examples. I do not see real understanding of Unix by the author and the shall usage in real Unix environment. Instead of massaging three almost identical shells a decent book should probably cover Perl and Expect. So this book is good neither for beginners nor for intermediate/advanced users ;-). May be awk chapter can be omitted if Perl is used and such a decision can cut the weight of the book too. You can buy an older book Unix Shells by Example (654 pages 2 edition, July 12, 1999; Prentice Hall; ISBN: 0130212229) that covers ksh. See reviews of the older book.

CD-ROM - 761 pages 1st edition (June 15, 2000)
Prentice Hall; ISBN: 0130147117 ; Dimensions (in inches): 2.10 x 9.20 x 7.03
Amazon.com Sales Rank: 8,266
Avg. Customer Review: 4 out of 5 stars
Number of Reviews: 1

Table of contents

[Dec 27, 1999] Linux and Unix Shell Programming by David Tansley

Looks very promising. Very well thought out organization which is evident event from the table of content: better that in any other book that I know. As the first edition there are too many errors but for a professional reader that does not matter much, which matter are concepts and due to this this book is uniquely useful.
Unfortunately not all errors are just typos, some errors are conceptual, for example when discussing XRAG the author fails to mention the option 0n that prevents overflowing of the argument list (in this case commands are executed one by one).
Publisher URL: http://www.awl.com/cseng/
See also LJ 74 Book Review
A reader
this book has many examples other don't have!, October 22, 2000

1. This book contains many errors like other readers have pointed out, but its shell programming examples really help me. Those examples I can't find from other books.

2. This book will not help you too much in unix concepts, and thus you may have to buy another good unix concepts book to solve those problems.

3. overall, as long as you have enough time to play those examples in your unix machine and want to write a 30 pages of codes like those in chapter 21 and 22, this is definitely the one you want and bring you to another level!

4. personally, I buy two different books to study a computer skill. One is the text book by college professor who may insure the concepts are correct, the other is the book having enterprise examples. But it is so hard for one to find the one having both. This book partially fit my second need!

John (GodLovesEveryone.org) (Northwest Arkansas) - See all my reviews

Tansley's Linux book is an Amazing Friend to keep nearby, March 28, 2000

A friend of mine raves about "Linux & Unix Shell Programming" by David Tansley, and I certainly have to agree with him.

In my case, I had to add Linux to my Windows 98 computer so that I could better talk to and understand programmers who enter the programming contest at <www.MSOworld.com/programming.html>. This book would almost be my "Best Friend" if such a thing were possible, because it lets me look up the DOS terms I memorized years ago and see the equivalent Linux terms and syntax. (I'm in love with that feature, by the way).

"Linux & Unix Shell Programming" even has material that will help you learn the same CGI that is found on many web pages, and, thank goodness, the wild cards I fell in love with in DOS are there.

As you can see from the table of contents, below, it covers quite alot of ground, from "Introduction to Linux/Unix in general" to "Building CGI scripts for a web site."

Cool, eh?

Definitely buy it if you're looking to understand Linux, and especially if you're an old DOS user from the early computer age.

The Table of Contents is below. I hope you fall in love with it.

John Knoderer
mazes@msoworld.com
webmaster@mazes.com

Gregory D. Donovan (Golden, CO) - See all my reviews

Best Shell Programming Book I've Found Yet!, July 6, 2004

I own no less than ten books on shell programming and this one has helped me more than the rest combined.

The author has the talent for condescending to my level to explain concepts that I have had a great deal of trouble understanding.

I was able to write a menu driven script to simplify the loading and unloading of a tape library after reading just two chapters from the middle of the book.

I even created my first shell function in the process. Yes there are a few typos. I'm not sure why some of the more sophisticated reviewers had a problem with this.

I still found the book very useful and was able to catch the intended meaning in spite of the typos. If you are a genius this book may not be for you. If you are trying to learn how to write scripts quickly I highly recommend it.

I would have traded all my other scripting books for this one had I known how useful it is.

Victor Kamat (Modesto, CA United States) - See all my reviews

Reviewer: A reader from Modesto, CA United States
This is a marvellous book on Unix/Linux shell programming. D. Tansley knows unix/linux very well, and is a very good teacher too. (In my opinion if you study this book and "The Korn Shell" by Olczak you'll become very good at Unix and Shell scripting.)

He has obviously thought a great deal about the organization of the book; in my opinion he has done it very well.

About 1/2 the book is devoted to grep, find. awk, cron, file permissions, quoting, the login environment, etc. His explanations are the best I have read, and all this is enhanced by his organization of the material and his examples.

He then gets into shell scripts, things like conditional testing, control flow structures, functions, and then more advanced material. And once again he does a very nice job.

The more I read this book and use it in my daily work, the more impressed I am with it. If you are a unix/linux user do yourself a favor and get this book.

One reviewer has given this book a scathing review; in my opinion this reviewer is totally off-the-wall. It may be that he has a problem with the english language (he's from Swizterland). Set aside his remarks.

[Jul 12, 1999] Unix Shells by Example

Junk...
This book covers ksh93 and three other shells (Bourne shell and C shell) which is an overkill for an intro book. There are a lot of examples but most of them are low level "oversimplified blackboard examples". You should consider this book as a collection of unrelated chapters that can be used in any order or omitted completely. The author is definitely not a specialist in Unix, but a college teacher who polished his course from semester to semester without removing principal weaknesses. The only good thing about the book is that it tries to provide some information on most important utilities in addition to shells. Chapters on awk (Chapter 5-7, 120 pages) and sed (Chapter 4, 30 pages) are strong features of the book. There is also a chapter on grep (Chapter 3). Supplement A that covers Unix utilities useful for shell programming should probably be upgraded to a chapter. the book contains hands-on exercises for every topic, an appendix with detailed syntax listings, examples of many useful UNIX utilities, comparison charts, and much more. Again I would like to reiterate that the main strength of this book is that in addition to shell it contains separate chapters on grep, sed and awk.
But even with some additions and modifications I would recommend Sobel's book as an add-on to this book. Explanation of various features of the shells in is decent, but order of chapters is somewhat strange and most examples are weak and artificial.
There is also a weaker Linux editon that discuss bash instead of Ksh93.
The book covers too many shells. Despite apologies of the author each redundant chapter adds to the brick size of the book and adds to the cost of the book as well.

by Ellie Quigley
Our Price: $39.99
Paperback - 654 pages 2 edition (July 12, 1999)
Prentice Hall; ISBN: 0130212229 ; Dimensions (in inches): 1.80 x 9.25 x 7.03
Amazon.com Sales Rank: 11,184
Avg. Customer Rating:
Number of Reviews: 17
Table of contents

The author also published :

The Complete Perl Training Course

Ellie Quigley / CD-ROM / Published 1998 /$99.95

Perl by Example

Ellie Quigley / Paperback / Published 1997 / $31.96

Here are selected Amazon reviews:

*** Need Go Beyond by Example", August 3, 1997
Reviewer: A reader
I am a "not-so-proud" owner of "Shell By Example" and "Perl by Example" - let me tell you why. First, the "Perl" book is boring and unfocused. The "Shell" book is even worse, it has several typos and the book is inflated to 600+ pages - the author uses the same data file in every example and prints it out in every example every time (There are a lot of examples, as indicated by the book title)! Second, it (the "Shell" book) does not provide some useful, interesting, long examples, most of the examples (scripts) are "baby talk" types - you are more likely to read them and forget them later. There is no problem-solving section. There is no reader involvement. In addition, the paper used in manufacturing of this book is so heavy, it makes this book look like a 1000+ page book. I bought these books at the same time in a "normal" bookstore - which means I did not take advantage of 20 % discount from AMAZON.COM and paying high California Sale Tax.

One of those "must have" books, June 25, 1999
Reviewer: rjw@pcs-sd.com from South Dakota, USA
It is unfortunate that the many typos made it into the final product. That aside, I recommend this book to anybody who wants to know more about shell programming in general. Although I still have many separate books on awk, sed, sh, csh, etc. this is the book I started learning Unix on, and this is the book I still keep on the shelf, or use when I am preparing my own classes on shells. The layout and content of this book has made me search for and buy other Quigley titles simply on the strengh of the author's name.

Learning by example, November 17, 2000
Reviewer: willem leenen (see more about me) from Amsterdam
The 'Unix Shells By Example' is a well-known book in the field of shell scripting. It has about 640 pages with a CD-ROM included. The book is well edited, with good white-spacing and clarity in layout. Having taught the unix shells for over 15 years, the author really knows her stuff, and the text is factual and to the point. The index seems complete and one doesn't have a difficulty in finding the right info one is looking for. These properties should be normal for books, but computer books seem often an exception.

The chapters deal about the central Unix-commands for scripting (Grep, AWK, SED) and the big three shells (korn, bourne and C-shell). The author explains the subject in great detail by showing example scripts. First you're given the data or text to be edited, then the script or command lines and finally a lengthy line-by-line explanation of the script syntax. The subjects of the scripts range from explaining the basic Unix-commands to complex intertwining regular expressions, functions, obscure nawk options etc. The author also touches the subject of shell-history, making comparisons of the three shells, giving 'lab-exercises' and some Unix background about command types, login and inheritance. The apparent subject that is missing in this book is the Bash shell, the preferred shell in the Linux community. However, a separate book on this subject is available (Linux Shells By Example). As with all books that have an extensive coverage of the subject, this book too can be overwhelming for the absolute beginners in shell scripting. It takes some time before one writes syntax like:

nawk -F: 'BEGIN{printf("What vendor to check?");\

getline ven <"/dev/tty"};$1 ~ ven\

{print"Found" ven "on record no" NR}' vendor

Instead of searching the pages for the basics, beginners should consider buying an entry level book.

Conclusion: For the intermediate scripter who visits shell sites like shelldorado and lurks newsgroups in search of advanced programming constructs to steal this book is a great find. You won't be left with a feeling that you'll outgrow this book. For newcomers in scripting this should however not be the first book to buy, they're better of with titles like "learning shell scripting in 24 hours". But once through these 24 hours, this book can only be warmly recommended.

[Feb 22, 1999] Unix Shell Programming Tools (Unix Tools) by David Medinets

*** Generally the book is a very unimpressive book. I would call it a pretty raw book. The value and intended audience are not clear. I saw that it was used for university courses, but I would advice against that. Probably in this role Linux Programming is a better deal.

Table of contents.

From amazon.com review written by Ryan Kuykendall:

David Medinets's Unix Shell Programming Tools surveys the commands and code elements of the three scripting languages that are most commonly used in Unix: the Bash shell, Perl, and the Tool Command Language (Tcl).

The book catalogs each of the different languages and uses short, descriptive code samples to demonstrate standard usage for most of the items discussed.

Medinets dedicates nearly half of the book to an ample discussion of the Bash shell and creates special chapters focused on the constituent elements of shell programming, including the creation of variables and procedures.

While discussions on Perl and Tcl are separated into distinct chapters, each has fewer code samples to illustrate variations on code writing and usage. Instead, the author supplements the discussions on Perl and Tcl with dictionary-entry-style charts describing each language component by component.

[Feb 19, 1999] Sams Teach Yourself Shell Programming in 24 Hours by Sriranga Veeraraghavan

***+ Weak... Pretty useful content but wrong shell ;-). This is definitely not The New Kornshell : Command and Programming Language, but the book has a very positive reviews from Amazon readers.

For example:

5 out of 5 stars A solid introduction into shell scripting , March 3, 2000
Reviewer: A reader from New York
This book provides a very good foundation so that one may learn Unix shell scripting. It also allows one to understand the more advanced books, which is very important. I thought there were some sections of the book that were a bit sketchy in their explanation.

For example, the no-op operator (:) was not explained to my liking (although a fairly good attempt was made). Overall, however, the beginner to Unix will learn much from this book.

5 out of 5 stars Best shell scripting guide since Kochan , September 16, 1999
Reviewer: A reader from Cary, NC
Glad to see the other good reviews. I was impressed and wanted to see what others had to say.

This is the way it should be done. Definitely appreciated the emphasis on the bash shell and the inclusion of other useful tools.

Pleasantly surprised by the depth and quality of the examples...this is one of the best book in SAMS catalog.

Author also had a chapter or two in Kao's Special Edition Using Unix, which was a solid book even though it is a major doorstop in size. Looking forward to more titles from Veeraraghavan.

It looks like the quality of non-O'Reilly titles may be improving after all...

[Dec 22, 1998] UNIX Shell Programmer's Interactive Workbook by Christopher Vickery, Chris Vickery

This book contains a lot of exercises but the author seems to be not seeing the forest after the tries and is unable to distinguish between important features/topics and obscure one. CD contains full CBT training course that costs much more than the book if you want to buy it separately.

Textbook Binding - 496 pages 1 edition (December 22, 1998) Prentice Hall; ISBN: 0130200646 ; Dimensions (in inches): 1.75 x 9.23 x 7.01
Amazon.com Sales Rank: 36,910
Avg. Customer Review: 5 out of 5 stars
Number of Reviews: 1

[Oct 1, 1998] Hands-On KornShell 93 Programming by Barry Rosenberg

***+ Good ksh93 programming book that can be a nice complement to Learning Korn shell. Not exactly an intro and does not go into details that Learning Korn shell goes in some areas. At the same time it discusses some features like discipline functions that are usually omitted in other intro/intermediate books including Learning Korn Shell.
The main problem with the book is that it does not discuss utilities that are usually used in shell programming and features of the interactive shell. Also the book is too short for the subject area that needs to be covered (the first 16 chapters are only 335 pages, chapter 17 is irrelevant to the topic). Some important areas are covered very superficially (.profile .kshrc). Space was also wasted on demonstrating how shell can be used for writing CGI scripts -- generally it should not -- that's too much a security risk ;-). The author stated his "by example" approach and I think that he is right, but he need to follow this approach more thoroughly.

Barry Rosenberg / Paperback / Published 1998
Amazon price: $44.95
Paperback - 444 pages Bk&Cd Rom edition (October 1998)
Addison-Wesley Pub Co; ISBN: 020131018X ; Dimensions (in inches): 0.86 x 9.13 x 7.28
Table of contents

Here is a relevant quote:

When I read programming manuals, I usually skip over the text and head straight for the examples. I like short, focused examples that don't bog me down in a lot of programming red-herrings. And when I am forced to read text, I like a little humor.

So, I wrote the kind of book that I like to read.

Here are some Amazon readers reviews:

5 out of 5 stars Impressed a tough critic! June 13, 1999

Reviewer: A customer from New Jersey

The KornShell Programming Tutorial should be the model for all technical books. It is well organized and extremely well written. The book provides a ton of examples, and output is provided for each one--what a concept! Reading this book has enabled me to write support and debugging scripts for the program I currently work on, and if I need to refer to the book, I can find the topic quickly. The writing style is crystal-clear and right-to-the-point, and the humorous touches round out everything nicely. Thanks to Barry Rosenberg for caring enough to write a book on Korn Shell programming that a novice could actually read, understand, and apply.


3 out of 5 stars This book is better than most...BUT.... (rating=3.5)
Reviewer: kim_carlton@hotmail.com from Richmond, VA December 31, 1998

Briefly: If you are an experienced programmer, know KSH 88 and want to learn KSH 93 - BUY THIS BOOK. Good things: Extensive coverage of KSH 93 with all the new features. Additionally, techniques are employed that are very educational. Bad things: Very sloppy editing. To wit:

All in all - I give it 3.5 stars. 4 stars with correct editing and proofing. 4.5 stars if co-processes were covered extensively. 5 stars if he gets rid of the jokes --- (ok, I'm kidding there).

A reader from an Oracle/Solaris Shop in St. Louis, Missouri , January 21, 1999 *****
A must have for Korn shell programmers who like example code
This is an excellent book chock-full of example code that is presented in a logical and practical manner. The only down side (not the author's fault) is the availability of ksh93 on some Unix platforms (e.g. Solaris 2.5/2.6 uses the older ksh88 version). Regardless, there are still good examples for ksh88 programmers. Oh, I can't rate the enclosed CD-ROM as I have not used it yet. If the CD is any good it will be icing on the cake.

gtillery@mindspring.com from Birmingham, Alabama , January 10, 1999 *****
Another #1 'Must Have' Book For Any Serious SysAdmin
Barry Rosenberg has done it again. This time with more flair and vision for what Kornshell can do! I purchased his original book on Kornshell and practically wore the cover off of it. He has taken a great book and made it even better! I will recommended this one to everyone I can talk to as well. Looks like this new edition will replace his other book on my bookshelf. Simply Outstanding!

[Sep 1, 1998] Unix Shell Objects

Pdksh-based.

Christopher A. Jones / Paperback / Published 1998
Amazon price: $33.99 ~ You Save: $6.00 (15%)

Paperback - 448 pages Bk&Cd Rom edition (September 1998)
IDG Books Worldwide; ISBN: 0764570048 ; Dimensions (in inches): 1.29 x 9.02 x 7.04

The author, Christopher A. Jones (chris@perpendicularuniverse.com) , August 24, 1998
Object-Oriented Programming
UNIX Shell Objects is a book about Object-Oriented programming. This book describes techniques for crafting reusable interfaces, taking advantage of polymorphism, and using inheritance in ways that simplify your programming instead of complicating it. This book guides you step by step through the nature of using Object-Orientation effectively via the Korn shell. After developing useful system objects, the book moves on to tackling network topology through the use of an Object Request Broker for... read more

[Mar 27, 1995] The New Kornshell : Command and Programming Language by Morris I. Bolsky, David Korn

**** This is the most authoritative book on Korn Shell 93\. More of a reference than textbook. Should not be your first or only book on shell programming...

Morris I. Bolsky, David Korn / Paperback / Published 1995

Textbook Binding - 416 pages 2 edition (March 27, 1995)
Prentice Hall; ISBN: 0131827006

. Here is one review from Amazon:

There is no one better than Mr. Korn himself to offer the clearest, most complete information about KornShell. The usefulness of this book as a language reference is indisputable. Although not immediately comprehensible by the novice, it is, nevertheless, essential to all KornShell programmers. The back cover index is one of the nicest features of the book. I only wish more books would use this design. Every new technology should have major technical reference material written by its inventor or creator available to the general public. In the UNIX world, such works are common. I enthusiastically recommend this book for all KornShell programmers. For those that find it difficult initially, I assure you that you will grow into it, and it will eventually find its place close at hand in your office library.

Desktop KornShell Graphical Programming by J. Stephen Pendergrast, Jr.

Covers ksh93, the authoritative reference on dtksh.

Addison-Wesley, 1995.

Korn Shell Reference

Arnold Robbins / Paperback / Published 1995

Teach Yourself the Korn Shell in 14 Days with Disk

Kamran Husain / Published 1995

Unix Shell Programming

***+ This is a good book, but only ksh88 is covered. One can see that authors are personalities not hired staff who can spit 1200 page book for any fashionable topic. I read the third edition (1994). Slightly outdated and does not mention ksh93. Covers SH, KSH and CSH.

Arthur, Lowel Jay. Burns Ted / Paperback, 4th edition / Wiley, 1994/

Wiley site contains several fragments on the book including:

Unix Applications Programming : Mastering the Shell

Ray Swartz / Published 1990

Expert Korn Shell Programming (In Just 3 Days)

William N Franklin / Unknown Binding / Published 1997

[Jun 1, 1993] Learning the Korn Shell (A Nutshell Handbook) by Bill Rosenblatt

**** This is second good intemediate book. Contents is slightly outdated and covers only ksh88. Still the first edition is somewhat better then the second that was upgraded by a different author. The key factor for this book is the right definition of intended audience: it is really the best introductory book for students at the university level and professionals. Reader needs to know some Unix (and the reader is expected to know classic Unix utilities) or programming experience.
Actually it is one of the few shell books that provides a good coverage of usage of pipes in shell scripting, the quintessential feature of the Unix shell. This is the strongest feature of the book. At the same time the books also contains a lot of subtle but important information for example it explains why an alias ll='ls -la ' (with trailing space) is more useful then without trailing space. It also covers "IFS" variable, shell functions. In several chapter the authors develop the example of a simple, yes (marginally) useful tool: an analog of C-shell popd/pushd/dirs troika for the ksh. the last chapters contains an example of a really complex (shell debugger) script.
Paradoxically the first edition is considered to be weak by some Amazon.com readers: IMHO this is a nice demonstration of an "Amazon lemmings effect". May be the reason is that the book is too complex to be the first book for learning shell, if you are complete novice (often shell course introduces people to Unix at universities). In such cases A Practical Guide to Solaris might be a better bet, but still I recommend to buy this book as a second book -- it contains a lot of important information that helps better understand shell and write better shell scripts. The second edition should be available in April 2002, and with 9 years and 40 pages we can expect a lot of improvements ;-)
Shortcomings of the book include very superficial treatment of .profile and .kshrc files. Some examples also can be made batter (I think that pushd/popd example that authors use can be replaced by something more useful) but that can be said almost about any book. Neither sed not awk is covered (O'Reilly has a separate book on this subject). At the same time the fact that book does not use awk cripple some examples as it solves several shell problems more elegantly than other built-in UNIX commands.

Bill Rosenblatt / Paperback / Published 1993

Paperback - 363 pages (June 1993)
O'Reilly & Associates; ISBN: 1565920546
Table of contents

5 of 5 stars A great book about Korn shell programming, December 3, 2001
Reviewer: A reader from Dallas, TX
I gave it 5 stars partially because it was given just 1 star unjustly by a few reviewers. From a number of complaining reviews, one realizes that the book title is little misleading. It's not a book for a true beginner wanting to read about "simple" examples of shell programs and looking for detailed explanations line by line. This book is concise, to the point, and really explains "Korn" shell's features. Even as early as chapter 4 about Korn shell basics, things are explained that a long-time shell programmers may not know. If you do and have done serious, real world Korn shell programming, you'll appreciate it.

Reference

The New Kornshell : Command and Programming Language by Morris I. Bolsky, David Korn

**** This is the most authoritative book on ksh93. More of a reference than textbook. Should not be your first or only book on shell programming

Morris I. Bolsky, David Korn / Paperback / Published 1995

Textbook Binding - 416 pages 2 edition (March 27, 1995)
Prentice Hall; ISBN: 0131827006

. Here is one review from Amazon:

There is no one better than Mr. Korn himself to offer the clearest, most complete information about KornShell. The usefulness of this book as a language reference is indisputable. Although not immediately comprehensible by the novice, it is, nevertheless, essential to all KornShell programmers. The back cover index is one of the nicest features of the book. I only wish more books would use this design. Every new technology should have major technical reference material written by its inventor or creator available to the general public. In the UNIX world, such works are common. I enthusiastically recommend this book for all KornShell programmers. For those that find it difficult initially, I assure you that you will grow into it, and it will eventually find its place close at hand in your office library.

Korn Shell, The: Linux and Unix Shell Programming Manual
by Anatole Olczak. Paperback

Despite the title this is not a user manual -- this is a reference. Although never mentioned explicitly it covers ksh93.

Our Price: $44.95
Paperback - 464 pages 3rd Bk&cdr edition (January 5, 2001)
Addison Wesley Professional; ISBN: 0201675234 ; Dimensions (in inches): 1.06 x 9.21 x 7.42

Korn Shell Quick Reference Guide

Anatole Olczak / Paperback / Published 1998

Korn Shell Reference

Arnold Robbins / Paperback / Published 1995

Unix Shell Commands Quick Reference

(Que Quick Reference Series)

William Holliker / Published 1990

C Shell Quick Reference Guide

Anatole Olczak / Mass Market Paperback / Published 1998
Amazon price: $7.95 + $1.35 special surcharge

Unix C Shell Desk Reference

Martin R. Arick / Paperback / Published 1993
Amazon price: $27.96 ~ You Save: $6.99 (20%)

Unix C Shell Desk Reference

Paperback / Published 1991


Bourne Shell and Portable Shell Programming

***** Portable Shell Programming : An Extensive Collection of Bourne Shell Examples by Bruce Blinn

Bruce Blinn / Paperback / Published 1995

(Hewlett-Packard Professional Books)

Textbook Binding - 288 pages 1 edition (October 19, 1995)
Prentice Hall; ISBN: 0134514947
Amazon.com Sales Rank: 40,130
Avg. Customer Review: 4.5 out of 5 stars
Number of Reviews: 10

Book Preface - Portable Shell Programming An Extensive Collection of Bourne Shell Examples, 1-e

Review of Portable Shell Programming by by Nick Christenson, npc@jetcafe.org

... After a brief chapter on interpreting command line options in shell scripts, Blinn turns to an extended discussion of the use of sed as a filter for these scripts. The explanation and uses of sed are compact, although they provide enough information to cover the vast majority of the situations for which it is commonly used. A noted absence from the book is that there is no more than passing coverage of the awk programming language, which solves several shell problems more elegantly than other UNIX commands. The complete shell programmer will want to obtain a separate reference to this programming language.

The next several chapters cover shell utilities, including the important and mysterious "IFS" variable, shell functions, and examples of complete and marginally complex shell scripts. The functional explanations are all quite good, and the sample scripts are often useful themselves, and they do a good job of illustrating the use of the concepts presented in preceding chapters.

The next two chapters, on debugging and specific portability issues, are very well thought out and are far and away the best sources of this information I have seen in print. This information is excellent and even an expert shell programmer will almost certainly find something of significant value here. These chapters are followed by a list of common problems and resolutions that shell programmers commonly face. This information is also extremely useful, and it's likely that they will impart significant understanding to most readers. The book ends with a comparison of shells and a summary of the Bourne shell syntax.

The only major downside to this book is it's price. For its size, $40 seems a bit steep to me, but given the quality of the material in the book, it's really quite a bargain. I recommend that every shell programmer should own Portable Shell Programming along with their well worn copy of K&P. I don't think it's necessary to purchase any other books on the topic.

... ... ...

5 out of 5 stars "Practical" is meaningful in this case!, April 10, 1998
dtsmith2 (see more about me) from New York, NY

As opposed to other books with "practical" in the title, this one lives up to its name. I found Chapters 4 (Using Files), 5 (The Environment), and 7 (Using Filters) very helpful. The book is full of many examples of practical things, such as how to delete all blank lines in a file. This makes is valuable for the beginner, and the later chapters contain information for the more advanced shell programmer.

I got this book at a time when the guy who wrote all our shell scripts quit without notice. This book was a lifesaver, as I had to write short (and not so short) shell scripts to automate certain tasks & understand the work he did.

I would like to see more discussion in Chapter 7 (Using Filters) about combining the use of sed and the Unix/Linux command tr. I find that I have to use these together sometimes as one does things the other can't handle. This is the only suggestion I have to improve an already useful book.

4 out of 5 stars excellent, February 27, 2004

pikejl (see more about me) from Stafford, VA United States

If you've done any intoductory shell programming at all, this book will get you started in more serious shell programming efforts. I only gave this book 4 stars although it really deserves more, because it may not live up to the expectations of some readers.

Only the Bourne shell is covered, because it's the most portable. It covers all the basics and many advanced issues. The authors philosphy is to teach by example, and this book is full of examples and sample code.

The first half of the book is a down and dirty "How To by Example." The examples are general enough and well enough documented that the use for the syntaxes described remains clear in the readers mind. The second half of the book contains some sample shell utilities. These are shell programs that were written to mimmick or epxpand on functionality of common UNIX commands. I found the first half of the book to be the most useful over time.

Some explanations may be a bit terse for brand new shell prgrammers. Awk is covered in much detail at all, although there are some very nice examples of using sed. All in all this is the best shell programming reference I've seen.

4 out of 5 stars Great Shell Programming Intro, June 14, 2003

Kevin Taylor (see more about me) from Wheaton, IL United States

The author starts off with the assumption that the reader is technically savvy but has no knowledge of shell scripting. This means that the first chapter necessarily covers basic
syntax such as creating a script file, comments, file name expansion, quotes, control structures, pipes, etc. I found this chapter extremely useful for reviewing the basic building blocks that all shell scripts tend to share. This will be a valuable chapter for someone brand new to shell scripting or Unix-style operating systems. The 4 pages covering quoting was the most lucid coverage I have yet found.

Variable are covered comprehensively in Chapter 2. This chapter covers all the ways of declaring, initializing, assigning and passing variables. It also covers the Bournee shell special variables, such as $?, $$, etc. I learned some new techniques for handling uninitialized variables using special Bournee shell syntax, such as "". This statement causes the script to print out the "message" and then terminate if the "variable" is not initialized.

The author next covers shell functions and built-in commands available in Bournee shell. The 3 pages on shell functions is adequate to illustrate function syntax. The author also does an adequate job of examining function parameters, variables in functions, strategies for reusing functions and the different effects from executing a function in the current shell versus a subshell. The rest of the book shows numerous examples of functions, so the lack
of function examples here is acceptable. Next the author introduces the important built-in
commands such as : (null), . (dot), eval, exec, read, test, wait, and many others. All of the non-obvious commands have an example or two. Most of these commands are also used extensively in the remainder of the book.

The point of most shell scripts is to manipulate files, so I consider the material in Chapter 4 crucial. This chapter does a fine job of explaining the file descriptors (0,1,2) and redirection of input and output. The author then discusses opening, writing, reading,
closing and truncating files. Finally, "here" documents are covered. This is a nifty feature of Bournee shells which allow the creation of "inline" documents.

Bournee shells usually depend on the fact that they are running on a Unix-like system. In other words, most shell scripts interface with the operating system. Chapter 5 details how Bourne scripts interact with the environment they are running in. Coverage includes Environment Variables, child versus parent environments, getting user and system information, using signals, and, finally, remote commands. The coverage is not comprehensive, nor could it be. It would take volumes to comprehensively cover the UNIX environment in relation to shell scripts. With that said, the author presents a respectable subset of the most important topics.

The next short chapter first reviews the UNIX command line conventions, e.g. "command [options] [parameters]". The author then discusses the getopt(s) commands for parsing command line parameters and what to do when these commands are not available.

Filters are commands that get their data from the standard input, perform some transformation on the data, and then write the data to the standard output. More than one filter can be strung together to perform very complex transformations. This chapter presents an introduction to this important topic. The tools illustrated are pipes, sed and awk. This chapter, again, only presents an introduction. But the number of examples is impressive and so is the categorization. With this chapter, Chapter 8 and the man pages for sed and awk, a reader will be in a position to infuse his shell scripts with considerable power.

Chapter 9 and 10 are the culmination of the previous 8 chapters. Chapter 9 provides a library of shell functions that I found highly instructive. The list of functions are: CheckHostname, Clear, DownShift, FullName, GetYesNo, IsNewer, IsNumeric, IsSystemType, Prompt, Question, StrCmp, and, finally, SystemType.

The author presents an assortment of shell scripts that are written to be both instructive and useful. As with the functions in Chapter 9, I found these to be highly instructive. The list of scripts are: Cat, DirCmp, Kill, MkDir, Shar, Wc, addcolumn, dircopy, findcmd, findfile, findstr, hostaddr, and, finally, ptree.

No programming language guide would be complete without the obligatory coverage of debugging. This is an area of personal interest to me, because my experience in the industry has taught me that few programmers leave the university with adequate debugging skills. The art of debugging boils down to a set of heuristics for reproducing or capturing an error, narrowing down the potential causes to a manageable set of candidates, and then progressively simplifying until the exact cause of the problem can be understood and corrected. This chapter will not teach the reader to be a competent debugger. The chapter does illustrate common pitfalls that shell scripts contain. It also discusses the basic elements in tracing through a script and even touches on shell scripting style as a tool to reduce bugs. All good, common sense information.

Considering the title of the book, it would be expected that there would be a chapter on portability. This chapter presents some of the best material I have seen assembled on writing portable shell scripts. The author discusses System V versus BSD, subsets of commands, abstraction, locating commands and files, shell features, issues with a number of specific commands, and file and path names. If you are writing production scripts that may be shipped in a heterogeneous environment, this is required reading.

5 out of 5 stars Five stars for usefulness, November 7, 2002

Ed McGuigan (see more about me) from Boynton Beach, FL United States

Bruce Blinn has written a very useful, highly practical shell programming book.

I am working my way through the book but even after a chapter or two I have started to apply the priceless nuggets I was able to glean.

If you work in a Un*x environment and need to script tedious tasks to allow you more time to get on with the fun stuff, then this will help you.

It is well written and as easily understood as you can reasonably expect when you consider the arcane subject matter.

5 out of 5 stars Awesome Book, May 11, 2001

A reader from Houston, Texas United States

This is a great book. It gets straight to the point, covers everything there is to know about the bourne shell and uses the least amount of words to do it. The author has done a fantasic job!

Unix Shell Programming by Stephen G. Kochan, Patrick H. Wood

**** This is one of the oldest good shell books. First edition was published in 1987 I think. It's interesting to see what people know about shells in late 80th. This is also a book written by the author who knows C well (Stephen G. Kochan also wrote Programming in ANSI C and that shows): the trait lost in later generation of shell book authors ;-)

Amazon price: $23.96
Paperback - 490 pages 2nd Revsd edition (January 1990)
Hayden Books; ISBN: 067248448X ; Dimensions (in inches): 0.84 x 9.10 x 7.41
Amazon.com Sales Rank: 3,561
Avg. Customer Review: 4.5 out of 5 stars
Number of Reviews: 12

5 
out of 5 stars Have taught and used this book for over 5 years., 16 November, 1998
Reviewer: A reader from Tampa, Fl.

I teach at a small college. My students have are inexperienced UNIX users. They love the book. The examples are understandable and helpfull.

I use the book as a reference. I find it equally invaluable. It sits on my bookshelf and is used almost daily. Both myself and my students find this book invaluable for new learning and reference.

5 of 5 stars Dated, but fantastic, May 31, 2001
Reviewer: alex j. avriette (see more about me) from washington, dc
I am a perl and C programmer, and I am very familiar with the shells outlined in this book. So the material was not particularly "new" for me. I can see how it would be difficult to understand for a user who was new to shell programming.

If the intended audience is the intermediate unix user who knows something of programming, this book gets a full 5 star, my seal-of-approval rating. Terrific.

One thing it is lacking is a brief mention of perl or of awk. In many cases, it is simpler to write:

date | awk '{ print $2 }'

instead of:

date | cut -d' ' -f2

or, at least from the standpoint of understandability and readability. but the book doesnt claim to be a manual for awk, and O'Reilly has an excellent book on the subject.

I continually recommend this book to people, and where ever I go, I find this book on the bookshelves of successful people.

3 of 5 stars Somewhat dated...., July 18, 2001
Reviewer: Lee D Carlson (see more about me) from Global Mathematics Inc Saint Louis, Missouri USA

Although published in 1990, this book could still function well as an introduction to UNIX and (Bourne) shell programming, provided one is aware of some changes to the shell in most implementations of UNIX since that date. Also, the Perl language has come on strong in recent years, and depending on your tastes (and time), that language can be used with great efficiency to do the tasks that are traditionally done in the shell.

After a quick review of the basics of UNIX, the authors give a purely descriptive explanation of the UNIX shell in chapter 3. Emphasizing that it is an interpretive language, the most commonly used shell commands are discussed in chapter 4, starting with a discussion of regular expressions. The cut, paste, sed, tr, grep, uniq, and sort commands are treated in detail.

In chapter 5, one begins the actual task of creating shell programs using shell variables. There is no data typing in the shell, so values can be assigned to variables without noting their type as integer, float, etc. The authors only briefly discuss the mechanism in shell programming. The method by which the shell interprets quotation characters is covered in the next chapter. The single, double, backslash, and back quote characters are discussed in detail. Noting that arithmetic operations are done on values stored in variables in the shell, the authors show to proceed with these operations using the expr program.

The mechanisms for passing arguments to shell programs is treated in chapter 7, the authors showing how to write shell programs that take arguments typed on the command line. The role of positional variables for delaying assignment after normal command line processing is discussed. The $#, and $* variables are discussed briefly, with $# getting set to the number of arguments typed on the command line and $* used for programs taking a variable number of arguments. The shift command is explained well as a method to allow one to use more than nine arguments to a program.

The ability of shell programs to execute decision blocks is treated in chapter 8, via the if statement. The role of the test and exit commands are in if blocks are discussed in good detail. In addition, the case command, familiar to C programmers is introduced as a technique to allow a single value to be compared against other values. The && and || constructs are used to show the reader how to execute commands that are contingent on the success or failure of the preceding command.

Program loops, via the for, while, and until commands are discussed in chapter 9, followed in the next chapter by a discussion of how to read data from the terminal or from a file using the read command. The ability to perform I/O redirection is discussed also.

Local and export variables are discussed in the next chapter on the user environment, and the authors give a good summary of how these work in shell programming. More discussion on parameter passing is done in chapter 12, with the different methods of parameter substitution given detailed treatment. The authors show how to use the $0 variable to check whether two or more programs have been executed, and how to use the set command to set shell options and to reassign positional parameters. This is followed in the next chapter by a discussion of the eval command, which makes the shell scan the command line twice before executing it, and the wait command, which will allow serialization in program execution. The trap and type commands are discussed also.

The Korn shell is discussed in chapter 15, with emphasis on the features added to Korn shell that cannot be found in the Bourne shell. The vi and emacs capability of this shell is briefly discussed in this chapter. The differences between Korn shell functions and Bourne shell functions are discussed in detail by the authors. Most importantly, the ability of the Korn shell to do integer arithmetic without using the expr command is discussed via the let command, which is built-in to the Korn shell. Also, the capability of the Korn shell to support data typing is discussed, along with its pattern matching capabilities. Pattern matching is done most efficiently now using Perl however.

The Bourne Shell Quick Reference Guide by Anatole Olczak (Paperback - March 1998)
Amazon price: $6.36


Dtksh and X-Windows

Desktop Kornshell Graphical Programming (Addison-Wesley Professional Computing)

J. Stephen Pendergrast, Jr.

New Price: $53.25
Used Price: $38.99

Hardcover (June 1995)
Addison-Wesley Pub Co; ISBN: 0201633752

The Shell Hacker's Guide to X and Motif (Wiley Professional Computing)

Alan Southerton / Paperback / Published 1994


Csh/Tsch

Teach Yourself the Unix C Shell in 14 Days (Unix Library)

David Ennis, James C., Jr. Armstrong / Paperback / Published 1994

Unix C Shell Field Guide

Gail Anderson, Paul Anderson / Paperback / Prentice Hall /ISBN: 0-13-937468-X

C Shell Programming

William N Franklin / Paperback / Published 1997

Using Csh and Tcsh (Nutshell Handbook)

Paul Dubois

C Shell Quick Reference Guide


Etc



Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least


Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

 

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: May 01, 2018