33 Matching Annotations
  1. Last 7 days
    1. 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
    2. open a login shell which sources ~/.bash_profile
  2. Dec 2019
    1. 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.
    1. 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
    2. 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:
    3. 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.
    1. 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
    1. If you want happy cow messages when you login change your bash_profile.
    2. 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
    1. 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.
  3. Nov 2019
  4. Jul 2019
    1. 将错误IP放到数组里面判断是否ping失败三次
      for IP in $IP_LIST; do
          while [ $NUM -le 3 ]; do
              if ping -c 1 $IP > /dev/null; then
                  echo "$IP Ping is successful."
                  # echo "$IP Ping is failure $NUM"
                  let NUM++
          if [ ${#FAIL_COUNT[*]} -eq 3 ];then
              echo "${FAIL_COUNT[1]} Ping is failure!"
              unset FAIL_COUNT[*]
    2. 获取随机8位字符串:
      # echo $RANDOM |md5sum |cut -c 1-8
      # openssl rand -base64 4
      # cat /proc/sys/kernel/random/uuid |cut -c 1-8
    3. 获取随机8位数字:


      # echo $RANDOM |cksum |cut -c 1-8
      # openssl rand -base64 4 |cksum |cut -c 1-8
      # date +%N |cut -c 1-8
    4. 注意事项





      5)有两个命令能帮助我调试脚本:set -e 遇到执行非0时退出脚本,set-x 打印执行过程。


  5. Feb 2018
    1. You do that using backticks: echo World > file.txt

      run command from file in bash command and define after > the filename where the rest of the command is.

    1. ${FUNCNAME[@]}


  6. Nov 2017
    1. 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.

      Two most useful commands in bash

  7. Oct 2017
  8. Sep 2017
  9. Jul 2017
    1. .

      This character should be escaped by a backslash. The complete command would then be:

      strings $PWD/bin/myapp | egrep '\.gcda$'
  10. Feb 2017
    1. 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.

      The power of BASH!

  11. Oct 2016
    1. Counting number of lines


    2. -print0

      find -print0 经常和 xargs -0 配合使用,处理文件名中换行符这种特殊情况

  12. Feb 2014
    1. 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:

      This is a very good example of why shell scripting does not scale from simple scripts to large projects. This is not the only place where changes in whitespace can lead to scripts that are very difficult to debug. A well-meaning and experienced programmer from another language, but new to bash scripting, might decide to clean up formatting to make it more consistent-- a laudable goal, but one which can lead to unintentional semantic changes to the program.

      Flat, short bash scripts are extremely useful tools that I still employ regularly, but once they begin creeping in size and complexity it's time to switch to another language to handle that-- I think that is what (rightly) has driven things likes Python, Puppet, Ansible, Chef, etc.

      Despite the syntactic horrors lurking in shell scripts there is still a beautiful simplicity that drives their use which is a testament to the core unix philosophy.