For sufficiently simple cases, just running a few commands sequentially, with no subshells, conditional logic, or loops, set -euo pipefail is sufficient (and make sure you use shellcheck -o all).

The bash manual contains the statement For almost every purpose, aliases are superseded by shell functions.

Functions are much more flexible than aliases. The following would overload the usual ls with a version that always does ls -F (arguments are passed in $@, including any flags that you use), pretty much as the alias alias ls="ls -F" would do: ls () { command ls -F "$@" }

shopt -s lastpipe

pe() { for _i;do printf "%s" "$_i";done; printf "\n"; } pl() { pe;pe "-----" ;pe "$*"; } db() { ( printf " db, ";for _i;do printf "%s" "$_i";done;printf "\n" ) >&2 ; } db() { : ; }

type

# line containing 'cake' but not 'at' # same as: grep 'cake' table.txt | grep -v 'at' # with PCRE: grep -P '^(?!.*at).*cake' table.txt $ awk '/cake/ && !/at/' table.txt blue cake mug shirt -7

== and != for string comparison -eq, -ne, -gt, -lt, -le -ge for numerical comparison

> will overwrite the current contents of the file, if the file already exists. If you want to append lines instead, use >>

The syntax for “redirecting” some output to stderr is >&2. > means “pipe stdout into” whatever is on the right, which could be a file, etc., and &2 is a reference to “file descriptor #2” which is stderr.

single quotes, which don’t expand variables

This only works if you happen to have Bash installed at /bin/bash. Depending on the operating system and distribution of the person running your script, that might not necessarily be true! It’s better to use env, a program that finds an executable on the user’s PATH and runs it.

This runs a loop 555 times. Takes a screenshot, names it for the loop number with padded zeros, taps the bottom right of the screen, then waits for a second to ensure the page has refreshed. Slow and dull, but works reliably.

#!/bin/bash
for i in {00001..00555}; do
   adb exec-out screencap -p > $i.png
   adb shell input tap 1000 2000
   sleep 1s
done
echo All done

the whole language is a shame, but it's so useful :)

:w !sudo tee %

bro：以用例为主的帮助系统man 以外的帮助系统有很多，除去 cheat, tldr 外，还有一款有意思的帮助系统 -- bro，它是以用例为主的帮助，所有用例都是由用户提供，并且由用户投票筛选出来的：<img src="https://pica.zhimg.com/50/v2-cebd65810604c26de9dbc7a697c72dd3_720w.jpg?source=1940ef5c" data-caption="" data-size="normal" data-rawwidth="801" data-rawheight="529" class="origin_image zh-lightbox-thumb" width="801" data-original="https://pica.zhimg.com/v2-cebd65810604c26de9dbc7a697c72dd3_r.jpg?source=1940ef5c"/>

cheat：命令行笔记就是各种 cheat sheet ，比如经常搞忘 redis 命令的话，你可以新建 ~/.cheat/redis 这个文件，写一些内容，比如：cat /etc/passwd | redis-cli -x set mypasswd redis-cli get mypasswd redis-cli -r 100 lpush mylist x redis-cli -r 100 -i 1 info | grep used_memory_human: redis-cli --eval myscript.lua key1 key2 , arg1 arg2 arg3 redis-cli --scan --pattern '*:12345*'

pm：在 bash / zsh 中迅速切换项目目录

special permission bit at the end here t, this means everyone can add files, write files, modify files in the /tmp directory, but only root can delete the /tmp directory

git ls-files is more than 5 times faster than both fd --no-ignore and find

If we call this using Bash, it never gets further than the exec line, and when called using Python it will print lol as that's the only effective Python statement in that file.

#!/bin/bash
"exec" "python" "myscript.py" "$@"
print("lol")

For Python the variable assignment is just a var with a weird string, for Bash it gets executed and we store the result.

Given all that, I simply do not understand why people keep recommending the {} syntax at all. It's a rare case where you'd want all the associated issues. Essentially, the only "advantage" of not running your functions in a subshell is that you can write to global variables. I'm willing to believe there are cases where that is useful, but it should definitely not be the default.

All we've done is replace the {} with (). It may look like a benign change, but now, whenever that function is invoked, it will be run within a subshell.

$@ is all of the parameters passed to the script. For instance, if you call ./someScript.sh foo bar then $@ will be equal to foo bar.

GIT_PAGER= git diff

