Show HN: Sultan – Pythonic interface to your shell(sultan.readthedocs.io)
sultan.readthedocs.io
Show HN: Sultan – Pythonic interface to your shell
https://sultan.readthedocs.io/en/latest/
53 comments
> much different than a remote HTTP/ReST API
does that make subprocess module like urllib, and these wrappers like the ubiquitous requests package?
I think it's harder than you say: a given tool like grep has an API the size of an entire website, and then depending on usage, has different usage patterns which different optimizations.
Also, a REST API user is consuming an API, whereas a CLI wrapper is consuming an API to implement another. Much bigger fish to fry there, I think.
does that make subprocess module like urllib, and these wrappers like the ubiquitous requests package?
I think it's harder than you say: a given tool like grep has an API the size of an entire website, and then depending on usage, has different usage patterns which different optimizations.
Also, a REST API user is consuming an API, whereas a CLI wrapper is consuming an API to implement another. Much bigger fish to fry there, I think.
You make a very good point. Sultan, at the end of the day, is a syntactic sugar for Subprocess. It has a couple of doo-dads for remote SSH execution, and things like that.
I originally wanted to have Sultan to do exactly what you're saying, but when I started diving into it, it seemed like a task that was very tough to solve. For example, grep's syntax remains similar between OS, but it has some API changes between versions. Trying to figure out what version has what syntax seems a bit daunting, and perhaps impossible to do with all commands.
The usecase that Sultan really caters to is the developer who writes their code on one OS, and keeps that code in the same OS across different environments. Not everyone wants their code to run across different OS and Distributions. I felt like it was a special case to do this, and decided to keep Sultan as generic as possible and let developers build the logic for different OS and Distributions on top of it.
The problem Sultan does solve is code maintainability, reusability within their own project (which assumes the project runs on 1 OS), and testability (unit and integration tests can be written, while you can't do that in Bash easily).
I originally wanted to have Sultan to do exactly what you're saying, but when I started diving into it, it seemed like a task that was very tough to solve. For example, grep's syntax remains similar between OS, but it has some API changes between versions. Trying to figure out what version has what syntax seems a bit daunting, and perhaps impossible to do with all commands.
The usecase that Sultan really caters to is the developer who writes their code on one OS, and keeps that code in the same OS across different environments. Not everyone wants their code to run across different OS and Distributions. I felt like it was a special case to do this, and decided to keep Sultan as generic as possible and let developers build the logic for different OS and Distributions on top of it.
The problem Sultan does solve is code maintainability, reusability within their own project (which assumes the project runs on 1 OS), and testability (unit and integration tests can be written, while you can't do that in Bash easily).
This seems to be a simple wrapper around subprocess, but I'm afraid it is not changing things dramatically. Overall, I don't agree that Sultan's syntax is any more Pythonic than subprocess itself.
+1 for https://sultan.readthedocs.io/en/latest/sultan-examples.html...
I think it would be interesting if you could iterate on the results of "ls -l", where each row is represented by an object.
+1 for https://sultan.readthedocs.io/en/latest/sultan-examples.html...
I think it would be interesting if you could iterate on the results of "ls -l", where each row is represented by an object.
Representing each row as an object works, but it ends up having us write custom objects for different result types. When you run Sultan().ls('-l'), you will get back a list of Strings, which you can freely use in Python for your specific needs (like use a Regex to fetch date/times or file size). I felt like this offers developers the best flexibility, rather than trying to customize each output (which will definitely make the codebase very confusing)
And then I remember that Windows PowerShell does (attempts to, to be fair) exactly that
attempts to, to be fair
Output of ls in PS is an Array of objects (DirectoryInfo or FileInfo instances). How is that merely an attempt?
Output of ls in PS is an Array of objects (DirectoryInfo or FileInfo instances). How is that merely an attempt?
While PS-native stuff yield objects, not all pre-PS utilities/builtins are overriden or have interface for PS and output old fashioned text blob, which is not automagically parsed in any way by PS. My comment was system-level, not utility-level.
How does
s(command_from_potentially_unsafe_source).run()
os.system(command_from_potentially_unsafe_source)
subprocess.call(command_from_potentially_unsafe_source, shell=True)
I looked at the source code. Under the hood, it's just a thin wrapper around `subprocess`.
Cool subprocess is a little verbose. But did you happen to notice if it executes with shell=True or shell=False?
Do you include Python 3.5's subprocess.run in that assessment? I find it much cleaner for the common cases than the rest of the API:
https://docs.python.org/3/library/subprocess.html#using-the-...
https://docs.python.org/3/library/subprocess.html#using-the-...
I hadn't actually noticed that! It looks like .run() allows input and output to be piped and the return code captured. That is a serious improvement over subprocess.call().
Doesn't seem that different from call()
It looks like it allows stdin, stdout, stderr and return code to be handled properly which call() doesn't. It's still syntactic sugar over Popen() and communicate() but will cut down boilerplate for calling external processes.
When I dabble with Python to get a job done, I invariably end up using subprocess at some stage and going through some contortions. I like the look of Sultan, it seems well thought out and has loads of well written docs.
Anyone know how the name came about?
Anyone know how the name came about?
Since I was creating a tool that works with Commands, I thought of the tag line "Command and Rule Your Shell", and I thought of different types of rulers (Kings, Shahs, Czars, Sultans, etc.). The Sultan name seemed to fit the best.
I was also trying to grow a Handlebar mustache at the time, and I wanted my logo to have a Handlebar Mustache, so that's why the logo has a Handlebar Mustache :-)
I was also trying to grow a Handlebar mustache at the time, and I wanted my logo to have a Handlebar Mustache, so that's why the logo has a Handlebar Mustache :-)
Sultan means king
If you see the tag line for project
Since we're throwing out random shell related tools, I found pexpect recently: https://pexpect.readthedocs.io/en/stable/api/replwrap.html
Which was super useful for controlling some utilities that wanted to be run in an interactive bash shell.
Which was super useful for controlling some utilities that wanted to be run in an interactive bash shell.
I've been using 'tentakel' for remote server admin for years, 'fabric' for lightweight deployment, and more recently 'invoke' for local invocations (all are Python projects).
This project looks interesting too, will give it a try.
BTW: Has anyone news on Fabric 2 ?
This project looks interesting too, will give it a try.
BTW: Has anyone news on Fabric 2 ?
Would love to know this as well.
Here's a comment I made some time ago on HN about similar / related Python libs / tools:
https://news.ycombinator.com/item?id=8735892#8737512
Edit: That comment was part of an HN thead about this topic, which might be interesting in its own right:
Streem – a new programming language from Matz (github.com)
https://news.ycombinator.com/item?id=8735892
https://news.ycombinator.com/item?id=8735892#8737512
Edit: That comment was part of an HN thead about this topic, which might be interesting in its own right:
Streem – a new programming language from Matz (github.com)
https://news.ycombinator.com/item?id=8735892
How's this different from sh or fabric?
Ive written numerous python wrappers around shell commands for all sorts of one off utils, but this is nice and flexible and generic. Sultan looks well thought out. Open to contributors?
Sultan is open for contribution. Feel free to put your thoughts in the Issues for features you'd like, and submit any Pull Requests for any issues that already exist.
Seems similar to the package sh/pbs. [0]
[0] https://amoffat.github.io/sh/
[0] https://amoffat.github.io/sh/
Yes it is. I looked at SH before writing Sultan. I was not very crazy about the syntax. I wanted the code to be easy to read, because one of my primary goals was the code maintainability, and that requires the code to be as readable as possible.
Trying very hard to ignore it, but to be honest... The logo looks like a smiling phallus.
No example even if you click on FAQ … what is sultan.
Huh? It has examples on the first page, the one that's linked in the submission.
how is it different from Fabric?
Nice stuff though
Nice stuff though
It is actually inspired by Fabric, but I was not very happy just using Strings. I also wanted better context management.
Fabric is great for DevOps, but there are applications that we build that aren't catered for DevOps work, and that is why I created Sultan.
Fabric is great for DevOps, but there are applications that we build that aren't catered for DevOps work, and that is why I created Sultan.
Very nice!
I've been using somewhat similar sh[1] for the same purpose. It's nice seeing more alternatives.
[1]https://amoffat.github.io/sh/
[1]https://amoffat.github.io/sh/
Two more resources on top of sh:
Invoke: http://www.pyinvoke.org/ wraps subprocess commands into Makefile-like tasks
Fabric: http://www.fabfile.org/ Same as invoke, but catered to remote subprocess commands over SSH
Invoke: http://www.pyinvoke.org/ wraps subprocess commands into Makefile-like tasks
Fabric: http://www.fabfile.org/ Same as invoke, but catered to remote subprocess commands over SSH
This was featured on HN the other day:
https://learnxinyminutes.com/docs/shutit/
https://news.ycombinator.com/item?id=14526567
https://learnxinyminutes.com/docs/shutit/
https://news.ycombinator.com/item?id=14526567
Very nice, as a side note I must say that I as an avid tmux-user much appreciated your "The Tao of tmux" piece!
There is also pyinfra [1], which provides the same sort of features for both local and remote devices, yet designed for consistent deployments and state diffing.
[1] https://github.com/Fizzadar/pyinfra
[1] https://github.com/Fizzadar/pyinfra
Xonsh is how to do this.
Xonsh is a shell that integrates Python at the command line. This is a library to make calls to the command line.
And your point is??
At the risk of simply putting words into noobiemcfoob's mouth:
"Xonsh is " NOT " how to do this."
"Xonsh is " NOT " how to do this."
OK. I thought this would be so obvious that people would see it. Sultan says "Sultan was created to help with scripts that we create with Bash, that tend to get complex." If one has an open mind, one should be asking "why would I use bash for this at all, when there exists a far superior command shell, xonsh, which incorporates all of bash's capability, with all of python, in one piece?"
Why are we trying to interface with bash to run commands from python in the first place? Cut out the middleman, bash, which is just a nuisance in the way.
Why are we trying to interface with bash to run commands from python in the first place? Cut out the middleman, bash, which is just a nuisance in the way.
You don't need to interface with bash necessarily you need to interface with binaries on the system like apt for example
Which is exactly what xonsh does.
The point would be that Xonsh is a Python command line. This is a Python library for running commands. So they definitely have two separate use cases.
Why not plumbum?
(I know why not to use plumbum)
(I know why not to use plumbum)
Thanks didn't know about plumbum.
What do you know?
What do you know?
bash is the best tool to write bash in, and writing a shell in python doesn't automatically make it pythonic.
Imagine writing a wrapper for "grep". It may work in one environment, but if you need portability, you're going to quickly realize that there are nuances in implementation and the actual calling interface. Now you're handling branching logic in your application code based on platform, version, etc.
Interfacing with a command line tool shouldn't be thought of much different than a remote HTTP/ReST API talking text/plain instead of application/json. You're looking for your "client wrapper" to handle argument validation, parsing, versioning, etc.