[sos-devel] isatty opinions

[Bryn M. Reeves]

-----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).

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

> 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?

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).

> 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.

> 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.

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-----