The best practice is this: #!/usr/bin/env bash #!/usr/bin/env sh #!/usr/bin/env python

Here's my bash boilerplate with some sane options explained in the comments

set -euo pipefail

It basically takes any command line arguments passed to entrypoint.sh and execs them as a command. The intention is basically "Do everything in this .sh script, then in the same shell run the command the user passes in on the command line".

#!/bin/bash
set -e

... code ...

exec "$@"

${0%/*} removes everything including and after the last / in the filename ${0##*/} removes everything before and including the last / in the filename

The alternative for curl is a credential file: A .netrc file can be used to store credentials for servers you need to connect to.And for mysql, you can create option files: a .my.cnf or an obfuscated .mylogin.cnf will be read on startup and can contain your passwords.

Linux keyring offers several scopes for storing keys safely in memory that will never be swapped to disk. A process or even a single thread can have its own keyring, or you can have a keyring that is inherited across all processes in a user’s session. To manage the keyrings and keys, use the keyctl command or keyctl system calls.

Docker container can call out to a secrets manager for its secrets. But, a secrets manager is an extra dependency. Often you need to run a secrets manager server and hit an API. And even with a secrets manager, you may still need Bash to shuttle the secret into your target application.

Using environment variables for secrets is very convenient. And we don’t recommend it because it’s so easy to leak things

As the sanitized example shows, a pipeline is generally an excellent way to pass secrets around, if the program you’re using will accept a secret via STDIN.

A few notes about storing and retrieving file secrets

After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.

As it stands, sudo -i is the most practical, clean way to gain a root environment. On the other hand, those using sudo -s will find they can gain a root shell without the ability to touch the root environment, something that has added security benefits.

Much like sudo su, the -i flag allows a user to get a root environment without having to know the root account password. sudo -i is also very similar to using sudo su in that it’ll read all of the environmental files (.profile, etc.) and set the environment inside the shell with it.

This means that unlike a command like sudo -i or sudo su, the system will not read any environmental files. This means that when a user tells the shell to run sudo -s, it gains root but will not change the user or the user environment. Your home will not be the root home, etc. This command is best used when the user doesn’t want to touch root at all and just wants a root shell for easy command execution.

Though there isn’t very much difference from “su,” sudo su is still a very useful command for one important reason: When a user is running “su” to gain root access on a system, they must know the root password. The way root is given with sudo su is by requesting the current user’s password. This makes it possible to gain root without the root password which increases security.

“su” is best used when a user wants direct access to the root account on the system. It doesn’t go through sudo or anything like that. Instead, the root user’s password has to be known and used to log in with.

you can use "${@:1}" instead of shift, but that requires bash instead of sh in your #! shebang. IMHO your original shift approach is simpler and better

while : # This is the same as "while true".

There's a bash debugger, bashdb, which is an installable package on many distros. It uses bash's built-in extended debugging mode (shopt -s extdebug).

yell() { echo "$0: $*" >&2; } die() { yell "$*"; exit 111; } try() { "$@" || die "cannot $*"; }

If you were to check the return status of every single command, your script would look like this:

However, this construct is not completely equivalent to if ... fi in the general case.

[[ -z "$a" || -z "$b" ]] && usage

Note that the double quotes around "${arr[@]}" are really important. Without them, the for loop will break up the array by substrings separated by any spaces within the strings instead of by whole string elements within the array. ie: if you had declare -a arr=("element 1" "element 2" "element 3"), then for i in ${arr[@]} would mistakenly iterate 6 times since each string becomes 2 substrings separated by the space in the string, whereas for i in "${arr[@]}" would iterate 3 times, correctly, as desired, maintaining each string as a single unit despite having a space in it.

Sadly, bash can't handle long options which would be more readable, i.e.:

I have used this bash one-liner before set -- "${@:1:$(($#-1))}" It sets the argument list to the current argument list, less the last argument.

Changing a user’s default Shell to bash v5

sdiff

So be careful running editing a bash script that may be currently executing. It could execute an invalid command, or do something very surprising.

readonly TUX=penguinpower

function foo { local -n data_ref=$1 echo ${data_ref[a]} ${data_ref[b]} } declare -A data data[a]="Fred Flintstone" data[b]="Barney Rubble" foo data

How To Create a Sudo User on Ubuntu

echo "scale=2; 2/3" | bc .

break : . continue eval exec exit export readonly return set shift trap unset

