Thanks a lot for reviewing the code. I thank you a lot. On Feb 25, 2016 9:41 PM, "Jean-Baptiste Thomas" <cau2jeaf1ho...@laposte.net> wrote: > > > github.com/himanshushekharb16/ProxyMan > > Hi Himanshu. Quick look at main.sh. > > 1) Some messages are written to stdout, others to stderr. I think > that writing everything to stderr would be preferable, if only for > consistency. Rule of thumb : if it's data, write to stdout ; if > it's messages, write to stderr, even if they're not errors. A > function like this is useful : > > msg () > { > fmt=$1 > shift > printf "myprog: $fmt\\n" "$@" >&2 > } > > or > > msg () > { > echo myprog: "$@" >&2 > } > > if you prefer echo. > > 2) After "case $choice in toggle)", > > if [ $mode == "'none'" ]; then > > is not safe. Should have double quotes around $mode. > > 3) You seem to like to quote string constants, as in > > if [[ $4 == 'y' ]]; then > > It doesn't hurt anything, but it's completely unnecessary. Just > a heads-up. > > 4) exit is often called without an argument. Or not called at > all. A program that succeeds must exit with status zero. > Conversely, exiting with status zero constitutes a promise that > everything went well. Even if the exit status is less important > for interactive programs such as yours, it's a good habit to get > into. > > 5) There's a general lack of checking for failure of operations > that can fail (writing to files, copying files...). >
I am novice to bash. In fact, I learned bash a little bit just to implement the idea. So, there are examples that show my immaturity. My bad! Also, I would love to know about good sources to learn and practice Bash. I followed "The Linux Command Line by William E. Shotts". > 6) Lots of variable references without double quotes around them, > EG when calling configure_apt(). What if, say, the password > contains white space or "?" or "*" or "[" ? Please tell me about how to read special characters as @, ? etc. in password, as @ is the point after authentication where IP starts. > > Sorry if this sounds like nit-picking but attention to detail is > a big part of quality. Good luck. Mark Zuckerberg said, "We should break things, to make them better". And you quoted the points where things may break. Thanks again. :)