Bash Cookbook: 英文原版，Shell脚本编程指南

需积分: 10 197 浏览量更新于2024-07-18 收藏 9.41MB PDF 举报

"Bash Cookbook 英文原版，由 Carl Albing, JP Vossen 和 Cameron Newham 合著，是一本关于Bash Shell脚本编程的专业书籍，旨在帮助读者解决与数据处理相关的各种问题。" 本书详细探讨了Bash（Bourne-Again SHell）的使用技巧和高级特性，是Linux和Unix用户、系统管理员以及数据科学家的重要参考资料。在描述中提到的“Bad Data”指的是那些妨碍工作的数据，可能是由于存储问题、数据表示不准确或政策误导导致的。在数据科学领域工作的人迟早会遇到这些问题，而这本书提供了应对这些问题的策略和解决方案。书中涵盖了以下关键知识点： 1. **Bash基础知识**：包括命令行接口（CLI）的基本操作，如文件和目录管理、管道、重定向和输入/输出重定向。 2. **Shell脚本编写**：讲解如何创建和运行Bash脚本，包括变量、条件语句、循环结构、函数定义和错误处理。 3. **命令行工具**：介绍grep、sed、awk等强大的文本处理工具，用于数据过滤、搜索和转换。 4. **数据处理**：讲解如何利用Bash处理和分析数据，特别是在没有专门数据分析工具的情况下。 5. **错误排查**：提供处理坏数据的方法，包括数据清洗、格式化和验证。 6. **自动化任务**：通过脚本实现日常任务的自动化，提高工作效率。 7. **环境变量和配置**：讨论如何设置和使用环境变量，以及优化Shell配置。 8. **函数和脚本库**：创建可重用的代码片段，构建自己的Bash函数库。 9. **调试和测试**：学习如何调试Bash脚本，确保其正确性和可靠性。 10. **安全实践**：强调在编写脚本时应考虑的安全问题，如权限控制和防止注入攻击。 11. **案例研究**：书中包含多个实际案例，展示如何应用所学知识解决具体问题。 12. **最佳实践**：分享作者们的经验和建议，帮助读者形成良好的Shell编程习惯。《Bash Cookbook》不仅适合初学者入门，也对有经验的Bash用户提供了深入的见解和技巧。通过阅读本书，读者能够提升自己在Shell脚本编写方面的技能，更有效地管理和处理数据，解决实际工作中遇到的问题。

Preface

About This Book

This book covers bash, 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. While these and other shells such as dash,

and zsh are not specifically covered, odds are that most of the scripts will work pretty

well with them.

You should be able to read this book cover to cover, and also just pick it up and read

anything that catches your eye. But perhaps most importantly, we hope that when

you have a question about how to do something or you need a hint, you will be able

to easily find the right answer—or something close enough—and save time and

effort.

A great part of the Unix philosophy is to build simple tools that do one thing well,

then combine them as needed. This combination of tools is often accomplished via a

shell script because these commands, called pipelines, can be long or difficult to

remember and type. Where appropriate, we’ll cover the use of many of these tools in

the context of the shell script as the glue that holds the pieces together to achieve the

goal.

This book was written using OpenOffice.org Writer running on whatever Linux or

Windows machine happened to be handy, and kept in Subversion (see Appendix D).

The nature of the Open Document Format facilitated many critical aspects of writ-

ing this book, including cross-references and extracting code see Recipe 13.17, “Pro-

cessing Files with No Line Breaks.”

GNU Software

bash, and many of the tools we discuss in this book, are part of the GNU Project

