Here is a little site which is good for spotting basic mistakes in shell scripts.
http://www.shellcheck.net/ -Surya On Thu, Feb 25, 2016 at 2:23 PM, Himanshu Shekhar <irm2015...@iiita.ac.in> wrote: > 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. :) > -- Surya Saha Sol Genomics Network Boyce Thompson Institute, Ithaca, NY, USA http://www.linkedin.com/in/suryasaha https://twitter.com/SahaSurya
