for cpp_file in *.cpp; do gcc -c $$cpp_file & done; wait This gives much finer control than make -j.

There is one very important reason for enabling job control to be useful inside scripts: the side-effect it has of placing background processes in their own process groups. This makes it much, much easier to send signels to them and their children with one simple command: kill -<signal> -$pgid. All other ways of dealing with signaling entire trees of processes either involve elaborate (sometimes even recursive) functions, which are often bugnests, or risk killing the parent in the process (no pun intended).

To avoid the problems with different versions of echo you may want to use printf instead. In contrast to echo printf always interprets \ sequences but doesn't automatically add a linefeed at the end so you have to append \n at the end if you want one.

while (( "$#" )); do case "$1" in -a|--my-boolean-flag) MY_FLAG=0 shift ;; -b|--my-flag-with-argument) if [ -n "$2" ] && [ ${2:0:1} != "-" ]; then MY_FLAG_ARG=$2 shift 2 else echo "Error: Argument for $1 is missing" >&2 exit 1 fi ;; -*|--*=) # unsupported flags echo "Error: Unsupported flag $1" >&2 exit 1 ;; *) # preserve positional arguments PARAMS="$PARAMS $1" shift ;; esacdone# set positional arguments in their proper placeeval set -- "$PARAMS"

As a general rule: You should quote everything (that may be quoted).

For filter-branch, using pipelines like git ls-files | grep -v ... | xargs -r git rm might be a reasonable workaround but can get unwieldy and isn't as straightforward for users; plus those commands are often operating-system specific (can you spot the GNUism in the snippet I provided?)

However, the place where pip places that package might not be in your $PATH (thus requiring you to manually update your $PATH afterwards), and on windows the pip install might not take care of python-specific issues for you (see "Notes for Windows Users", above). As such, installation via package managers is recommended instead.

the bullet-proof way to add a path (e.g., ~/opt/bin) to the PATH environment variable is PATH="${PATH:+${PATH}:}~/opt/bin"

The command nix-shell will build the dependencies of the specified derivation, but not the derivation itself. It will then start an interactive shell in which all environment variables defined by the derivation path have been set to their corresponding values, and the script $stdenv/setup has been sourced. This is useful for reproducing the environment of a derivation for development.

source $stdenv/setup
genericBuild

$ ./my_script Will end up in STDOUT(terminal) and /var/log/messages $ tail -n1 /var/log/messages Sep 23 15:54:03 wks056 my_script_tag[11644]: Will end up in STDOUT(terminal) and /var/log/messages

exec &> >(tee -a "$log_file")

exec &> >(tee -a "$log_file") echo "This will be logged to the file and to the screen" $log_file will contain the output of the script and any subprocesses, and the output will also be printed to the screen.

Write stderr and stdout to a file, display stderr on screen (on stdout) exec 2> >(tee -a -i "$HOME/somefile.log") exec >> "$HOME/somefile.log" Useful for crons, so you can receive errors (and only errors) by mail

I just wanted to point out that the syntax is not supported by the POSIX standard and thus won't universally work in /bin/sh scripts (many people erroneously use bash syntax in /bin/sh scripts)

exec > >(tee "$HOME/somefile.log") 2>&1

#!/bin/sh # -*- tcl -*- # The next line is executed by /bin/sh, but not tcl \ exec tclsh "$0" ${1+"$@"}