(http://www.gnu.org/). GNU (pronounced guh-noo, like canoe) is a recursive acro-

nym for “GNU’s Not Unix” and the project dates back to 1984. Its goal is to develop

a free (as in freedom) Unix-like operating system.

Without getting into too much detail, what is commonly referred to as Linux is, in

fact, a kernel with various supporting software as a core. The GNU tools are wrapped

around it and it has a vast array of other software possibly included, depending on

your distribution. However, the Linux kernel itself is not GNU software.

The GNU project argues that Linux should in fact be called “GNU/Linux” and they

have a good point, so some distributions, notably Debian, do this. Therefore GNU’s

goal has arguably been achieved, though the result is not exclusively GNU.

The GNU project has contributed a vast amount of superior software, notably

including bash, but there are GNU versions of practically every tool we discuss in

this book. And while the GNU tools are more rich in terms of features and (usually)

friendliness, they are also sometimes a little different. We discuss this in Recipe 15.3,

xvi

Preface

“Developing Portable Shell Scripts,” though the commercial Unix vendors in the

1980s and 1990s are also largely to blame for these differences.

Enough (several books this size worth) has already been said about all of these

aspects of GNU, Unix, and Linux, but we felt that this brief note was appropriate.

See http://www.gnu.org for much more on the topic.

A Note About Code Examples

When we show an executable piece of shell scripting in this book, we typically show

it in an offset area like this:

$ ls

a.out cong.txt def.conf file.txt more.txt zebra.list

The first character is often a dollar sign ($) to indicate that this command has been

typed at the bash shell prompt. (Remember that you can change the prompt, as in

Recipe 16.2, “Customizing Your Prompt,” so your prompt may look very different.)

The prompt is printed by the shell; you type the remainder of the line. Similarly, the

last line in such an example is often a prompt (the

$ again), to show that the com-

mand has ended execution and control has returned to the shell.

The pound or hash sign (#) is a little trickier. In many Unix or Linux files, including

bash shell scripts, a leading # denotes a comment, and we have used it that way in

some out our code examples. But as the trailing symbol in a bash command prompt

(instead of $), # means you are logged in as root. We only have one example that is

running anything as root, so that shouldn’t be confusing, but it’s important to

understand.

When you see an example without the prompt string, we are showing the contents of

a shell script. For several large examples we will number the lines of the script,

though the numbers are not part of the script.

We may also occasionally show an example as a session log or a series of com-

mands. In some cases, we may

cat one or more files so you can see the script and/or

data files we’ll be using in the example or in the results of our operation.

$ cat data_file

static header line1

static header line2

1 foo

2 bar

3 baz

Many of the longer scripts and functions are available to download as well. See the

end of this Preface for details. We have chosen to use

#!/usr/bin/env bash for these

examples, where applicable, as that is more portable than the

#!/bin/bash you will

see on Linux or a Mac. See Recipe 15.1, “Finding bash Portably for #!” for more

details.

Preface

xvii

Also, you may notice something like the following in some code examples:

# cookbook filename: snippet_name

That means that the code you are reading is available for download on our site

(http://www.bashcookbook.com).Thedownload(.tgz or .zip)isdocumented,but

you’ll find the code in something like ./chXX/snippet_name,wherechXX is the

chapter and snippet_name is the name of the file.

Useless Use of cat

Certain Unix users take a positively giddy delight in pointing out inefficiencies in

other people’s code. Most of the time this is constructive criticism gently given and

gratefully received.

Probably the most common case is the so-called “useless use of cat award” bestowed

when someone does something like

cat file | grep foo instead of simply grep foo

file

. In this case, cat is unnecessary and incurs some system overhead since it runs in

a subshell. Another common case would be

cat file | tr '[A-Z]' '[a-z]' instead of

tr '[A-Z]' '[a-z]' < file. Sometimes using cat can even cause your script to fail (see

Recipe 19.8, “Forgetting That Pipelines Make Subshells”).

But... (you knew that was coming, didn’t you?) sometimes unnecessarily using cat

actually does serve a purpose. It might be a placeholder to demonstrate the fragment

of a pipeline, with other commands later replacing it (perhaps even

cat -n). Or it

might be that placing the file near the left side of the code draws the eye to it more

clearly than hiding it behind a

< on the far right side of the page.

While we applaud efficiency and agree it is a goal to strive for, it isn’t as critical as it

once was. We are not advocating carelessness and code-bloat, we’re just saying that

processors aren’t getting any slower any time soon. So if you like cat, use it.

A Note About Perl

We made a conscious decision to avoid using Perl in our solutions as much as possi-

ble, though there are still a few cases where it makes sense. Perl is already covered

elsewhere in far greater depth and breadth than we could ever manage here. And Perl

is generally much larger, with significantly more overhead, than our solutions. There

is also a fine line between shell scripting and Perl scripting, and this is a book about

shell scripting.

Shell scripting is basically glue for sticking Unix programs together, whereas Perl

incorporates much of the functionality of the external Unix programs into the lan-

guage itself. This makes it more efficient and in some ways more portable, at the

expense of being different, and making it harder to efficiently run any external pro-

grams you still need.

剩余623页未读，继续阅读

rockyhoo

粉丝: 0
资源: 3

Bash Cookbook: 英文原版，Shell脚本编程指南

Advanced Bash-Scripting Guide 英文原版

英文原版-Bash Pocket Reference 2nd Edition

bash -c bash

bash shell的bash

命令行bash test.bash

#!/bin/bash gnome-terminal -- bash -c 'bash 1.sh; exec bash' gnome-terminal -- bash -c 'bash task1.sh; exec bash'

git bash修改bash

bash test.bash

怎么用bash关闭另外一个bash用bash关闭另外一个bash

bash: bash: command not found

最新资源