[sos-devel] isatty opinions

[Jesse Jaggars]

More responses below...

----- Original Message -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 09/05/2012 09:37 PM, Jesse Jaggars wrote:
> > So I've been reassigned the following JDR bug:
> > https://issues.jboss.org/browse/JBPAPP-9565
> > 
> > The story behind this situation is long and gory, but to make it
> > short the productization process removed some libraries that jython
> > uses to call native code for what could be argued as fair reasons
> > (could easily be argued the other way too I suppose.)
> > 
> > Anyhow, it seems that without the jffi libraries JDR fails to
> > execute while running on a solaris box due to the inability to find
> > the proper native bits to run. The call in question is os.isatty().
> > 
> Ugh. I'm not sure I like this restriction although I do see that
> we're
> in a tough spot (I don't think that anyone wants to compile native
> binaries for Solaris).
> 

Yep that's basically it. The community version just ships the .so 
files that come with jython, but that's not an acceptable option for EAP
unfortunately. There was some discussion of making an exception somehow
but that fizzled out.

> Is there really no way that this can be done with existing available
> binary code?
> 

Could be, I haven't investigated trying with pure java and then falling
back onto os.isatty. That's probably possible, but it promotes ugliness.

> > We use this call in two spots today:
> > 
> > [jjaggars sos (master $>)]$ ack isatty sosreport.py 270:        if
> > hasattr(sys, 'ps1') or not sys.stderr.isatty(): 310:        if not
> > sys.stdin.isatty():
> 
> Is there some way we can shim this? The isatty checks are generally
> of
> interest in detecting interactive/non-interactive sessions and are
> important in Linux environments.
> 
> I'd assume that in Jython execution we never have a controlling TTY,
> is that correct?
> 

This isn't entirely true, but sosreport is forced into batch mode
operation in every case so maybe we could skip the whole thing in this case.

> In that case we can replace direct calls to isatty() with a function
> that always returns false under Jython but makes the os.isatty() call
> on other platforms.
> 
> > The first is when we catch an exception in debug mode, if we don't
> > have a tty we don't use pdb to debug. The second is when we setup
> > logging; if we don't have a tty we disable some output stuff.
> 
> It gates batch mode and disables coloured output (to avoid
> non-printing control characters on stdout).
> 

So colored output was removed so the only real benefit is the setting of
batch mode in this case. I wonder if defaulting to batch mode would be
a miserable idea? Providing we add an --interactive option.

> > How critical is it to attempt to detect an underlying tty for these
> > cases? Can we safely trust our defaults and the user (or blame them
> > for their mistakes if they do it wrong) for these seemingly trivial
> > situations?
> 
> I would guess that there are quite a few users that run sos without a
> tty and expect that to imply batch mode. Without that check we'll
> start prompting for stuff and those users current modes of execution
> will hang.

See above.

> 
> > Here are some more details to help frame things a bit more. I'm not
> > sure how important it is to fix this issue, might mark as a
> > will_not_fix. I'm also unsure if removing the isatty() calls will
> > be enough to fix this issue altogether, it's possible that there
> > are a whole mess of functions that follow the same failing code
> > path that I don't know about yet and don't have a good way to test
> > for.
> 
> That's probably my biggest concern here: what else could we be
> missing? How does this affect future plans in terms of making certain
> core APIs "off-limits" for sos?
> 
> Shimming a few corner cases isn't a big deal. Wrapping half the
> python
> standard library would be much more painful.
>

Getting sosreport to work in jython has added some corner-case handling
ugliness already, but it'd be nice to cut back on that I think. Might
be a good idea to think about separating the UI layer from the actual
machinery.
 
> Regards,
> Bryn.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAlBIotwACgkQ6YSQoMYUY96L1wCfVhGdF84lQkBeTLM4EsMDswOG
> InYAoKAipBYfwsO4l+7BWSIwFEOjh4uG
> =Gb+O
> -----END PGP SIGNATURE-----
>