[ https://issues.apache.org/jira/browse/HADOOP-9902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090273#comment-14090273 ] 

Allen Wittenauer commented on HADOOP-9902:
------------------------------------------

bq. It seems that hadoop-functions.sh ends up in sbin/hadoop-functions.sh in the finally binary assembly but hadoop-config.sh looks for it in the HADOOP_LIBEXEC_DIR. 

Weird!  I've been using tar ball builds and it shows up in HADOOP_LIBEXEC_DIR / libexec as expected. I wonder what's going on here then. hadoop-dist.xml even specifies libexec and excludes it from sbin specifically.  From my own fresh build of trunk + this patch:

{code}
mbp:hadoop-3.0.0-SNAPSHOT aw$ pwd
/Users/aw/Src/hadoop-common/hadoop-dist/target/hadoop-3.0.0-SNAPSHOT
mbp:hadoop-3.0.0-SNAPSHOT aw$ find . -name hadoop-functions.sh
./libexec/hadoop-functions.sh
{code}

So I guess I need some advice here on a way to reproduce it and/or how to fix this one.

bq. hadoop-common-project/hadoop-common/src/main/bin/hadoop's extra quotes

Yup, that's clearly broken.  Probably snuck in while I was playing with the space bug.  That's an easy fix.

bq.  HADOOPOSTYPE needs to be documents

This is one of those things that I didn't know what to do with it.  I really don't want it to exist, to be honest, but with HADOOP-8719, we have to do something in the hadoop-env.sh. Stupid Apple and/or Oracle.  I think in the end we're just kind of screwed and will need to make it real. :/  I'll change it to HADOOP_OS_TYPE, define it both in hadoop-env.sh and hadoop-functions.sh so that it can be referenced as a real value.

bq. Are we planning to use *-env.sh for documenting all the variables that one may set?

That was my intent, yes.  I'm looking at it from the perspective of your typical /etc/default/*, /etc/sysconfig, etc, type file.

bq. Any reason populate_slaves_file function is in hadoop-config.sh and not in hadoop-functions.sh ?

It was really meant as a utility function only for hadoop-config.sh to simplify the options listing/parsing code. But there's no reason it can't be moved.  I'll do that as well as make it hadoop_ to keep the name space clean.  

bq. The following appears to be a sort of no-op if value is not set 

Yup, correct. Another easy fix. (... and clearly bad copypasta from the current code ...)

bq. Any reason not to try harder and see what type -p java returns? 

I think it's too risky.  I'd much rather have an explicit JAVA_HOME than assume that /usr/bin/java (or whatever happens to get returned) is "good".  'type -p' can also be wildly unpredictable since it uses the hashed value... this is not necessarily the first one that shows up in the path!

Thanks! 

> Shell script rewrite
> --------------------
>
>                 Key: HADOOP-9902
>                 URL: https://issues.apache.org/jira/browse/HADOOP-9902
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: scripts
>    Affects Versions: 3.0.0
>            Reporter: Allen Wittenauer
>            Assignee: Allen Wittenauer
>              Labels: releasenotes
>         Attachments: HADOOP-9902-10.patch, HADOOP-9902-11.patch, HADOOP-9902-12.patch, HADOOP-9902-13-branch-2.patch, HADOOP-9902-13.patch, HADOOP-9902-2.patch, HADOOP-9902-3.patch, HADOOP-9902-4.patch, HADOOP-9902-5.patch, HADOOP-9902-6.patch, HADOOP-9902-7.patch, HADOOP-9902-8.patch, HADOOP-9902-9.patch, HADOOP-9902.patch, HADOOP-9902.txt, hadoop-9902-1.patch, more-info.txt
>
>
> Umbrella JIRA for shell script rewrite.  See more-info.txt for more details.



--
This message was sent by Atlassian JIRA
(v6.2#6252)