Guidelines

Don't put any lines in your config files that you don't understand!

Keep necessary notes

1. meaningfull name
2. comment & reference

Compatibility & Light-weight (i had to ditch my beloved emacs) & less-dependency

1. support both darwin & ubuntu

2. zsh & bash 4.x

3. local & ssh

4. Prefer pre-installed software(intersection of OSX and Ubuntu)(I'll remain trying, but i cann't guarantee)

   use curl rather than wget(because as to OSX, wget is not a built-in command)

5. deal with the difference between BSD & GNU program

   • use python script to replace some of these programs in order to reduce the impact causing by these differences (between go python ruby and javascript, only python is supported by both OS in default)

Pre-arrangement

PATH related

keep /bin/ at the end of PATH sequence, so avoid using some old version of softwares like /bin/bash on macosx, to save energy.

Loading-Sequence

(also the dependency chain, frome left to right, each layer may or may not depends on the layer on its left side and may or may not be depended by the layer on its right side):

internal -> mechanism -> (path - runtime) -> (function - alias) -> module -> custom

1. internal (written with only then shell-builtin commands & some shared pre-installed programs on both the ubuntu and OSX)
2. path (package-manager specific & custom-defined 'PATH') - try Sub-Shell when export PATH is needed, only keep necessary 'PATH' exported(remember the Global Variables Are Bad)
3. mechanism (basic setup for downstream stuff)
4. module (least dependence between each other, dependency autonomy)
5. no external dependence for executable script

Naming Convention:

function name with underscore as prefix means this function is internal-use only

Terminology

module & modules

1. when I mention about module in comment/naming or something else, it means someting related to one module
2. when I mention about modules in comment/naming or something else, it means something related to all modules in a generic way
3. In another word, module or modules are like scope identifier

annotation

There are some functions work like java-annotion with RetentionPolicy.SOURCE。

_annotation_completion_write() {
    # like java-annotation, i use this to annotate certain lines in bash file, in
    # order to process them later
    return
}

_annotation_completion_generate() {
    # like java-annotation, i use this to annotate certain lines in bash file, in
    # order to process them later
    return
}

TODO & Question & Reference

• backup shell-command-history to github with encryption

1. How to write a new git protocol
2. blackbox

• add security check for SCM(personal or other sensitive info)

• backup browser history

1. easy to search
2. pre or post process

• bootstrap-mechanism for the whole setup process

1. more automation
2. clean and easy to use
3. easy to extend

• performance

1. lazy-loading like technique to reduce the 'sourcing' overhead

   - Prefer script over function, scripts does not directly effect the sourcing process -- also this will be good for debugging (every time you change a function you have to source again to see if it works)
           - Use function over script in such condition: the code is part of sourcing process, because according to [Shell-Functions](https://www.gnu.org/software/bash/manual/html_node/Shell-Functions.html#Shell-Functions), bash execute function in current shell context, no new process is created to interpret them, and script do raise new process, so it's apperantly function is with a lighter overhead execution-wise.
   

2. caching source-chain to boost later bootstrap process (reducing usage of function like '_load_sh_files')

3. global environment variable to avoid repeat-initialization while opening multiple-tab inside iterm2/terminal(open a new tab inside iterm2/terminal will create a new bash process, i might have mis-conjectured something)

• coding style

1. cleansing code

• Legal-Stuff