5 ms·

Is this really a shell scriping language? Hush isn't an interactive shell, nor does it compile to a common shell script. The only way to run these scripts is to

Is this really a shell scriping language? Hush isn't an interactive shell, nor does it compile to a common shell script. The only way to run these scripts is to install the hush interpreter and run the script through it. Isn't that just a normal scripting language? What's the real benefit of using this over Node or Python? I suppose the syntax is more aesthetically similar to shell scripts... but I don't exactly see that as a plus.

da39a3ee 4y ago
The point is that you can do things like create external processes, pipe them together, redirect output to files, with the same ultra-lightweight syntax of bash etc. Compare that to all the nonsense you have to do in Node or Python to pipe two processes together!
- gorgoiler 4y ago
  You’re right in that writing Python using shell paradigms is awful. Writing Python that shells out to do stuff — but using Python paradigms — isn’t so bad. Particularly if you are used to calving off your shell stuff into shell functions that run something and massage the output. In Python you end up doing something pretty similar: yield the text you want and use that as arguments to the next call to subprocess.run. Basically “| xargs command” but nicer.
- feanaro 4y ago
  This is a thing: https://pypi.org/project/plumbum/ https://pypi.org/project/plumbum/
  - mypalmike 4y ago
    Wow that's clever. Scary and clever. I might try it out.
  - geophile 4y ago
    This too: https://marceltheshell.org https://marceltheshell.org.
dahfizz 4y ago
System level stuff sucks in Python. Dealing with files, I/O, permissions, etc is a real pain. It easily takes 5x as long and as many loc to do the same thing as in bash. I can see the benefit of dropping to a command block to, say, run a command and filter the output with some | grep | awk | sort of whatever, and then seamlessly come back up to a more fully featured language to deal with that data.
- gorgoiler 4y ago
  This is very true, particularly if your script is just an imperative list of commands to run. Python scripts win when you actually need to handle errors, or non trivial output parsing, or when the concept of “list of things” doesn’t fit neatly into the “lines of text / pipe symbol” paradigm. I try to think of it like Donkey Kong. Every time you do something like this: var=$(command | awk -vID=$ID ‘$6 ~ /foo/ and $7 == ID {print $1 “ “ $2} | head -3) …you get hit by a barrel. Three hits and you turn it into a Python module with a __main__.py or an if __name__ == “__main__” at the bottom. If it’s a truism that most shell scripts are better off written in Python, it’s just as true that all Python scripts are better off as reusable modules (that may also be standalone scripts.)
- spsesk117 4y ago
  I feel like you just described Perl, and I use Perl almost every day for this kind of thing, but people seem to hate it these days. The syntax can be weird, but I still think it really shines in cases like these.
- sverhagen 4y ago
  My experience is different. For me, Python has a good balance of readability, access to system functions and consistent, predictable interfaces. I'm not saying you're wrong, just that "it depends". I'm pretty adequate at writing BASH, but it's not my "daily driver" programming language, so I have to still try things out, google a lot of things that aren't easily obvious, and excessive trial and error. But as a Java programmer I also know that Java, with all of its abstractions and verbosity, is a complete non-starter for shell scripting. For me, Python has often been a helpful compromise. Part of this may also be that I've never learned to do a great job at organizing a BASH shell "project". So, those often get unwieldy maintenance nightmares. At plenty of time me and my peers have agreed: when your BASH script exceeds [some low number of] lines, find another language. Again, it matters a lot what your team's culture and comforts are. If that's BASH for you, then r.e.s.p.e.c.t.
inopinatus 4y ago
Counterpoint: I work at the REPL of scripting languages roughly as much as I do the shell prompt.
- patrck 4y ago
  Every shell is a REPL Using your editor to drive a shell is a huge win because it: (a) flips the development bit in your brain, and (b) creates a shared history across all your machines. Combine that with literate programming and you have a `duck-talking` history of every development or outage response tied to what you actually did.
  - gorgoiler 4y ago
    Don’t you ever use a debugger? Don’t you consider that a REPL? It’s the same paradigm as a REPL with the same upsides and downsides.
    - patrck 4y ago
      Definitely. Debugging loves `duck-talking`. Didn't mean to come across as REPLs consisted only items in the set of { programming , shells }.
