The main criticism has been the cleverness of the dynamic lookups. There
is also the ability to use a Command object for more explicit calls:
cmd = sh.Command("/some/command")
cmd(arg)
So you have the best of both worlds. If you like the idea of the programs
being attributes on the module, you can use the advertised way, if you
don't, you can use the more explicit way.
Windows support would be a little more difficult. It existed in an old
version of sh, when it was merely a wrapper around the subprocess module.
Now that sh.py no longer relies on the subprocess module and does
fork-exec itself (in order to get more flexible access to the processes),
Windows is currently unsupported. My current understanding is that most of
the value comes from the linux/OSX folks, but Windows support is scheduled
for the future.
On Sat, Oct 20, 2012 at 8:02 PM, Mike Graham
On Sat, Oct 20, 2012 at 8:33 PM, Andrew Moffat
wrote: Hi,
I'm the author of sh.py, an intuitive interface for launching subprocesses in Linux and OSX http://amoffat.github.com/sh/. It has been maintained on github https://github.com/amoffat/sh for about 10 months and currently has about 25k installs, according to pythonpackages.com (http://pythonpackages.com/package/sh, http://pythonpackages.com/package/pbs)
Andy Grover maintains the Fedora rpm for sh.py http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=94247 and Nick Moffit has submitted an older version of sh.py (which was called pbs) to be included in Debian distros
http://pkgs.org/debian-wheezy/debian-main-i386/python-pbs_0.95-1_all.deb.htm...
I'm interested in making sh.py more accessible to help bring Python
forward
in the area of shell scripting, so I'm interested in seeing if sh would be suitable for the standard library. Is there any other interest in something like this?
Thanks
sh.py strikes me as on the clever side for the stdlib and the lack of Windows support would be very unfortunate for a stdlib module (I don't know if this is relatively easily fixed, though it seems possible)
Mike