On Apr 28, 2015, at 10:59 AM, Andrew Wang <andrew.w...@cloudera.com> wrote:
>
> This is also not something typically upheld by unix-y commands. BSD vs. GNU
> already leads to incompatible flags and output. Most of these commands
> haven't been changed in 20 years, but that doesn't constitute a compat
> guarantee.
One of the reasons why Solaris doesn’t officially support user names
greater than 8 characters is because of the breakage to ls and what that would
do with how one parses them. So, yes, it is upheld in cases where it would be
too big of a burden on backward compatibility. (That’s the easy example, I
could give a lot more from my days at Sun if you’d like.)
> This is something I'd like to follow for our own commands. We provide
> different APIs for machine consumption vs. human consumption, and make this
> clear in the compat guide. Of course, we should still be judicious when
> changing the human output, but I just don't see a good way forward without
> relaxing our current compat guidelines.
I think that’s a great suggestion.
> The other thing to consider is providing supported Java APIs for the
> commonly-parsed shell commands. This is something we have much more
> experience with.
I think people forget about who the customer of some of these
interfaces actually are. I can probably count the number of ops people I know
who speak Java frequently enough to be comfortable with it for every day use on
two hands. In this particular case, fsck is, by and far, an ops tool. Give us
perl and/or python and/or ruby bindings. That was the promise of protobuf,
right? But Java? Yeah, no thanks, I’ll continue processing it from stdin with
a couple lines of perl than deal with the mountains of Java cruft.
<insert “we don’t do enough planning around major releases so we have
these issues” argument here>