cjohnson318 4y ago
I love Python, but if all I need to do is grab one part of one line of something, and put it into some other command, then I'm just going to use some unholy mixture of sed, awk, or whatever. If I did the same thing in Python, I'd end up with thirty lines or more.
- gorgoiler 4y ago
  Thirty lines? Unholy one liners are not limited to shell scripting: from subprocess import check_output sh = lambda script: check_output(script, shell=True, text=True) ips = set(line.split()[-1] for line in sh('last -a').splitlines() if line and 'tmux' not in line) The first two lines are pure overhead. The last line is the equivalent of a shell script one liner but now has all the advantages of a language that supports “\N{clown face}”.
  - geocar 4y ago
    > The first two lines are pure overhead. In 200 bytes half of which is overhead. That's not a great start. > The last line is the equivalent of a shell script one liner It's slower and requires much much more typing, and anything I want to add isn't going to go in the right place. It has a gross hack to support "tmux", and produces other spurious output (bugs). I don't want my X sessions or other ptys; I have reverse DNS disabled, and I really just want IP addresses. This is what I would write in shell: last -a|sed -e 's/.* $[0-9a-f]*[:.][0-9a-f.:]*$$/\1/;t;d'|sort -u > now has all the advantages of a language that supports “\N{clown face}”. This is a joke right? I have twenty cores, this is going to use three. Python is going to use one. 30% less typing, less bugs, faster. Those things are important. A fucking emoji is not.
    - gigatexal 4y ago
      for those of us with not as much grey in our beards (+1 this response if you get the joke) the python example is a ton more readable to me. Now that probably doesn't matter if the utility is only for you. I've a number of helper programs/scripts/etc that I use that I wrote and are only for my consumption. Re the paralell stuff and python it's easy to import multiprocessing and take advantage of all cores. I think where python wins is how easy it is to handle errors and organize things as it's a full fat programming language vs a shell scripting language like Bash + the gnu userland.
cookiengineer 4y ago
The purpose of OP's project kind of reminded me of shell.js (shx) [1] which is a nodejs library that wraps all kinds of common UNIX commands to their own synchronously executed methods. I guess that most shell projects start off as wanting to be a cross-platform solution to other operating systems, but somewhere in between either escalate to being their own programming language (like all the powershell revamps) or trying to reinvent the backwards-compatibility approach and/or POSIX standards (e.g. oil shell or zsh). What I miss among all these new shell projects is a common standardization effort like sh/dash/bash/etc did back in the days. Without creating something like POSIX that also works on Windows and MacOS, all these shell efforts remain being only toy projects of developers without the possibility that they could actually replace the native shells of other operating systems. Most projects in the node.js area I've seen migrate their build scripts at some point to node.js, because maintaining packages and runtimes on Windows is a major shitshow. node.js has the benefit (compared to other environments) that it's a single .exe that you have to copy somewhere and then you're set to go. When I compare that with python, for example, it is super hard to integrate. All the anaconda- or python-based bundles for ML engineers are pretty messed up environments on Windows; and nobody actually knows where their site-packages/libraries are really coming from and how to even update them correctly with upstream. [1] https://github.com/shelljs/shelljs https://github.com/shelljs/shelljs
HelloNurse 4y ago
> The only way to run these scripts is to install the hush interpreter and run the script through it Exactly like any other shell, and consider how inconvenient and hazardous a transpiler "to a common shell script" would be.

da39a3ee 4y ago

The point is that you can do things like create external processes, pipe them together, redirect output to files, with the same ultra-lightweight syntax of bash etc. Compare that to all the nonsense you have to do in Node or Python to pipe two processes together!

gorgoiler 4y ago
You’re right in that writing Python using shell paradigms is awful. Writing Python that shells out to do stuff — but using Python paradigms — isn’t so bad. Particularly if you are used to calving off your shell stuff into shell functions that run something and massage the output. In Python you end up doing something pretty similar: yield the text you want and use that as arguments to the next call to subprocess.run. Basically “| xargs command” but nicer.
feanaro 4y ago
This is a thing: https://pypi.org/project/plumbum/ https://pypi.org/project/plumbum/
- mypalmike 4y ago
  Wow that's clever. Scary and clever. I might try it out.
- geophile 4y ago
  This too: https://marceltheshell.org https://marceltheshell.org.

dahfizz 4y ago

System level stuff sucks in Python. Dealing with files, I/O, permissions, etc is a real pain. It easily takes 5x as long and as many loc to do the same thing as in bash. I can see the benefit of dropping to a command block to, say, run a command and filter the output with some | grep | awk | sort of whatever, and then seamlessly come back up to a more fully featured language to deal with that data.

gorgoiler 4y ago
This is very true, particularly if your script is just an imperative list of commands to run. Python scripts win when you actually need to handle errors, or non trivial output parsing, or when the concept of “list of things” doesn’t fit neatly into the “lines of text / pipe symbol” paradigm. I try to think of it like Donkey Kong. Every time you do something like this: var=$(command | awk -vID=$ID ‘$6 ~ /foo/ and $7 == ID {print $1 “ “ $2} | head -3) …you get hit by a barrel. Three hits and you turn it into a Python module with a __main__.py or an if __name__ == “__main__” at the bottom. If it’s a truism that most shell scripts are better off written in Python, it’s just as true that all Python scripts are better off as reusable modules (that may also be standalone scripts.)
spsesk117 4y ago
I feel like you just described Perl, and I use Perl almost every day for this kind of thing, but people seem to hate it these days. The syntax can be weird, but I still think it really shines in cases like these.
sverhagen 4y ago
My experience is different. For me, Python has a good balance of readability, access to system functions and consistent, predictable interfaces. I'm not saying you're wrong, just that "it depends". I'm pretty adequate at writing BASH, but it's not my "daily driver" programming language, so I have to still try things out, google a lot of things that aren't easily obvious, and excessive trial and error. But as a Java programmer I also know that Java, with all of its abstractions and verbosity, is a complete non-starter for shell scripting. For me, Python has often been a helpful compromise. Part of this may also be that I've never learned to do a great job at organizing a BASH shell "project". So, those often get unwieldy maintenance nightmares. At plenty of time me and my peers have agreed: when your BASH script exceeds [some low number of] lines, find another language. Again, it matters a lot what your team's culture and comforts are. If that's BASH for you, then r.e.s.p.e.c.t.