When you have a pipeline, unbuffer must be applied to each element except the last (since that doesn't have its output redirected). Example: unbuffer p1 | unbuffer p2 | unbuffer p3 | p4

Operating systems implement a command-line interface in a shell for interactive access to operating system functions or services.

empty is an utility that provides an interface to execute and/or interact with processes under pseudo-terminal sessions (PTYs). This tool is definitely useful in programming of shell scripts designed to communicate with interactive programs like telnet, ssh, ftp, etc.

can be easily invoked directly from shell prompt or script

#!/bin/sh
empty -f -i in -o out telnet foo.bar.com
empty -w -i out -o in "ogin:" "luser\n"

#!/usr/bin/expect

spawn telnet foo.bar.com 
expect ogin {send luser\r}

does not use TCL, Perl, PHP, Python or anything else as an underlying language is written entirely in C has small and simple source code can easily be ported to almost all UNIX-like systems

The quirky looking printf is necessary to correctly expand the script's arguments in $@ while protecting possibly quoted parts of the command (see example below).

xargs -i sh -c 'test -f {} && echo {}'

If a program receives file names as arguments, don't join them with spaces. Use "$@" to access them one by one.

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

Given the deskopen script, you can use a reference to it as the shebang line in a .desktop file

Now this probably won't make difference in the real world (e.g. because the exit codes are not portable and on top of that not always unambiguous as discussed in Default exit code when process is terminated?)

non-interactive shells (actually when job control is not enabled)

In any case signal handling in shells is one of the least reliable and portable aspects. You'll find behaviours vary greatly between shells and often between different versions of a same shell. Be prepared for some serious hair pulling and head scratching if you're going to try to do anything non-trivial.

for sig in $(kill -l) ; do trap "echo parent:$sig" $sig done

read -rep $'\nDo you wish to stop playing?(y/n)' yn

You also need job controlled -monitoring in your parent so it keep track of its children. wait, for example, only works at all with job control. -monitor mode is how shells interact with terminals.

The parentheses always start a subshell. What's happening is that bash detects that sleep 5 is the last command executed by that subshell, so it calls exec instead of fork+exec. The sleep command replaces the subshell in the same process.

if the process does not react on a normal kill, you may want to add an additional kill -9 a few seconds afterwards.

example: get an environment which is used to build irssi (also see nix-shell) $ nix-build $NIXPKGS --run-env -A irssi example: get a persistent environment which is used to build irssi $ nix-build $NIXPKGS --run-env -A irssi --add-root

C.12. Release 1.6 (2013-09-10)In addition to the usual bug fixes, this release has several new features:The command nix-build --run-env has been renamed to nix-shell.

Never use x && y || z when y can return a non-zero exit status.

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

If it's closing the "window" likely you're putting the exit # command inside a function, not a script. (In which case use return # instead.)

Bash (like all Bourne shells) has a special syntax for referring to the list of positional parameters one at a time, and $* isn't it. Neither is $@. Both of those expand to the list of words in your script's parameters, not to each parameter as a separate word.

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

The potential problem: if second_task fails, third_task will not run, and execution will continue to the next line of code - next_task, in this example. This may be exactly the behavior you want. Alternatively, you may be intending that if second_task fails, the script should immediately exit with its error code. In this case, the best choice is to use a block - i.e., curly braces: first_task && { second_task third_task } next_task Because we are using the -e option, if second_task fails, the script immediately exits.

When people write COND && COMMAND, typically they mean "if COND succeeds (or is boolean true), then execute COMMAND. Regardless, proceed to the next line of the script." It's a very convenient shorthand for a full "if/then/fi" clause.

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

It starts truncating it's output (shortening strings with ...) once you pipe it's output into grep. That is quite unacceptable. When I am checking if something is inhibited in a script, I should have all possible information available and not have to consider if a string will get truncated when being piped into a tool, that is perfectly readable on a wide terminal.

An even more general version that allows using find options:

readlink is not part of the standard. A portable script could be implemented with only POSIX shell features.

the following seems to do it without the bashism

Variables - Part 1

*

begins with a special symbol: #. This marks the line as a comment

Philosophy

Note that to make a file executable, you must set the eXecutable bit, and for a shell script, the Readable bit must also be set:

Shell Scripting Tutorial

You can also nest brace expansion lists in the mkdir command. For example, in the articles subdirectory under the htg directory, we want to create two subdirectories called new and rewritten. So, we type the following command at the prompt and press Enter. mkdir -p htg/{articles/{new,rewrites},images,notes,done}

The most commonly supported tool for this is kerl. Kerl is a wrapper around downloading, compiling, and loading various Erlang/OTP versions on a single system, and will abstract away most annoying operations.

{ read foo ; read filesystem size using avail prct mountpoint ; } < <(df -k /)

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.

Invert the exit code of a process. Make 0 into 1 and everything else into a 0. An alternative to ! some-command syntax present in some shells.

Apple replaced Bourne Again SHell with Z shell for licensing reasons

And I continue to tell people: Friends don't let friends write bash script.

# Add auto-completion and a stored history file of commands to your Python # interactive interpreter. Requires Python 2.0+, readline. Autocomplete is # bound to the Esc key by default (you can change it - see readline docs). # # Store the file in ~/.pystartup, and set an environment variable to point # to it: "export PYTHONSTARTUP=~/.pystartup" in bash. import atexit import os import readline import rlcompleter historyPath = os.path.expanduser("~/.pyhistory") def save_history(historyPath=historyPath): import readline readline.write_history_file(historyPath) if os.path.exists(historyPath): readline.read_history_file(historyPath) atexit.register(save_history) del os, atexit, readline, rlcompleter, save_history, historyPath

ps f

\curl

Point to be noted is, there is a backslash before curl. This prevents misbehaving if you have aliased it with configuration in your ~/.curlrc file.

As for exec, I am just using it because it makes sense to run the final command in the same process, replacing the wrapper script instead of spawning a new process. It's not strictly necessary.

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.

Do not start ssh-agent from .bashrc or .zshrc, since these files are executed by each new interactive shell. The place to start ssh-agent is in a session startup file such as .profile or .xsession.

Open3.capture2e

将错误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

注意事项

#!/bin/sh(cat <<EOFstart(){    echo "start"}EOF) >/tmp/b

;

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.

Run nm-tool | grep \*. That should show just the line with the SSID you are connected to.

You can push an alternative branch to Heroku using Git. git push heroku-dev test:master This pushes your local test branch to the remote's master branch (on Heroku).

Every shell has some startup files that it consults for its configuration. Zsh has system-wide startup items in /etc/ (or, in distributions such as Ubuntu, in /etc/zsh/) and user-specific startup files (in the home directory). When Zsh starts up, it reads the following things in this order: /etc/zshenv and ~/.zshenv If the shell is a login shell: /etc/zprofile and ~/.zprofile If it’s an interactive shell: /etc/zshrc and ~/.zshrc If the shell is a login shell: /etc/zlogin and ~/.zlogin And when a user logs out from a login shell, Zsh reads /etc/zlogout and ~/.zlogout. To work out which commands you have to write in which startup files, it's important to know the different types of shells. A login shell is one that's spawned when you log in - for example, via SSH or on a virtual terminal. An interactive shell displays a prompt to the user where you can type commands - for instance, when you open a terminal window in Ubuntu. However, if you run ssh host somecommand, then this is a login shell, but is in fact a non-interactive one.

Every shell has some startup files that it consults for its configuration. Zsh has system-wide startup items in /etc/ (or, in distributions such as Ubuntu, in /etc/zsh/) and user-specific startup files (in the home directory). When Zsh starts up, it reads the following things in this order: /etc/zshenv and ~/.zshenv If the shell is a login shell: /etc/zprofile and ~/.zprofile If it’s an interactive shell: /etc/zshrc and ~/.zshrc If the shell is a login shell: /etc/zlogin and ~/.zlogin And when a user logs out from a login shell, Zsh reads /etc/zlogout and ~/.zlogout. To work out which commands you have to write in which startup files, it's important to know the different types of shells. A login shell is one that's spawned when you log in - for example, via SSH or on a virtual terminal. An interactive shell displays a prompt to the user where you can type commands - for instance, when you open a terminal window in Ubuntu. However, if you run ssh host somecommand, then this is a login shell, but is in fact a non-interactive one.

There's also a function periodic() that is executed every PERIOD seconds if the latter variable is set.

Zsh also makes it possible to run particular code automatically on certain occasions. You just have to define some special functions. The two most frequently used are chpwd and precmd. Zsh calls the former each time the current directory changes. The latter is called just before Zsh shows you a new prompt. Both functions are regularly used to show the current directory in the title bar of your terminal emulator. If you use programs other than the shell, which alter the title of your terminal emulator (Vim is one example), you should use precmd - it restores the title after another command has run. So this is how we show the current directory in the title bar (adapted from the manual page):

REPORTTIME=5 TIMEFMT="%U user %S system %P cpu %*Es total"