good_func can only return one value. Also, a sub-shell is created. If you call good_func in a loop, it can be very slow.

bad_func runs in the same shell. It can set multiple values. Typically, you can have a convention such as storing the result in RESULT. It runs faster in a loop.

In good_func which echoes the result, what happens if you are later debugging and add some echoes inside the prog. You must then be careful that you redirect your echo to stderr.

$ the tips no 1,2,4 can be summarized to “create process as necessary”, this can be achieved in many ways (eg. using features

of tool used, tweaking the pipeline)
- the maintainer of each tool considers many things before a feature is added to the tool, such as will it be used

frequently?, does it offers much efficiency?
- no one is expected to remember all features (except the famous ones) of a tool unless he limits his area of expertise.

however, each feature added till now is logically appropriate, i mean u can expect that grep has a feature that only output

the num of matched line / diff can suppress its output & only tell whether files are different. that’s why i think doing

optimization to a script is only done after the script has satisfied its functional requirement (up to this point the script

is made in the intuitive way) & only scripts that are heavily used treated this way. the fun part is that u can skip this

boring task by making someone do it, cause it is simple
- tools’ maintainers tend to use the same opt char in controlling similar future (ex: for suppressing output, its either q /

s)

$ tips no 3 isn’t consistent with the others if what u’re looking for is performance, it forks another subsh to do the func.

a solution to this problem is to maintain a convention on the func identifier & the var that stores the return val, just like

maintaining convention of what a func do & its identifier. example:
_mul(){
_MUL=$(($1*$2))
}
mul(){
echo _mul $1 $2
}

- this way u can store _MUL to a var / use it directly as long as access to _MUL is serialized

- try it with time: compare: time v=$(mul 2 3) with time { _mul 2 3; v=$_MUL; }

$ no 5 isn’t a tip, ‘read’ is important since it’s the easiest & cheapest (builtin) way, u can do v=$(</dev/stdin) /

v=$(dd) with eof ending the input but it’s just dumb unless u need a particular characteristic where ‘read’ can’t satisfy

Then again, the information here does fit under the title “Five Shell Programming __Tips__”, I guess it’s just that we should opt for the more intuitive use than some obscure command line arguments in most everyday usages.

STICKY FILES
On older Unix systems, the sticky bit caused executable files to be hoarded in swap space. This feature is not useful on modern VM systems, and the Linux kernel ignores the sticky bit on files. Other kernels may use the sticky bit on files for system-defined purposes. On some systems, only the superuser can set the sticky bit on files.

(If it’s the program start-up time you’re concerned about, that’s what the sticky bit is for.)