[chrisdone]

Completely fair criticism. Obviously, I don't mean to continue writing such lengthy code on the command-line, but in order to feel out what's good enough, I need the shell. The brevity can come later. E.g. there's no reason

    ls "*.*"

couldn't be defined, e.g.

    ls = run . ("ls " ++)

[saidajigumi]

I'd argue that even the double-quotes in `ls "."` are too much for normal usage. There have been many attempts at creating non POSIX-y shells based on various languages, but AFAICT it's a non-starter to require special syntax when running basic command lines. I'm mostly not writing shell scripts, I'm using a command line to interact with the system. As such, I want no barrier to running programs yet a lightweight way to leverage a "real" programming language. Redefining tools like `ls` seems like a red herring as well. I'm not against built-ins (they're necessary), but the Unix toolchain isn't going anywhere anytime soon. You'll still need to pull data out of git, logfiles, munch that data with external tools, etc. As such it's worth thinking about how to best bridge these worlds. If the shell environment can provide a better ls, that's fine, but I suspect it's a design bug if it feels like it needs the built-in for day-to-day usage.

On "feel", it also feels like there should be a seamless syntactic protocol for post-POSIX shells, but I've yet to nail down how it would work. Straw-man requirements:

    - Absolutely no special syntax to run programs
    - Low-drama way to write "real code", i.e. native 
      scripting language syntax.
    - Great integration via syntax, shell built-ins for 
      working in Unix-y pipeline.
    - Replace powerful yet bizarre bash/zsh parameter 
      constructs with better native language tools.

By low-drama, think of the success of Markdown vs. HTML, TeX, etc. for markup. Not as powerful, but much easier to use for its use cases. IMO, this is the most powerful thing about the POSIX shells -- there's zero ceremony around running programs and dealing with I/O redirection. That's also the compromise, as things like quoting semantics get hairy. One way a post-POSIX shell could go is to retain this seamlessness while adding a touch more modality so that the worst problems of POSIX shells are eliminated. For example, multiple-quoting or re-quoting should never be needed, real data structures are both available and the default, etc.

Anyhow, Hell looks like a fun experiment and sandbox. Enjoy!

[hyperpape]

I agree completely. I've been thinking about this a lot, and non-quoted strings strike me as an absolute requirement for anything that aims to replace the bourne shell and its descendants (as opposed to complementing them in the way that Perl/Python/Ruby do it). But obviously it's hard to have non quoted strings in a programming language.

I need to play more with TCL (the one non sh-like language I know that does this) but I think even it has some very strange features that grow out of treating ordinary text as strings.