Shill: A Secure Shell Scripting Language | Hacker News Reader

Shill: A Secure Shell Scripting Language

shill-lang.org

85 pointsthinkmoore43 comments

Personally, I am not a big fan of putting more acl/config/monitor requirements to the shell. New features add complexity, possible bugs and hacking vectors.

Prefer just simply "git add /{etc,bin,sbin,lib} /usr/{bin,sbin,lib} ... && git commit "

And daily cron jobs run a "git status" would give me some idea, trigger and confident if someone have "hack into" the server.

Very relevant timing.

I've all but switched to zsh on my dev boxes but this looks to be a great option for production environments.

All but?

Edit: I meant to ask what your setup is like, such that you would describe yourself as being somewhere between "have switched" and "have not switched". It seems to me like it would be one or the other.

"All but" is synonymous to "completely", as far as I learned.

"All but" means "not quite completely", or "just shy of completely".

More precisely it means "almost" (here)

Well, zsh isn't much better than Bash. Fish beats both, but the web-based stuff annoys me. Given Windows has the super-powerful and elegant PowerShell, I think a new shell language is definitely needed.

Not just a shell language, I want a better/modern shell. Fish is pretty good but not quite and I don't need "newbie friendly".

Exactly! The newbie web configuration is such a turn off, but the language is definitely better - events and all.

You can always just edit config.fish in vim if you want to, that's what I do.

It's hard to explain, but just the fact that it has some huge useless feature bothers me.

Is it really that huge? The config pages are pretty simple, and it looks like it's just served using Python's built-in SimpleHTTPServer library.

It's some kind of a heuristic rule: Don't use a product by a guy with a vastly different mindset than your own.

Time for advertisements!

I've been doing this for some time: https://github.com/xiaq/elvish (https://news.ycombinator.com/item?id=8090534)

Thanks for reminding me about your project, which I saw earlier here! I was about to try it out and then forgot.

There was a powershell-like shell project for linux. Instead of a unified runtime it used d-bus to automatically pipe objects from a process to another.

Due to the d-bus dependency and other details, I remember it being a Gnome/RH-related project but I cannot remember the name.

(I'm not persuaded that d-bus is the best choice here, but still, it was an interesting project)

Anyone remembers it?

Wasn't that hotwire? [1]

1: https://pypi.python.org/pypi/hotwire

Thanks, but no.

Another detail I remember: its website or the blog of its author was surely online in 2011/2012 and it has a slightly brownish/reddish theme

PowerShell scripting is pretty terrible though. And it's concept is limited to only 1 runtime.

> super-powerful and elegant PowerShell

I'd agree, unfortunately it's pronounced PowersHell.

(by those who have to use it)

Can you be more specific? I think the language features and the ability to pass structured data vs text, the OOP features are what all shells should be doing in the new millennium.

Developer here, happy to answer any questions.

Developer in Racket, does not have S-expressions syntax? Why? Would love to use some scripting lisp on my machine.

Maybe some lisp hackers gradually find out that a lot of parenthesis is not that fun for everyone. Not meant to enrage Lisp hackers, I actually find parenthesis bearable.

There is also Pyret(http://www.pyret.org/) created by some people on the PLT team (you can confirm this by looking at the owner of their Github repo https://github.com/brownplt/pyret-lang). But more surprisingly it's implemented in JavaScript...

As usual, one just need a paredit equivalent to forget about parens forever. I also remember an extension (maybe emacs, or a scheme SRFI) removing the top-level parens (implicit rewriting rule).

    repl> defun id (x) x

    repl> defun fact (n)
            (if (< n 2)
               1
               (* n (recur (1- n))))

A little more pleasant for people used in curly braces I'd say.

Codes are read much more often than written.

paredit makes editing parens easier, but reading them is still difficult for the unskilled (rainbow parens help, but it's still far from painless). Compare this to how autocompletion makes it easier to write a VeryVeryVeryVeryVeryVeryVeryLongMethodName but doesn't make it any easier to read.

I don't know, properly abstracted LISP code is 'supposed' to be tiny (you have all you need to write nice DSL/API) so you don't have long winded things on screen.

And I have a differing opinion about code meant to be read. This is a side effect of syntaxful languages read statically in buffer editors. You want to understand LISP ? you load the code, play with and evaluate sub expressions, and sexps/paredit is of great help here.

I think you're referring to sweet-expressions. http://srfi.schemers.org/srfi-110/srfi-110.html

--Nope-- Kinda, I actually blended this with something else, which was more of a simple editor hack to avoid typing the top parens. Now things are clear. Thanks for the link though.

Anybody actually wrote code in sw-exps ?

Pyret is implemented in JavaScript so we can have a completely in-browser runtime. And since the Pyret compiler is implemented in Pyret, that comes along for free and can be run in the browser as well. JS is far from an ideal compilation target (especially for a functional language, it requires jumping through some extra hoops [1]), but compiling to it lets us deliver the language to students with no installation necessary [2].

[1] http://www.ustream.tv/recorded/43777177 [2] https://code.pyret.org

Hey, I just checked out your homepage and learned that Pyret is already being used to teach programming at Brown University. Cool!

Good luck convincing a serious Lisp afficionado that his preferred syntax schema isn't some kind of Platonic ideal though.

If your machine is running some Unix OS, then PicoLisp is what I would recommend. -> http://picolisp.com/

So you'd want something like the Lush of yore?

http://lush.sourceforge.net/

SCSH: http://scsh.net/

I would have thought the best way to do secure shell scripting is to use a non-shell language, e.g. Python or Go.

It seems most shell vulnerabilities (including shellshock) fundamentally come from the awful and dangerous syntax.

Fundamentally, it's not an issue of syntax. The problem is that the way commodity systems are set up, the capabilities of a script or program come from the environment in which it is run. There is no way that a user can easily tell what a script will do, even if it isn't malicious or doesn't have a code injection vulnerability.

Can't say I like the name; it evokes nothing but negative connotations.

I just find it so amusing, personally. I like it. It fits in with the security theme relatively well, too.

How does "shill" relate to security in any kind of fashion? Am I missing something?

in the same way that the name "john the ripper" relates to security

it's just a cute name

It has that rogue intelligence/geopolitical power play to it.

It's a play on the name "Scheme" and "Schemers" which was continued by the "Racket" and "Racketeers" name. There's something of a history of naming things like this in the LISP community. Wikipedia says:

"Scheme was originally called 'Schemer', in the tradition of other Lisp-derived languages like Planner or Conniver."

Your reaction is, however, valid. People outside the Scheme community and it's closely related communities are unlikely to know this etymology.

Reply on news.ycombinator.com