inopinatus 4y ago

Counterpoint: I work at the REPL of scripting languages roughly as much as I do the shell prompt.

patrck 4y ago
Every shell is a REPL Using your editor to drive a shell is a huge win because it: (a) flips the development bit in your brain, and (b) creates a shared history across all your machines. Combine that with literate programming and you have a `duck-talking` history of every development or outage response tied to what you actually did.
- gorgoiler 4y ago
  Don’t you ever use a debugger? Don’t you consider that a REPL? It’s the same paradigm as a REPL with the same upsides and downsides.
  - patrck 4y ago
    Definitely. Debugging loves `duck-talking`. Didn't mean to come across as REPLs consisted only items in the set of { programming , shells }.

cjohnson318 4y ago

I love Python, but if all I need to do is grab one part of one line of something, and put it into some other command, then I'm just going to use some unholy mixture of sed, awk, or whatever. If I did the same thing in Python, I'd end up with thirty lines or more.

gorgoiler 4y ago
Thirty lines? Unholy one liners are not limited to shell scripting: from subprocess import check_output sh = lambda script: check_output(script, shell=True, text=True) ips = set(line.split()[-1] for line in sh('last -a').splitlines() if line and 'tmux' not in line) The first two lines are pure overhead. The last line is the equivalent of a shell script one liner but now has all the advantages of a language that supports “\N{clown face}”.
- geocar 4y ago
  > The first two lines are pure overhead. In 200 bytes half of which is overhead. That's not a great start. > The last line is the equivalent of a shell script one liner It's slower and requires much much more typing, and anything I want to add isn't going to go in the right place. It has a gross hack to support "tmux", and produces other spurious output (bugs). I don't want my X sessions or other ptys; I have reverse DNS disabled, and I really just want IP addresses. This is what I would write in shell: last -a|sed -e 's/.* $[0-9a-f]*[:.][0-9a-f.:]*$$/\1/;t;d'|sort -u > now has all the advantages of a language that supports “\N{clown face}”. This is a joke right? I have twenty cores, this is going to use three. Python is going to use one. 30% less typing, less bugs, faster. Those things are important. A fucking emoji is not.
  - gigatexal 4y ago
    for those of us with not as much grey in our beards (+1 this response if you get the joke) the python example is a ton more readable to me. Now that probably doesn't matter if the utility is only for you. I've a number of helper programs/scripts/etc that I use that I wrote and are only for my consumption. Re the paralell stuff and python it's easy to import multiprocessing and take advantage of all cores. I think where python wins is how easy it is to handle errors and organize things as it's a full fat programming language vs a shell scripting language like Bash + the gnu userland.

cookiengineer 4y ago

The purpose of OP's project kind of reminded me of shell.js (shx) [1] which is a nodejs library that wraps all kinds of common UNIX commands to their own synchronously executed methods. I guess that most shell projects start off as wanting to be a cross-platform solution to other operating systems, but somewhere in between either escalate to being their own programming language (like all the powershell revamps) or trying to reinvent the backwards-compatibility approach and/or POSIX standards (e.g. oil shell or zsh). What I miss among all these new shell projects is a common standardization effort like sh/dash/bash/etc did back in the days. Without creating something like POSIX that also works on Windows and MacOS, all these shell efforts remain being only toy projects of developers without the possibility that they could actually replace the native shells of other operating systems. Most projects in the node.js area I've seen migrate their build scripts at some point to node.js, because maintaining packages and runtimes on Windows is a major shitshow. node.js has the benefit (compared to other environments) that it's a single .exe that you have to copy somewhere and then you're set to go. When I compare that with python, for example, it is super hard to integrate. All the anaconda- or python-based bundles for ML engineers are pretty messed up environments on Windows; and nobody actually knows where their site-packages/libraries are really coming from and how to even update them correctly with upstream. [1] https://github.com/shelljs/shelljs https://github.com/shelljs/shelljs

HelloNurse 4y ago

> The only way to run these scripts is to install the hush interpreter and run the script through it Exactly like any other shell, and consider how inconvenient and hazardous a transpiler "to a common shell script" would be.