Thanks a lot for reviewing the code.
I thank you a lot.
On Feb 25, 2016 9:41 PM, "Jean-Baptiste Thomas" <cau2jeaf1honoq@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. :)