Dear Wiki user, You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change notification.
The "UnixShellScriptProgrammingGuide" page has been changed by SomeOtherAccount: https://wiki.apache.org/hadoop/UnixShellScriptProgrammingGuide?action=diff&rev1=19&rev2=20 * Remember that abc_xyz_OPTS can and should act as a catch-all for Java daemon options. Custom heap environment variables and other custom daemon variables add unnecessary complexity for both the user and us. They should be avoided. In almost every case, it is better to have a global and apply it to all daemons to have a universal default. Users can/will override that variables as necessary in their init scripts. This also helps cover the case when functionality starts in one chunk of Hadoop but ends up in multiple places. + * If you absolutely need to have a per-daemon environment variable, try to generalize the solution and use the `HADOOP_${command}_yourthing`-type of layout. See the hadoop_verify_user function for an example. + * Avoid mutli-level `if`'s where the comparisons are static strings. Use case statements instead, as they are easier to read. * BSDisms, GNUisms, or SysVisms. Double check your command, parameters, and/or reading of OS files on multiple operating systems. (Usually a quick Google search will pull up man pages for other OSes.) In particular, check out Linux, OS X, FreeBSD, Solaris, and AIX. It's reasonable to expect code to work for approximately three-five years. Also take note of hadoop_os_tricks, where OS-specific start up stuff can go, so long as a user would never want to change it... * Output to the screen, especially for daemons, should be avoided. No one wants to see a multitude of messages during startup. Errors should go to STDERR instead of STDOUT. Use the `hadoop_error` function to make it clear in the code. - * If you need to add a new function, it should start with hadoop_ and declare any local variables with the `local` tag. This allows for 3rd parties to use our function libraries without worry around conflicts. + * This isn't Java. CamelCase is weird and you will be endlessly mocked if you use it for variable names. Instead, all capital letters for globals, lowercase for locals. - * This isn't Java. CamelCase is weird and you will be endlessly mocked if you use it for variable names. Instead, all capital letters for globals, lowercase for locals. + * If you need to add a new function, it should start with hadoop_ and declare any local variables with the `declare` or `local` tag. This allows for 3rd parties to use our function libraries without worry around conflicts. * The [[http://wiki.bash-hackers.org/scripting/style|Bash Hackers website]] and [[https://google-styleguide.googlecode.com/svn/trunk/shell.xml|Google]] have great general advice for style guidlines in bash. Additionally, Paul Lutus's [[http://www.arachnoid.com/python/beautify_bash_program.html|Beautify Bash]] does a tremendously good job reformatting bash. --------------------------------------------------------------------- To unsubscribe, e-mail: common-commits-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-commits-h...@hadoop.apache.org
