Shake draws inspiration from Python's sh. Which looks to me like a port of http://perldoc.perl.org/Shell.html. However after experience, that original version now comes with important warnings about things like metacharacter quoting not being able to be done in a portable and safe way.

It is easy to get things 95% right, and I am sure that Shake does that. But think twice before using it for production programs, particularly if there is any possibility of it encountering untrusted input.

> We will have a beautiful DSL so you don’t have to quote arguments as string...

If i'm using Perl's Shell.pm (as mentioned elsewhere here by btilly) and wanted to avoid quoting arguments then I could do:

  use 5.016;
  use warnings;
  use Shell ();

  use PerlX::QuoteOperator ls => {
    -emulate => 'qq',
    -with    => sub ($) { Shell::ls($_[0]) },
  }; 

  use PerlX::QuoteOperator uname => {
    -emulate => 'qq',
    -with    => sub ($) { Shell::uname($_[0]) },
  }; 

  use PerlX::QuoteOperator ip => {
    -emulate => 'qq',
    -with    => sub ($) { Shell::ip($_[0]) },
  }; 

  # and then...

  ls();
  uname(-a);
  ip(-4 addr);

  `ls`;
  `uname -a`;
  `ip -4 addr`;

  my $x = "/usr/local/";
  my $files = `ls -l $x`;

  my $perl_files = `ls | grep .pl`;

This is a really bad idea. It's not even close to useful right now. For instance, you can't use variables in your shell invocation, so this doesn't work:

    (let [x "/usr/local"] (ls -l x))

Good luck.

All these efforts to provide pretty & convenient interfaces to arbitrary executables strike me as being useful only for people who want a powerful REPL as their command-line prompt and/or would rather use Clojure or Python (or whatever other language) for mundane tasks that would otherwise normally be done with throwaway shell scripts. Outside of these limited use cases, I'm not sure this sort of thing is a good idea.

Creating this was probably fun and a good learning experience, but I wouldn't recommend trying to push it beyond that point. The problem Shake solves doesn't call for the sort of DSL that uses macros to make Clojure code act like something other than Clojure code.

I'd rather have something like https://github.com/clojure/tools.cli but in reverse: a library for building, manipulating, and running command lines and interacting with the results ... maybe something that supports setting up mappings so that external programs can be exposed as Clojure fns with "Clojuresque" arguments "--rather" "than" "--arrays-of" "strings".

That's both wonderful and scary. I think the UI of it needs work -- if you want to treat all shell commands as functions, they imho should just return their outputs by default. (Potentially as a lazy list of lines?)

Also, I think that path should not be passed in as an environment variable, but in Clojure somehow. There's no reason for a program to pollute a global namespace with it's internal details.

Sounds very much like pallet's stevedore.

http://palletops.com/doc/reference/script/ https://github.com/pallet/stevedore

This was already pioneered by Olin Shivers' SCSH (Scheme Shell). See the process notation chapter in the SCSH Reference Manual: http://www.scsh.net/docu/html/man-Z-H-3.html#node_chap_2. Wish the SCSH project would come alive again: https://github.com/scheme/scsh.

That's great. Next step is implementing piping :-)

This is actually pretty neat, specifically the part about indexing the executables available in your path and turning them into macros. I was underwhelmed at first because I thought you manually implemented each program.

I can't really imagine a use case for this for me (bash! But with parens!) but still very neat idea and cool execution.

A function? Really? Without side effects?)

You can set environment variable SHAKE_PATH to specify path that you want to initialize.