(set -f; IFS=:; printf "%s\n" $PATH)

From Bash to Zsh

zsh will be the default login shell for new accounts, and even then, you can select bash instead

Apple replaced Bourne Again SHell with Z shell for licensing reasons

One thing to consider is that getting used to this being enabled in your profile may result in some confusion if you run into a situation where your personalized profile configuration isn't applied (rebuilt machine, shell scripts which may run on other machines, etc). There's some benefit to sticking close to defaults. This is definitely a conservative viewpoint, however.

ps f

It’s worth noting that first line of the script starts with #!. It is a special directive which Unix treats differently.

When you execute commands in non login shell like ssh server command or scp file server:~ or sudo(without -i) or su (without -l) it will execute ~/.bashrc

open a login shell which sources ~/.bash_profile

The point of the .bashrc file is that it sets the shell up to be more convenient for interactive users. Helpful alias, pretty colors, useful prompts, common environment variables, that sort of thing. And some of these conveniences could break non-interactive scripts.

The main benefit I can see to having .bashrc sourced when running a (non-interactive) remote command is that shell functions can be run. However, most of the commands in a typical .bashrc are only relevant in an interactive shell

I discovered that remote shells are treated differently. While non-interactive Bash shells don’t normally run ~/.bashrc commands at start-up, a special case is made when the shell is Invoked by remote shell daemon:

This has the consequence that if the .bashrc contains any commands that print to standard output, file transfers will fail, e.g, scp fails without error.

COMMAND EXECUTE BASHRC -------------------------------- bash -c foo NO bash foo NO foo NO rsh machine ls YES (for rsh, which calls `bash -c') rsh machine foo YES (for shell started by rsh) NO (for foo!) echo ls | bash NO login NO bash YES

If you want happy cow messages when you login change your bash_profile.

AFAIK, the right way to enable un-hindered scp is less about which conditional for stdout in your ~/.bashrc script, and more about simply restricting screen output to the ~/.bash_profile script. At least that is how it works for my distro (CentOS.) Edit for clarity: Put only lines in your ~/.bashrc file as required by "all" remote conections

So, though normally bash would not run ~/.bashrc for a non-interactive shell, with ssh it does so anyway.

For those (like me) wondering why is the space needed, man bash has this to say about it: > Note that a negative offset must be separated from the colon by at least one space to avoid being confused with the :- expansion.

将错误IP放到数组里面判断是否ping失败三次

#!/bin/bash  
IP_LIST="192.168.18.1 192.168.1.1 192.168.18.2"
for IP in $IP_LIST; do
    NUM=1
    while [ $NUM -le 3 ]; do
        if ping -c 1 $IP > /dev/null; then
            echo "$IP Ping is successful."
            break
        else
            # echo "$IP Ping is failure $NUM"
            FAIL_COUNT[$NUM]=$IP
            let NUM++
        fi
    done
    if [ ${#FAIL_COUNT[*]} -eq 3 ];then
        echo "${FAIL_COUNT[1]} Ping is failure!"
        unset FAIL_COUNT[*]
    fi
done

获取随机8位字符串：

方法1：
# echo $RANDOM |md5sum |cut -c 1-8
471b94f2
方法2：
# openssl rand -base64 4
vg3BEg==
方法3：
# cat /proc/sys/kernel/random/uuid |cut -c 1-8
ed9e032c

获取随机8位数字：

# echo $RANDOM |cksum |cut -c 1-8
23648321
方法2：
# openssl rand -base64 4 |cksum |cut -c 1-8
38571131
方法3：
# date +%N |cut -c 1-8
69024815

注意事项

You do that using backticks: echo World > file.txt

Shell Utilities for QC

Process Substitution

${FUNCNAME[@]}

while IFS='=' read -r col1 col2 do echo "$col1" echo "$col2" done <testprop.properties

In Bash you quite often need to check to see if a variable has been set or has a value other than an empty string. This can be done using the -n or -z string comparison operators.

;

Perl script in bash's HereDoc

Associative arrays in bash

.

strings $PWD/bin/myapp | egrep '\.gcda$'

A shell script is a file of executable commands that has been stored in a text file. When the file is run, each command is executed.

Counting number of lines

-print0

What is missing is a space between the $( and the following (, to avoid the arithmetic expression syntax. The section on command substitution in the shell command language specification actually warns for that: