stat uses GNU-specific -c format parameter

[abarnert]

(After #176 and some solution to #178, this is the last thing preventing ZeroDeploy from at least successfully constructing a remote connection to a Mac; I don't know if it's sufficient to make everything actually work…)

stat -c is a GNU extension.

In fact, stat itself is a NetBSD/FreeBSD extension that GNU copied with different parameters, but I'll get to that later.

On *BSD, you use -f to specify a format string. And instead of having a bunch of variations of each field, you have a smaller set of fields and a bunch of modifiers that can be applied to any of them—e.g., instead of %u for uid and %U for username, there's %u for user and %Su for string user. Also, the values for BSD %HT aren't exactly the same as the ones for GNU %F, but fortunately the three that you check for are the same. So, to make the three stat-based methods in BaseRemoteMachine to work, you just need to change the arguments to (respectively):

• -f'%u,%Su'
• -f'%g,%Sg'
• '%HT,%Xp,%i,%d,%l,%u,%g,%z,%a,%m,%c'

Meanwhile, for other platforms like Solaris, there is no stat command at all. I suppose you could write something that parses the output of ls -l, which I think should be sufficient for the places you're actually using it in plumbum and rpyc—but not for code that users have written that depend on a real stat result.

Also, I'm not sure how to patch this. The try/fallback idea I suggested for env -0 in #178 doesn't seem like a good idea for every single stat call. So you probably want to do something like this:

if self.uname.startswith('Linux') or self.uname.startswith('CYGWIN'):
    # do GNU stuff
elif self.uname == 'Darwin' or 'BSD' in self.uname:
    # do BSD stuff
else:
    # do fallback stuff

But doing this same set of checks in at least four places (these three methods, plus the env one) doesn't seem like a good idea. Maybe we want to centralize the tests in self.gnu_userland() and self.bsd_userland() functions? (Of course these two userlands aren't monolithically consistent, but if you stick to things that were in, respectively, glibc 2.1 and both NetBSD 2.0 and FreeBSD 5.0, that's probably safe enough, I hope.)

[tillberg]

I just ran into this myself, also trying to connect to an OSX machine, and was able to get all the functionality I need for my own application by creating a patch (#196) like that described above by @abarnert. Also, 👍 to the actual format strings above; I got the same results myself by translating the existing format strings via the darwin & linux stat man pages before finding this Issue.

On my OSX Yosemite system, this patch brings test_remote.py up from 1 passing test to 6 passing tests. (They all pass both before & after this change on my Ubuntu 15.04 machine.) And like I said, it made enough stuff work for my application -- mostly command invocation and streaming stdout/stderr from them.

I agree with everything that @abarnert said above about introducing a lot of complexity with this... interoperability with OSX is really great for what I'm working on, but for a lot of folks, this sort of platform-specific cruft is a slippery slope of complexity bloat.

[magixx]

Same issue with Solaris, AIX, and HPUX. Why is the OS module not used instead? If that's not possible then a module for istat might have to be created. For the former two I was lucky and found coreutils at http://www.opencsw.org/packages/CSWcoreutils/ and http://www.perzl.org/aix/index.php?n=main.coreutils. HPUX looks like it has it at http://hpux.connect.org.uk/hppd/hpux/Gnu/coreutils-8.22/ but I've not tested that yet.

[henryiii]

This should be improved (for FreeBSD) by #220.

[henryiii]

I believe the patch fixed this for common systems. Reopen if there are further problems!