Re: t/t1304: avoid -d option to setfacl (db82657)

Hi Brandon,

Thanks for posting my question. I realized shortly after my post to github that I should have posted to the mailing list instead.


On Nov 18, 2011, at 12:37 AM, Brandon Casey wrote:

[cc git@vger.kernel.org since that is the appropriate place for this discusion]

On Thu, Nov 17, 2011 at 8:59 PM, wsp
[off-list ref]
wrote:

quoted

Could this test case be reviewed again? It fails on FreeBSD where the appropriate way to specify default ACL's is with the "-d" option. The "d[efault]:" syntax is invalid on FreeBSD.

Well, I'm not sure there is a right answer here.

  Linux accepts -d or "d[efault]"
  Solaris only accepts "d[efault]"
  FreeBSD only accepts -d
  a quick search shows z/OS only accepts "d[efault]"
  other?

I think most everything else rolls their own implementation into chmod
or chacl or something like that.

OS X does indeed roll ACL management into chmod. The test passes there because the prereq isn't met (i.e. the setfacl command does not exist) and thus the tests are skipped.

The abandoned POSIX draft does actually specify the FreeBSD behavior.

So I think it's kind of a toss-up.  Which option we choose should
probably depend on whether we get more test coverage by using the
"d[efault]" notation or by using the -d option.  That depends on
whether there are more Solaris users compiling git or whether there
are more FreeBSD users.  I don't know the answer to that either.  I
tend to think there are very few of either.

Is there a reason conditional logic can't be used (perhaps keying off of `uname -s` or the like) so that we have coverage in all cases?

-S

-Brandon
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html