

Hell: A Haskell Shell - tikhonj
https://github.com/chrisdone/hell

======
miga
It is not a real shell, since it misses basic pipes. It is just a library for
renaming system functions to their Bash-like names...

Move on, and look at these:

* [http://hackage.haskell.org/package/Shellac](http://hackage.haskell.org/package/Shellac)

* [http://hackage.haskell.org/package/pipes-shell](http://hackage.haskell.org/package/pipes-shell)

* [http://hackage.haskell.org/package/HSH](http://hackage.haskell.org/package/HSH)

* [http://hackage.haskell.org/package/shellish](http://hackage.haskell.org/package/shellish)

~~~
asdasf
How does something this bad end up the top comment? Three out of four links
you provided are completely irrelevant. It is not missing pipes. Pipes are a
simple composition operator. Haskell already has that, no need to make a
special version for this.

~~~
klrr
While it's true that you can't really pipe _programs_ conveniently yet it sure
supports composition with all functions as you suggest. Just wanted to note in
case that was what the comment above was thinking about. Except that I pretty
much agree with you, current top comment is crap.

------
eternalban
See:
[http://www.haskell.org/haskellwiki/Simple_Unix_tools](http://www.haskell.org/haskellwiki/Simple_Unix_tools)
&
[http://www.haskell.org/ghc/docs/7.6.2/html/libraries/base-4....](http://www.haskell.org/ghc/docs/7.6.2/html/libraries/base-4.6.0.1/src/System-
Console-GetOpt.html)

ps: Haskell is such a Gloriously Happy Land, why make it "hell"?

~~~
chrisdone
Read the page?

~~~
eternalban
"Irony" is a side effect. Haskell is pure .. :P

------
sur
There's also scsh, which uses Scheme:

[http://www.scsh.net/](http://www.scsh.net/)

~~~
klibertp
Unfortunately, on FreeBSD:

    
    
        ===>  scsh-0.6.7 is marked as broken: fails to install on amd64.
    

And I really wanted to play with it. Seems like I will have to help in Scsh
reimplementation in Racket before I can do this.

------
st0neage
Hell? This could be heaven! For everyone.

~~~
CraigJPerry

        >> ls *.*
    

Vs.

    
    
        >> fmap (filter (isInfixOf ".")) ls'
    

No sale!

~~~
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.

------
marcosdumay
A shell made in a pure functional language... It does not look apealing (the
main use of a shell is to create side effects), but I'll sure try it.

~~~
deckiedan
As others have replied to you, I think you misunderstand what side effects &
IO are.

Imagine a "normal" shell type chain:

    
    
        ps -ef | grep 'elephant' | sort -nk2 >> logfile.txt
    

neither `grep`, nor `sort` should have any side effects, and if they do, then
you have potential for weird bugs later on. (imagine your / is mounted read
only, and sort has a side effect of writing everything to a temp file. now
suddenly this otherwise sane looking chain stops working).

In the command, you have a single input, and a single output (which has a
specific mode, append). Those are the only IO functions which you've
specified, but you have no guarantee that anything else will not make a mess
of things.

The dream for "pure functional" shell scripting would be where the side
effects are more obvious, and controllable, not to eliminate them.

~~~
joeyh
Sort _does_ have the side effect of writing to a temp file, when the input to
be sorted is large. :)

------
peq
I think most Unix commands have a function type which is not representable in
haskell, if you don't want to fall back to strings everywhere. So you end up
with many functions like ls and ls'. For a shell I prefer a dynamically typed
language.

~~~
joeyh
Typeclasses to the rescue..

    
    
        ls :: LsOptions -> IO Listing
    
        instance ToString Listing where ...
    
        instance Default LsOptions where def = LsOptions []
    

Now a single `ls` function can yield regular textual output, or the more
specific Listing type can be used if you want to say, map over the files
listed.

    
    
        toString <$> ls def
    
        map toUpper . filesListed <$> ls def
    

The repl can automate the application of toString of course, so the user can
just enter `ls def`. Someone better at this than I could probably find a way
to make the def parameter be optional, too.

------
mtdewcmu
It looks more usable than scsh, and I like the name.

