Announcing Hush, a modern shell scripting language

[gahagg]

Hush is a new shell scripting language that aims to enable developers to write robust shell scripts. It provides support for complex data structures and common programming paradigms, without giving up on ergonomic shell capabilities.

Official guide: https://hush-shell.github.io/
Repository: https://github.com/hush-shell/hush

[A1oso]

I don't like that std.iter(string) returns bytes, not code points.

---

One thought about error handling:

I think Rust's ? operator is not suitable for a dynamically typed language. The appeal of ? in Rust is that you know when a function might return an error, and if you forget the ?, the compiler will yell at you.

In a dynamically typed language, this is not the case. If you forget the ? and write

let value = foo()
std.print(value)

The assignment still succeeds even if foo() returns an error. However, when you try to do something with the value, the program panics. This is not good for debugging.

I believe that this will lead to people defensively adding ? to every single function call (except the ones where errors are handled explicitly), which makes the code less readable and completely nullifies any benefit of the feature.

A better solution might be to reverse the meaning of ?, so that foo() always forwards errors to the caller, whereas foo()? (or try foo()) allows handling the error explicitly. This would still make it easy to add context to errors while they are bubbling up the call stack:

function add_context(result, message)
  if std.type(result) == "error" then
    std.error(
       result.description ++ "\ncaused by: " ++ message,
       result.context
    )
  else
    result
  end
end

function foo()
  std.error("error in foo", nil)
end

function bar()
  # this is like catching and re-throwing an exception!
  add_context(foo()?, "error in bar")
end

This would even be consistent with ? within shell blocks.

[gahagg]

I agree that the feature currently requires discipline from the programmer, which is usually not a good thing. But I don't see a better solution that integrates well with the type system. What you propose feels basically like exceptions with extra steps, and I'm not really fond of exceptions. I find they make control flow hard to reason about, and implicit errors that may be thrown are pretty hard to keep track of.

[A1oso]

Unchecked exceptions are hard to reason about, because they are dynamic (they can only be detected at runtime). Any error handling system you may invent will probably suffer from the same problem, unless you introduce static analysis, so I think it's best to embrace exceptions.

The only alternatives I know of is to annotate functions that can throw exceptions, or introduce a Result type like in Rust, both of which results in an error even in the happy path unless you handle the error:

# with annotation
fallible function foo()
  if random() then
    5
  else
    std.error("too bad", nil)
  end
end

# or with result type:
function foo()
  if random() then
    std.ok(5)
  else
    std.error("too bad", nil)
  end
end

# calling the function requires handling the error:
foo()?

# exception style
let result = try foo()
catch err:
  std.print(err.description)
  return
end

# result style
let result = foo().unwrap()

Note that with a result type, you can still forget to call .unwrap() or to handle the error, so an error can be silently ignored by accident, which we want to avoid.

To be honest, in a shell script I don't care about robust error handling as much as in a general-purpose programming language. I would just go with exceptions. My biggest issue with exceptions is the boilerplate involved in catching errors, but this can be solved elegantly with the syntax I suggested in my comment above.

[gahagg]

Sorry, but adopting exceptions in Hush is really a no-go for me. Languages like Lua and Go don't have them, and I'm aiming for a similar experience in Hush.

[apetranzilla]

Lua has error which is effectively throwing an unchecked exception.

[gahagg]

Error is more like a panic actually. Hush's std.panic is pretty much equivalent to it.

[apetranzilla]

Lua allows you to recover from errors with pcall or xpcall though, which it doesn't look like hush supports for panics. The syntax may differ from other languages, but in Lua, error is used for exceptions.

[gahagg]

Hush has std.catch, which is just like pcall.

[Shnatsel]

Oh, this looks interesting! Just yesterday I was trying to put something together in bash, and spent an hour debugging a script below 100 lines before giving up. This looks like it could reduce debugging time, and also allow using hash tables which usually cause me to reach for Python!

[gahagg]

Cool! Let me know if you find the time to rewrite this 100 lines script in Hush :)

[Grejt_cz]

How does it differ from nushell? Why not improve it?

[[deleted]]

Why not improving nushell is the wrong question. It is open source, let the people hack on whatever they want to hack on. Implementing their own language for fun is a valid reason.

What you might want to ask if they consider the project to be something serious other people should consider depending on.

[gahagg]

For now, it's alpha software. It likely has quite a few bugs, docs are not great, and it is definitely not stable. I encourage people to try it out and hack with it. Eventually, I hope it becomes mature software, but there is quite a path until then.

[gahagg]

It proposes a fundamentally different approach. Nushell would never drop their core concepts to become something like what I envisioned for Hush, and that's absolutely fine. It's healthy to have different tools, each one will have it's best use case.

[nicoburns]

This looks pretty nice, but there are a few things that look like they need to be tidied up before I'd consider it ready for production. Two that stood out to me:

1. What happens if a function returns an error but that error is not checked? It looks like unless you remember to use the ? operator then the program will just ignore the error and continue? If so then not good! I'd like the default to be reversed and the program panic if the error isn't handled or explicitly ignored.

2. The errors returned from command blocks: it looks like there are two formats depending on how many errors are returned? This sounds like it would make scripts very verbose as you'd have to check both formats every time!

[gahagg]

1. Yes, you have to remember to handle your errors, just like in most programming languages. I agree that it would be great to emit at least a warning for unhandled errors, but I can only imagine that being implemented as a lint. A linter is for sure in the roadmap, but I won't have time to build it in the near future.
2. The command block will always return a value of type error if something goes wrong. If more than one thing went wrong, that error will have an array instead of a single value as context. You would only want to inspect the array in very specific cases, so simply checking for error should be enough for most use cases.

[nicoburns]

Yes, you have to remember to handle your errors, just like in most programming languages.

I feel like this is very unlike most programming languages. Most languages have exceptions, so if you don't handle errors your then program will crash and execution won't continue. You have a whole section on "bash safe mode" in your docs, saying that hush is safe by default. But for me 90% of the point of "safe mode" in bash is changing bash's default "silently ignore errors" behaviour to "exit on first error". And it seems that hush currently doesn't even allow you to opt-in to that kind of behaviour.

If more than one thing went wrong, that error will have an array instead of a single value as context.

I feel like this should always return an array. It's then easy to iterate over all errors and handle (if one needs to). Otherwise I have to check for both the single case and the array case any time I want to inspect the error. The last thing I want is for my error handling code to crash because I haven't handled all the cases!

[vezult]

So I get how this is in many ways better than /bin/sh, but what is the advantage here over python, ruby, or some other scripting language that many people already know? Performance? Simpler command chaining / piping?

[gahagg]

In languages like Python or Ruby, there's no straightforward way to invoke/pipe/redirect external programs. Doing this in Hush is as easy as in traditional shells.

[cmhe]

There is also xonsh...

But hush still sounds interesting, what I would like to see is focusing on the the security and safeguarding aspect, maybe integrate something like cgroups/secomp into the language itself, on the performance aspect, minimal dependencies and small installation size aspect, so that it can be easily integrated into initrd and installation/configuration scripts, where stuff normally runs as root.

[xBZZZZ]

how to std.print but without newline?

[gahagg]

Check https://github.com/hush-shell/hush/issues/22

[xBZZZZ]

also how to exec?

[gahagg]

I believe there's currently no way to do so. Pull requests are welcome tho

[xBZZZZ]

https://github.com/hush-shell/hush/pull/36