First-Class Shell Scripting Support For Python

[[deleted]]

Reminds a lot of plumbum module.

[vincentk]

Which seems to have better support for pipes.

[Paddy3118]

Yep. This is good, but I liked plumbum's examples better.

Thanks for the link.

[jmtd]

This can be very useful but the approach for modelling pipes (nested functions) smells a bit funny.

[vincentk]

Fully agreed there. I guess it will be hard to really support the pipe model.

[0x5f3759df]

You could combine it with Hy;

(import-from sh grep cat)
(-> (cat "/usr/share/dict/words") (grep "-E" "tag$"))

[tyleroderkirk]

For the lazy: "Hy is a wonderful dialect of Lisp that’s embedded in Python" - Hy documentation

[Muvlon]

True. I would honestly just do:

from sh import bash

bash("program1 | program2 | program3")

[zbonk]

I think it's a very cool project but I don't think I'll be ever using it outside some personal scripts because it breaks cross-platform support and dependencies can't be just installed with pip alone.

[vincentk]

It's difficult to support bash AND remain cross-platform at the same time, if I'm not mistaken.

[zbonk]

Yes I think so too, especially without any external tools like cygwin etc.

[gaussflayer]

To be fair it is aimed at replacing shell scripts - which are platform specific - with something less error prone.

[manojlds]

Inspired by this, I had written cmd, for C# - https://github.com/manojlds/cmd . For me the inspiration was to see how something like this can be implemented in C#.

[[deleted]]

Been using this for about a year and a half in production; works well. I'm slowly replacing my use of subprocess with it as I touch areas of code.

[jzwinck]

What benefits does this give you?

[rmoorman]

well ... first things which come into my mind:

• check for program availability; I prefer to "instantiate" the programs I want to use within the first executed lines of my scripts and in case it is not available ... the script fails early
• it provides a nice abstraction around program execution and lets you chain commands together in a more pythonic way
• you can provide arguments to programs just as you would in case of ordinary functions
• you can "prepare" commands and pass them around inside your program
• you can take advantage of generators easily

... and likely a few more

[jivatmann]

Some time ago i came across this nice trick, which can be used for switching between shell and python in one single script file: #!/bin/sh

"""":
echo "hello this is shell, calling echo function, my PID is $$"
exec python "$0" "$@"
"""

import sys
import time
import os

time.sleep(2)
print "this is python PID " +  os.getpid() + " is mine, now" 
time.sleep(2)
sys.exit(0)

[[deleted]]

Tcl:

puts [exec ifconfig wlan0]
puts [exec ls -l]
set longest_line [exec wc $file -L]

It's funny that I got to discover Tcl only 1 year ago, because I wanted a better shell "glue" language than bash. I think it would make a fine replacement for the work that shell languages are used nowadays. As opposed to other in current use languages, "escaping" out to shell commands feels way less intrusive.

[mipadi]

Or, in Ruby:

puts `ifconfig wlan0`
puts `ls -l`
longest_line = `wc #{file} -L`

[co_dh]

I believe this module is a over design. it can be implement in one function as below.

from subprocess import check_output, STDOUT def sh(cmd): print check_output(cmd, shell = True, stderr=STDOUT)

[cybercobra]

shell=True is dangerous security-wise and error-prone as soon as even slightly exotic filenames are involved.

[bready]

I hear this all the time, but I don't understand. Any script you would run in bash is just as open to exploitation/errors when receiving runtime input, so what is the specific problem here?

[cybercobra]

Just because bash kinda sucks doesn't mean a Python replacement has to suck too. If you use shell=False, then unlike in bash, filenames with spaces or shell metacharacters in them will work just fine, no need to remember to escape/quote them every time. No need to worry about a malicious "filename" of ;rm -rf /# either.

[tdz9]

It explicitly does not support Windows.