دانلود کتاب اصطلاحات bash – اسکریپت های شل قدرتمند، انعطاف پذیر و خوانا بنویسید

Webster’s Dictionary defines idiom as:1 1: an expression in the usage of a language that is peculiar to itself either in having a meaning that cannot be derived from the conjoined meanings of its elements (such as up in the air for “undecided”) or in its grammatically atypical use of words (such as give way) 2a: the language peculiar to a people or to a district, community, or class: dialect 2b: the syntactical, grammatical, or structural form peculiar to a language 3: a style or form of artistic expression that is characteristic of an individual, a period or movement, or a medium or instrument Why bash Idioms? One word—readability. Or perhaps a different word—understandability. In this book, those words mean the same thing. We don’t have to convince you that readability is critically important; unless this is the first book about programming you are reading,2 you already get it. Readability means being able to read and understand code, especially code that someone else wrote, but it also means being able to write code that you, or someone else, can later read and understand. Clearly these aspects are different sides of the same coin, so we’ll explore both the clear idioms to use and the obscure ones to avoid. We think of bash, informally, as a language to use to “run things.” If you need to do a lot of heavy data processing, bash may not be the first choice. You can do it, but it might not be pretty. Of course, if you already have the data processing tools you need and you just have to “glue” them together, well, then bash is great. But if all we do is run things, why do we care about the idioms of the language or its “structural form”? Programs grow, features creep, things change, and there is nothing more permanent than a “temporary solution.” Sooner or later someone is going to have to read the code, understand it, and make changes. If it’s written using an obscure idiom, the job is that much harder.