[Haskell] Re: ANN: HSH (Haskell Shell) 0.1.0
On 2006-06-06, John Goerzen [EMAIL PROTECTED] wrote: Hello, Following the release early, release often motto, I am happy to announce version 0.1.0 of HSH, the Haskell shell. Awesome. * Pure Haskell functions are as much a first-class citizen as is grep or cat I would say more so, actually. For actual usability as a primary shell, I'd want that reversed -- running commands is what shells do. Adding easy access to haskell functions on top would be great. -- Aaron Denney -- ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANN: HSH (Haskell Shell) 0.1.0
Hello, Following the release early, release often motto, I am happy to announce version 0.1.0 of HSH, the Haskell shell. You may obtain it with: darcs get --tag 0.1.0 http://darcs.complete.org/hsh Things are still very rough in many ways, but this version already lets you: * Run commands * Pipe things between commands * Pipe command input/output into and out of pure Haskell functions * Pure Haskell functions are as much a first-class citizen as is grep or cat Here is an example session: $ ghci -fglasgow-exts HSH *HSH run $ (ls, [.]) COPYINGHSHHSH.hsTODOannouncements testsrc COPYRIGHT HSH.cabal Makefile _darcs test.hs *HSH run $ (ls, [-l]) -|- (wc, [-l]) 12 *HSH :m +Text.Printf *HSH Text.Printf let countLines = (zipWith (\i line - printf %-5d %s i line) [(1::Int)..])::([String] - [String]) *HSH Text.Printf run $ (ls, [-l]) -|- countLines -|- (grep, [hs$]) 6 -rw-r--r-- 1 jgoerzen jgoerzen 1285 Jun 6 09:43 HSH.hs 11-rw-r--r-- 1 jgoerzen jgoerzen 565 Jun 6 09:43 test.hs *HSH Text.Printf :m +Data.List *HSH Text.Printf Data.List run $ (ls, [-l]) -|- countLines -|- filter (isSuffixOf hs) 6 -rw-r--r-- 1 jgoerzen jgoerzen 1285 Jun 6 09:43 HSH.hs 11-rw-r--r-- 1 jgoerzen jgoerzen 565 Jun 6 09:43 test.hs *HSH Text.Printf Data.List run $ (ls, [-l]) -|- countLines -|- filter (isSuffixOf hs) -|- (tr, [a-z, A-Z]) 6 -RW-R--R-- 1 JGOERZEN JGOERZEN 1285 JUN 6 09:43 HSH.HS 11-RW-R--R-- 1 JGOERZEN JGOERZEN 565 JUN 6 09:43 TEST.HS *HSH Text.Printf Data.List let generator = \(_::String) - unlines . map show $ [1..20] *HSH Text.Printf Data.List generator 1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n11\n12\n13\n14\n15\n16\n17\n18\n19\n20\n *HSH Text.Printf Data.List run $ generator -|- (grep, [1]) 1 10 11 12 13 14 15 16 17 18 19 Future versions will likely simplify syntax to make it easier to write scripts and introduce a sh to hsh converter. I also plan to add pure Haskell tools for some common shell-ish things that one could do in Haskell. -- John ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] develop new Haskell shell?
Jared Updike wrote: It would also be wise to look at occam and erlang and see if they have any useful ideas. And, of course, Windows PowerShell. And scsh (Scheme shell, pretty full featured these days): http://www.scsh.net/ At http://jaortega.wordpress.com/2006/05/16/not-your-parents-shell/ there is an interesting blog post about scsh and a new frontend for it called Commander S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: develop new Haskell shell?
On 2006-05-12, Jeremy Shaw [EMAIL PROTECTED] wrote: At Thu, 11 May 2006 23:05:14 +0100, Brian Hulley wrote: Of course the above could no doubt be improved but surely it is already far easier to understand and much more powerful than the idiosyncratic text based approach used in UNIX shells (including rc). The idea of representing unix pipes as monads has been around for a while -- but what most people fail to account for is that many (most?) real-world shell scripts also need to deal with return values and stderr. Even standard unix shells are pretty terrible in this regard -- so if we could do it *better* than standard shells -- that could be pretty compelling. Here are some simple examples of things to handle, starting with failures in a pipeline: $ aoeu | cat -n ; echo $? bash: aoeu: command not found 0 $ Sweet! A successful return code even though there is clearly a failure. Bash 3.x *finally* added, set -o pipefail -- which would cause the above to return an error. Unfortunately, there is no way to tell which part of the pipeline failed, or any way to attempt recovery of the part that failed. See also the pipestatus/PIPESTATUS arrays in e.g. zsh and ksh. Maybe it's in bash too these days. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: develop new Haskell shell?
On 2006-05-12, Max Vasin [EMAIL PROTECTED] wrote: Brian == Brian Hulley [EMAIL PROTECTED] writes: Brian Some other possibilities are: Brian 1) Every command returns a pair consisting of result and return Brian code IMHO the distinction between command's output (to stdout and stderr) and its return code is one of the faults in UNIX shells. Nothing, but log should be written to stdout by command, and stderr should be useless if we use exceptions (I'm not quite sure). You have failed to grasp the problem domain and the composability provided. Requiring names for output is worse than requiring names for functions. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] develop new Haskell shell?
Wow.. quite many responses.. I'll have to rearead them thoroughly.. ;) I think GHCI would be great (expect it's start up time compared to bash ;) I wouldn't use hs-plugins because it needs quite a lot of time to compile pieces of code.. I got the idea to use something like Don Libes expect/pexpect (python) as layer between user/ghci ? So you can use short characters beeing expanded? Problem: How to get to know when ghci has finished executing a command? I don't like the approach to putting every command in a function by default. But I want to do so for some commands. Eg sox/ aplay, For most small problems you can't get a shorter command than using bash.. So why not be able to switch. Meta-b - bash Meta-h - haskell Meta-9 - plan9 And after executing a command with bash take over the environment variables? One thing I'd really like to improve is history/ completion. So it would be cool to extend ghci to be able to use something like class Completion Completable where getCompletions :: Completable - firstChars - [String] or doCompletion :: Completable - firstChars - IO Completion or something more general perhaps even providing some list to select individual filenames... I'd also like to do somehthing like prog1 | prog2 | prog3| xargs mplayer .. Then prog1-3 and mplayer may be running at the same time. I still want to be able to send keys to prog1,2,3 and mplayer.. (eg to mute mplayer or to speed the music up, goto the next file, ) That would be reallly cool and interactive ;) Marc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] develop new Haskell shell?
We haven't talked about bash features like !:1 !:$ yet !:1 means first argument of last commands, !:$ means last argument of last command Some kind of completion could also be achieved by using this completion:: IO (a) -- a in this case Filename liftM cat completion where is a function (or another program) with it's own interface... beeing executated after pressing enter.. A haskell shell would be nice because you could also do something like this (in the manner of formIntegral) : dvd - (fromVideo viedo.mov))::MyDVD butn dvd mkiso dvd ;) Wow!!! You would be able to assemble common task in a new, type-safe fashion. fromVideo of cause would itself call something like mplayer or transcode. Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] develop new Haskell shell?
Donn Cave wrote: On Thu, 11 May 2006, Brian Hulley wrote: ... -- catenate all files in a specified directory catenate outputFile dir = withDir dir $ ls = cat outputFile So, you would apply this like catenate result /etc/stuff ? String literals need quotes? Yes - why not? Also, on Windows for example, filenames can have spaces so quotes are needed anyway with any shell at the moment if such filenames are used. However if this was a real problem it *might* be possible to relax the need for quotes by using a much more complicated parsing algorithm that could take into account the types of expected args and coerce the appropriate unquoted lexemes/expressions into strings, but I don't know if this would really be worth the trouble, and it would introduce ambiguity eg is etc/stuff a filename or an arithmetic expression? Of course the above could no doubt be improved but surely it is already far easier to understand and much more powerful than the idiosyncratic text based approach used in UNIX shells (including rc). (cd /etc/stuff; cat * result) Well the problem here is that the command leaves you in /etc/stuff so you have to remember this when you subsequently execute another command. The advantage of withDir is that the original directory is restored afterwards, which might make it easier to write modular scripts. In any case you could also make a cd command in Haskell, and write: cd etc/stuff ls = cat result ? renif extFrom extTo fileName = case split fileName of (n, ext) | ext == extFrom - rename fileName (unsplit (n, extTo)) _ - return () %ls = mapM_ (renif txt hs) $ for a in *.txt; do mv $a $(basename $a .txt); done Well someone had to define the meaning of basename so if we make the definition of renif similarly built-in the comparison is between ls = mapM_ (renif txt hs) and for a in *.txt; do mv $a $(basename $a .txt); done So the Haskell command is shorter, easier to read, and more re-usable, because mapM_ (renif txt hs) can be used anywhere that supplies a list of files whereas for a in *.txt doesn't make the source of the list explicit. Do they come from the current directory? What if some other list of files should be used? ? Not saying the UNIX shell is a rich and well structured programming environment, and maybe FP is a good direction for that problem. But don't underestimate it, the principles behind it are sharp, and while I think you could expect to win on complex data structures, you can't afford to lose on simple commands, because that's where most of the action is. From the above even the simple commands are easier in Haskell. The only drawback is the need to put quotes round filenames/paths but imho this doesn't seem like a major problem compared to the ease with which complex commands can be built up and the advantage of only having to learn one universal language. Hm. Not to pick at the details too much, but you know cat is actually a standard UNIX command, that writes to standard output and has no output file parameter? What's up with the new parameter in your version - was it not going to be workable the way it was? I forgot about this. You could define cat in Haskell as: cat :: [FileName] - Shell String and have another command analogous to to write a string into a file, say into into :: FileName - String - Shell () Then you could catenate all files in the current directory into a file called result by: ls = cat = into result (Same as cat * result) So in balance I think that while some UNIX commands may be slightly shorter, the shortness comes at the expense of the assumptions they have to make about the kinds of things you want to do eg cat * works well if the only possible source of files is the current directory, but doesn't work at all if you want to create a list of files from some other operation (unless you create a temporary directory with symlinks etc but it easily degenerates into a very complicated mess compared to Haskell). Regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] develop new Haskell shell?
Jeremy Shaw wrote: At Thu, 11 May 2006 23:05:14 +0100, Brian Hulley wrote: Of course the above could no doubt be improved but surely it is already far easier to understand and much more powerful than the idiosyncratic text based approach used in UNIX shells (including rc). The idea of representing unix pipes as monads has been around for a while -- but what most people fail to account for is that many (most?) real-world shell scripts also need to deal with return values and stderr. Even standard unix shells are pretty terrible in this regard -- so if we could do it *better* than standard shells -- that could be pretty compelling. [snip lots of examples and other interesting points] Some other possibilities are: 1) Every command returns a pair consisting of result and return code 2) Use exceptions instead of stderr 3) Use a more complicated monad It may still be a good idea to take the top 20 unix utils and code them as native haskell functions and see how far that goes. I know there are some existing libraries that deal with basic stuff like mv, etc. Has anyone implemented grep, find, etc? This is also how I would start because it would allow all the control flow/ ease of use issues to be explored just using GHCi / Hugs etc before tackling the problem of how to get binaries to interface with the shell. Regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: develop new Haskell shell?
Brian == Brian Hulley [EMAIL PROTECTED] writes: Brian Some other possibilities are: Brian 1) Every command returns a pair consisting of result and return Brian code IMHO the distinction between command's output (to stdout and stderr) and its return code is one of the faults in UNIX shells. Nothing, but log should be written to stdout by command, and stderr should be useless if we use exceptions (I'm not quite sure). Brian 2) Use exceptions instead of stderr instead of stderr and return code. The return code of `test' is in fact its result. Brian 3) Use a more complicated monad It may still be a good idea to take the top 20 unix utils and code them as native haskell functions and see how far that goes. I know there are some existing libraries that deal with basic stuff like mv, etc. Has anyone implemented grep, find, etc? Brian This is also how I would start because it would allow all the Brian control flow/ ease of use issues to be explored just using GHCi Brian / Hugs etc before tackling the problem of how to get binaries Brian to interface with the shell. -- WBR, Max Vasin. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: develop new Haskell shell?
Brian Hulley wrote: Donn Cave wrote: (cd /etc/stuff; cat * result) Well the problem here is that the command leaves you in /etc/stuff so you have to remember this when you subsequently execute another command. No it doesn't. The parentheses around the command sequence cause it to run in a subshell with its own private working directory. Well someone had to define the meaning of basename so if we make the definition of renif similarly built-in the comparison is between ls = mapM_ (renif txt hs) and for a in *.txt; do mv $a $(basename $a .txt); done This comparison is unfair because basename is a much more generic operation than renif. The Haskell code should be something like glob *.txt = mapM_ (\a - mv a (basename a .txt ++ .hs)) So the Haskell command is shorter, easier to read, and more re-usable, because mapM_ (renif txt hs) can be used anywhere that supplies a list of files whereas for a in *.txt doesn't make the source of the list explicit. Do they come from the current directory? What if some other list of files should be used? This makes no sense. Bash has its own set of rules. The for statement iterates over a list, which in this case is generated by a glob. If you want something else, you use the appropriate construct. The body of the for loop is just as reusable as the corresponding Haskell code. My reaction to this thread is the same as Donn Cave's: even after reading through the whole thread, I don't understand what a Haskell shell is supposed to be. It feels like people are more interested in capturing territory for Haskell than in solving any actual problem. For simple commands and pipes, the bash syntax is perfect. For anything nontrivial, I use some other language anyway. I long ago wrote a Perl script to do a far more general form of the renaming example you gave above. As far as I know, the only reason people write nontrivial /bin/sh scripts is that it's the only scripting language that's universally available on Unix systems. Even Perl isn't deployed everywhere. A Haskell shell is never going to be ubiquitous, and Haskell syntax is inferior to bash syntax for 99% of the command lines I type. On the other hand, I'm entirely in favor of extending Haskell with functions like glob :: String - IO [String]. That would be useful. -- Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: develop new Haskell shell?
On Fri, 12 May 2006, Ben Rudiak-Gould wrote: ... For simple commands and pipes, the bash syntax is perfect. For anything nontrivial, I use some other language anyway. I long ago wrote a Perl script to do a far more general form of the renaming example you gave above. As far as I know, the only reason people write nontrivial /bin/sh scripts is that it's the only scripting language that's universally available on Unix systems. I have a blind spot here due to a visceral dislike of Perl, but I do think there's a slim chance that a really well designed language could be useful in that niche - roughly speaking, non-trivial shell scripts. You're right, I wouldn't be able to use it at work, just like rc or, for that matter, Haskell, but still I'd love to see it happen. I just think really well designed is a tall order, and the notion that you can get there by just dropping Haskell into this application domain is an absurdity on the order of Edgar Rice Burroughs' fantasy of Tarzan appearing out of the jungle and being appointed chief of the Waziri. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: develop new Haskell shell?
Ben Rudiak-Gould wrote: My reaction to this thread is the same as Donn Cave's: even after reading through the whole thread, I don't understand what a Haskell shell is supposed to be. I'd like one as a scripting environment, a bit like scsh, just strongly typed and easier on the eyes. Haskell as interactive shell would be a nightmare indeed, having to type 'system foo' instead of simply 'foo' for everyday commands just won't cut it. On the other hand, as soon as a script has at least some programming logic in it, bash (or anything similar) soon becomes a huge PITA. Just think of all the different quotes and how difficult it is to write a script that doesn't go bonkers if it encounters a filename with a space in it (or a parenthesis, a bracket, an asterisk or anything of a myriad special chars I forgot). Haskell shines here; in a combinator library no quoting is necessary and the typechecker will detect most blunders in the equivalent code. Besides, Cabal could benefit from a good file manipulation library, as could a lot of other programs. I long ago wrote a Perl script to do a far more general form of the renaming example you gave above. So did I, but I don't want to experience that ever again. Anyway, for complex renaming, there's always mmv. On the other hand, I'm entirely in favor of extending Haskell with functions like glob :: String - IO [String]. That would be useful. Yes, of course. More specific types would be a good thing, though. Representing both file names and globs by strings will soon reproduce the mess of quote chars that makes sh such a bad programming language. Udo. -- It is explained that all relationships require a little give and take. This is untrue. Any partnership demands that we give and give and give and at the last, as we flop into our graves exhausted, we are told that we didn't give enough. -- Quentin Crisp, How to Become a Virgin signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: develop new Haskell shell?
Ben Rudiak-Gould wrote: Brian Hulley wrote: Well someone had to define the meaning of basename so if we make the definition of renif similarly built-in the comparison is between ls = mapM_ (renif txt hs) and for a in *.txt; do mv $a $(basename $a .txt); done This comparison is unfair because basename is a much more generic operation than renif. The Haskell code should be something like glob *.txt = mapM_ (\a - mv a (basename a .txt ++ .hs)) [rearranged] On the other hand, I'm entirely in favor of extending Haskell with functions like glob :: String - IO [String]. That would be useful. Why assume all filenames are strings? Is it not better to make a distinction between a file and a directory? Why fix everything down to the IO monad? In any case, the Haskell above is still just as short as the UNIX command. So the Haskell command is shorter, easier to read, and more re-usable, because mapM_ (renif txt hs) can be used anywhere that supplies a list of files whereas for a in *.txt doesn't make the source of the list explicit. Do they come from the current directory? What if some other list of files should be used? This makes no sense. Bash has its own set of rules. But who wants to waste their life learning them? :-) The for statement iterates over a list, which in this case is generated by a glob. If you want something else, you use the appropriate construct. The body of the for loop is just as reusable as the corresponding Haskell code. Ok perhaps I was being a little bit unfair. ;-) My reaction to this thread is the same as Donn Cave's: even after reading through the whole thread, I don't understand what a Haskell shell is supposed to be. It feels like people are more interested in capturing territory for Haskell than in solving any actual problem. For simple commands and pipes, the bash syntax is perfect. But it's surely just an accident of historical development. Now that we've got Haskell, why bother with old crusty stuff that's awkward and idiosyncratic? For anything nontrivial, I use some other language anyway. Why not always just use Haskell? A Haskell shell is never going to be ubiquitous At this rate it's never even going to get a chance... , and Haskell syntax is inferior to bash syntax for 99% of the command lines I type. Well perhaps this is just a matter of personal preference. Certainly it's good that everyone can use whatever they prefer. I personally disagree that Haskell syntax is inferior, except perhaps for the need to use quotes but that is imho a very minor distraction. Much more important is that by using the same language for shell + program development, whatever that language is, people could concentrate on solving problems instead of having to continually adapt themselves to the different mindsets of the different communities which develop various modes of interaction with a computer. Regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: develop new Haskell shell?
Udo Stenzel wrote: I'd like one as a scripting environment, a bit like scsh, just strongly typed and easier on the eyes. Haskell as interactive shell would be a nightmare indeed, having to type 'system foo' instead of simply 'foo' for everyday commands just won't cut it. This seems to be your only objection. It might be solvable by making some rule that an identifier that's used in a value position would be automatically bound to a function/value found by instantiating to a binary in the file system if it's not already bound, and there would need to be some rules about how binaries would work to cooperate with the Haskell type system. Another approach, to allow GHCi to be used as a shell immediately (given the right module with useful commands like ls, cat etc which could be written right now) would be to just have a shorter name for system eg what about: % #foo Just think: three extra characters but an infinity of new possibilities. :-) Regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: develop new Haskell shell?
On Fri, 12 May 2006, Brian Hulley wrote: Udo Stenzel wrote: I'd like one as a scripting environment, a bit like scsh, just strongly typed and easier on the eyes. Haskell as interactive shell would be a nightmare indeed, having to type 'system foo' instead of simply 'foo' for everyday commands just won't cut it. This seems to be your only objection. It might be solvable by making some rule that an identifier that's used in a value position would be automatically bound to a function/value found by instantiating to a binary in the file system if it's not already bound, and there would need to be some rules about how binaries would work to cooperate with the Haskell type system. What about the parameters - certainly there's little point in relieving me of the bother of quoting a command name, if I have to quote each parameter? Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: develop new Haskell shell?
Donn Cave wrote:
On Fri, 12 May 2006, Brian Hulley wrote:
Udo Stenzel wrote:
I'd like one as a scripting environment, a bit like scsh, just
strongly typed and easier on the eyes. Haskell as interactive
shell would be a nightmare indeed, having to type 'system foo'
instead of simply 'foo' for everyday commands just won't cut it.
This seems to be your only objection. It might be solvable by making
some rule that an identifier that's used in a value position would be
automatically bound to a function/value found by instantiating to a
binary in the file system if it's not already bound, and there would
need to be some rules about how binaries would work to cooperate
with the Haskell type system.
What about the parameters - certainly there's little point in
relieving me of the bother of quoting a command name, if I have to
quote each parameter?
My idea of a Haskell shell would be that everything in the computer would be
visible as a strongly typed monadic value, so for example, instead of typing
$ ghc -c -O1 Main.hs
ghc would appear in the shell as if it was a normal Haskell function with
this type:
ghc :: GHCOptions - [FileName] - Shell ()
where GHCOptions would be a record. For each binary, there would be default
options, so from Haskell you could type:
Shell ghc ghcDefaultOptions{link=False, opt=1} [Main.hs]
It might even be possible to make a syntactic extension to Haskell that any
function whose first argument is a record could be called with the record
brackets immediately after the function name, (ie with an implicit default
record based on the name of the function before the opening brace) so the
above could be written as:
Shell ghc{link=False, opt=1} [Main.hs]
There would have to be some specification somewhere to tell the binder what
the type of the binary (and its options) was etc.
Regards, Brian.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] develop new Haskell shell?
I have only been skimming this thread so sorry if this was already posted: http://www.webcom.com/~haahr/es/es-usenix-winter93.html es is a shell roughly based on rc but with higher order functions and a functional nature in general. It is quite interesting and could serve as inspiration. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: develop new Haskell shell?
Brian Hulley [EMAIL PROTECTED] writes: Donn Cave wrote: On Fri, 12 May 2006, Brian Hulley wrote: Udo Stenzel wrote: I'd like one as a scripting environment, a bit like scsh, just strongly typed and easier on the eyes. Haskell as interactive shell would be a nightmare indeed, having to type 'system foo' instead of simply 'foo' for everyday commands just won't cut it. This seems to be your only objection. It might be solvable by making some rule that an identifier that's used in a value position would be automatically bound to a function/value found by instantiating to a binary in the file system if it's not already bound, and there would need to be some rules about how binaries would work to cooperate with the Haskell type system. What about the parameters - certainly there's little point in relieving me of the bother of quoting a command name, if I have to quote each parameter? My idea of a Haskell shell would be that everything in the computer would be visible as a strongly typed monadic value, so for example, instead of typing $ ghc -c -O1 Main.hs ghc would appear in the shell as if it was a normal Haskell function with this type: ghc :: GHCOptions - [FileName] - Shell () I and a fellow student have implemented something along those lines. We walk through the $PATH and write a small stub definition for each program. This is then compiled and loaded using hs-plugins. The result is that you can access for example ghc from the command line. The type of the automatically generated functions are e.g.: cat :: Program String String which is the best type you can give without a lot of manual labour (it really ought to be [Word8]). You can then combine programs (and standard haskell functions) like so: cat | map toUpper where (|) :: (Cmd c1, Cmd c2, Marshal t, Marshal i, Marshal o) = c1 i t - c2 t o - Command i o and instance Cmd Program ... instance Cmd (-) .. So the interface is not monadic but more similar to arrow composition. This is probably a bad idea since you need to use something like xargs to run a command on each item in the input. As others (Donn) have pointed out, having to write (in our syntax) e.g. ssh -.l #jansborg #remote.mdstud.chalmers.se gets old really quickly for interactive use, so I don't think a haskell shell is really useful other than for scripting. Basic job control and tab completion for programs and files (but not normal haskell bindings) is implemented. The code is available here: http://www.mdstud.chalmers.se/~jansborg/haskal.tar.gz but please note that it is not at all finished, likely quite buggy, completely undocumented and not really well thought through. /Mats ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] develop new Haskell shell?
On Wed, 10 May 2006, Donald Bruce Stewart wrote: Funny this should come up. We've just had several submissions to work on a functional shell for the google summer of code. Here's a bit of a summary of what's been done in Haskell I prepared a while back. http://www.cse.unsw.edu.au/~pls/thesis-topics/functionalshell.html My background is more shells than FP, so I'm not sure what to make of this - if we're talking about doing things for educational purposes, or serious attempts to make a viable alternative to ... something. At any rate, for anyone thinking about writing a UNIX shell, here are two items that might be worth reading: http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/ A rant about the failings of csh. Particularly note the first topic about file descriptors - if you think the UNIX file descriptor system (the numbers, dup2(), etc.) is quaint but not worth taking very seriously, then you have a lot in common with other people interested in higher level languages (Bill Joy wrote csh) but probably should not be writing a UNIX shell. Tom C. has been doing this rant longer than he has been doing Perl. http://cm.bell-labs.com/sys/doc/rc.pdf The Plan 9 shell. Plan 9 comes from the inventors of UNIX, and its shell is one of the few really good ones. There's a UNIX implementation, whose author also collaborated on es, which another pretty interesting shell, I see it's mentioned on the UNSW web page. Plus a bonus one for the functional connection - I can't find any detailed information about it, but several years ago the next generation Amiga was going to have an FP shell. Here's an article, not in English, sorry, but isn't Italian a beautiful language! http://www.quantum-leap.it/default_frame.asp?id=30 Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] develop new Haskell shell?
Brian Hulley wrote: rename extFrom extTo files = do let candidates = filter (\(_,ext) - ext==extFrom) (map split files) mapM_ (\f@(n,_) - rename (unsplit f) (unsplit (n, extTo))) candidates % ls = rename txt hs I see I've used the same name twice...;-) It should be: ren extFrom extTo files = do let candidates = filter (\(_,ext) - ext==extFrom) (map split files) mapM_ (\f@(n,_) - rename (unsplit f) (unsplit (n, extTo))) candidates % ls = ren txt hs Of course a better choice of primitive commands would give a more powerful shell interface eg using: renif extFrom extTo fileName = case split fileName of (n, ext) | ext == extFrom - rename fileName (unsplit (n, extTo)) _ - return () %ls = mapM_ (renif txt hs) Regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] develop new Haskell shell?
At Thu, 11 May 2006 23:05:14 +0100, Brian Hulley wrote: Of course the above could no doubt be improved but surely it is already far easier to understand and much more powerful than the idiosyncratic text based approach used in UNIX shells (including rc). The idea of representing unix pipes as monads has been around for a while -- but what most people fail to account for is that many (most?) real-world shell scripts also need to deal with return values and stderr. Even standard unix shells are pretty terrible in this regard -- so if we could do it *better* than standard shells -- that could be pretty compelling. Here are some simple examples of things to handle, starting with failures in a pipeline: $ aoeu | cat -n ; echo $? bash: aoeu: command not found 0 $ Sweet! A successful return code even though there is clearly a failure. Bash 3.x *finally* added, set -o pipefail -- which would cause the above to return an error. Unfortunately, there is no way to tell which part of the pipeline failed, or any way to attempt recovery of the part that failed. Often times, a program is run for its return code, not its output: if /usr/bin/test -f /etc/motd ; then echo you have an /etc/motd ; fi And, there are also times when you want to do something with output, and something else with the return code. if cat -n /etc/motd /tmp/numbered ; then echo you have an /etc/motd ; fi This is tricky because many programs will not terminate until you have consumed all the output. Because of haskell's laziness, it is very easy to deadlock. Shell is also pretty weak in this regard, you can either get the return code or the output of a command, but you have to go through gyrations to get both. For example, $ echo `cat aoeu` ; echo $? cat: aoeu: No such file or directory 0 $ How do I check that `cat aoeu` has returned successfully? I think you have to use an intermediate file: if cat aoeu /tmp/tmpfile ; then echo An error occurred reading aoeu fi do something with output saved in /tmp/tmpfile rm /tmp/tmpfile The above code is actually a really bad idea because /tmp/tmpfile may already exist -- so it needs to be modified to use mktemp -- which further complicates the code. It is also, unfortunately, pretty difficult to create useful type signatures for unix commands. For most, the best you can do is: app :: [Flag] - String - IO String Consider `cat', It may appear at first that it has the type: cat :: [Flag] - a - a but then you realize that many of the flags affect the output in interesting ways. For example, '-n' numbers all the lines. If you did: cat [Flag -n] someXmlFile you surely will not get out valid xml data. So, I think that, in general, calling external programs from haskell is an inherently ugly and messy thing. It seems like you either end up with something that is *clean* but less powerful than shell in many respects, or something powerful, but ugly. Hopefully I am wrong, but that has been my experience. Some Ideas -- IMO, the real problem is, grep, find, etc, should have all been libraries with optional command-line interfaces. Then we could just have FFI bindings and write normal looking haskell code. It may still be a good idea to take the top 20 unix utils and code them as native haskell functions and see how far that goes. I know there are some existing libraries that deal with basic stuff like mv, etc. Has anyone implemented grep, find, etc? I think that the problem calling programs and trying to check there return code and use there output is that you are trying to wire up two different things: (1) the connecting of inputs and outputs (2) the flow control that results for the return values This problem looks a bit like the GUI problem where you have to describe the layout of the widgets on the screen and describe the flow of events from one widget to another. So there may be some ideas from GUI research that can be applied to the scripting stuff. It would also be wise to look at occam and erlang and see if they have any useful ideas. And, of course, Windows PowerShell. j. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] develop new Haskell shell?
On Thu, 11 May 2006, Brian Hulley wrote: ... -- catenate all files in a specified directory catenate outputFile dir = withDir dir $ ls = cat outputFile So, you would apply this like catenate result /etc/stuff ? String literals need quotes? Of course the above could no doubt be improved but surely it is already far easier to understand and much more powerful than the idiosyncratic text based approach used in UNIX shells (including rc). (cd /etc/stuff; cat * result) ? renif extFrom extTo fileName = case split fileName of (n, ext) | ext == extFrom - rename fileName (unsplit (n, extTo)) _ - return () %ls = mapM_ (renif txt hs) $ for a in *.txt; do mv $a $(basename $a .txt); done ? Not saying the UNIX shell is a rich and well structured programming environment, and maybe FP is a good direction for that problem. But don't underestimate it, the principles behind it are sharp, and while I think you could expect to win on complex data structures, you can't afford to lose on simple commands, because that's where most of the action is. Hm. Not to pick at the details too much, but you know cat is actually a standard UNIX command, that writes to standard output and has no output file parameter? What's up with the new parameter in your version - was it not going to be workable the way it was? Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] develop new Haskell shell?
It would also be wise to look at occam and erlang and see if they have any useful ideas. And, of course, Windows PowerShell. And scsh (Scheme shell, pretty full featured these days): http://www.scsh.net/ Jared. j. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- http://www.updike.org/~jared/ reverse )-: ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] develop new Haskell shell?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Klyne Did you see [http://nellardo.com/lang/haskell/hash/] ? Google also finds some links to code. #g -- Marc Weber wrote: Hi. Who wants to try devloping a new shell with me? Also: http://www.cse.unsw.edu.au/~dons/h4sh.html * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] develop new Haskell shell?
Who wants to try devloping a new shell with me? Also: http://www.cse.unsw.edu.au/~dons/h4sh.html And (in Clean): Rinus Plasmeijer and Arjen van Weelden. A functional shell that operates on typed and compiled applications. In Varmo Vene and Tarmo Uustalu, editors, Advanced Functional Programming, 5th International Summer School, AFP 2004, University of Tartu, Revised Lectures, volume 3622 of Lecture Notes in Computer Science, pages 245-272, Tartu, Estonia, August 2004. Springer http://www.cs.ru.nl/A.vanWeelden/index.php?p=publications -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] develop new Haskell shell?
johanj: Who wants to try devloping a new shell with me? Also: http://www.cse.unsw.edu.au/~dons/h4sh.html And (in Clean): Rinus Plasmeijer and Arjen van Weelden. A functional shell that operates on typed and compiled applications. In Varmo Vene and Tarmo Uustalu, editors, Advanced Functional Programming, 5th International Summer School, AFP 2004, University of Tartu, Revised Lectures, volume 3622 of Lecture Notes in Computer Science, pages 245-272, Tartu, Estonia, August 2004. Springer http://www.cs.ru.nl/A.vanWeelden/index.php?p=publications Funny this should come up. We've just had several submissions to work on a functional shell for the google summer of code. Here's a bit of a summary of what's been done in Haskell I prepared a while back. http://www.cse.unsw.edu.au/~pls/thesis-topics/functionalshell.html -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] develop new Haskell shell?
Donald Bruce Stewart wrote: Funny this should come up. We've just had several submissions to work on a functional shell for the google summer of code. Here's a bit of a summary of what's been done in Haskell I prepared a while back. http://www.cse.unsw.edu.au/~pls/thesis-topics/functionalshell.html Looking at the brief description of the Esther shell, I was struck by the question - why not just use Haskell directly ie by extending something like GHCi to allow interactive definition of functions/values and an operator to map filenames to functions. I was reminded of http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html and in particular the following principle: Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one. Regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] develop new Haskell shell?
Hi. Who wants to try devloping a new shell with me? The main goals: try adding some haskell scriting instead of bash/zsh, history dependend on a) executing program b) current dir c) last commands d) workspaces which should mean that the shell should save at least the last 10 commands of a,b,c,d. So you can do emerge (lookup parameters in history) even if you haven't used emerge for ages.. :) Nice, isn't it? d) Workspaces should mean: You can define some kind of workspace like workspace=haskellproject, wash, apache to add these tags together with the commands to the history.. So when working only in the wash workspace you can easily find those commands.. Perhpas it's even useful to attach commands or even scripts to those workspaces? eg the startApache script may be attached to admin, apache, ..., the cd /etc/init.d command only to admin.. I also would like to have some advanced kind of directory matching, defining aliases for directories. eg just type cd /usl to get a list of diretories looking like this: /UserShupportLocales /usr/src/linux /usl ? Using tab and bash is nice but it might be done better? Any suggestions? One would have to think about how to run processes in background and so on ... adding files as parameters the way it's possible in mc ( select them and add them to the command line ) perhaps even implement cp/mv/ ... for virtual file systems like zip files/ ftp/ ... ? and last but not least: on windows add all Programs beeing found in Start- Programs to the path list... I wish I could just do word/ Enterprise Manager at a shell and not searching for the menu entries over and over again.. ;) I know I can add them the to the path.. but that would be some work, too.. and not desirable in any case. I could imagine adding a small prefix to each cmd eg. eb (execute bash cmd) ez (execute zsh cmd) r (remove file list) efs (execute from windows start menu) bg cmd run in background like bashs feature. Perhaps even introduce some new syntax ? or use ghci or hugs with a preprocessor to translate these commands to haskell commands? What do you think? Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] develop new Haskell shell?
Did you see [http://nellardo.com/lang/haskell/hash/] ? Google also finds some links to code. #g -- Marc Weber wrote: Hi. Who wants to try devloping a new shell with me? The main goals: try adding some haskell scriting instead of bash/zsh, history dependend on a) executing program b) current dir c) last commands d) workspaces which should mean that the shell should save at least the last 10 commands of a,b,c,d. So you can do emerge (lookup parameters in history) even if you haven't used emerge for ages.. :) Nice, isn't it? d) Workspaces should mean: You can define some kind of workspace like workspace=haskellproject, wash, apache to add these tags together with the commands to the history.. So when working only in the wash workspace you can easily find those commands.. Perhpas it's even useful to attach commands or even scripts to those workspaces? eg the startApache script may be attached to admin, apache, ..., the cd /etc/init.d command only to admin.. I also would like to have some advanced kind of directory matching, defining aliases for directories. eg just type cd /usl to get a list of diretories looking like this: /UserShupportLocales /usr/src/linux /usl ? Using tab and bash is nice but it might be done better? Any suggestions? One would have to think about how to run processes in background and so on ... adding files as parameters the way it's possible in mc ( select them and add them to the command line ) perhaps even implement cp/mv/ ... for virtual file systems like zip files/ ftp/ ... ? and last but not least: on windows add all Programs beeing found in Start- Programs to the path list... I wish I could just do word/ Enterprise Manager at a shell and not searching for the menu entries over and over again.. ;) I know I can add them the to the path.. but that would be some work, too.. and not desirable in any case. I could imagine adding a small prefix to each cmd eg. eb (execute bash cmd) ez (execute zsh cmd) r (remove file list) efs (execute from windows start menu) bg cmd run in background like bashs feature. Perhaps even introduce some new syntax ? or use ghci or hugs with a preprocessor to translate these commands to haskell commands? What do you think? Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: A Haskell-Shell
On 21-Aug-1999, Heribert Schuetz [EMAIL PROTECTED] wrote: The appended patch to Hugs98 (to be applied in the src subdirectory) might be of some help for those who want to do shell scripting in Haskell. It modifies IO.openFile as follows: - If the name of a file opened in ReadMode ends in "|", then the part before the "|" is considered a program and its standard output is read. - If the name of a file opened in WriteMode begins with "|", then the part after the "|" is considered a program and it is written to its standard input. Several Unix programs have such a behaviour. With the patch applied, you can do things like this: do h - openFile "cat /etc/group|" ReadMode h' - openFile "|tr aeiou '*'" WriteMode hGetContents h = hPutStr h' hClose h hClose h' This is a convenient hack, but IMHO it is not suitable for inclusion in the Haskell standard library, because it increases the risk of security holes in Haskell applications. A better alternative would be to provide a new function named "openFileOrPipe" with this augmented functionality. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
Re: A Haskell-Shell
Hello! On Tue, Aug 24, 1999 at 03:41:18AM +1000, Fergus Henderson wrote: [...] This is a convenient hack, but IMHO it is not suitable for inclusion in the Haskell standard library, because it increases the risk of security holes in Haskell applications. I agree. I don't like that similar hack in Perl either. A better alternative would be to provide a new function named "openFileOrPipe" with this augmented functionality. Even better something akin to C's popen(3), where the mode (do you send data from or to the external program) is specified by a second parameter instead of implicitly by | symbols somewhere in the first parameter. Perhaps we could do some popen2 in the same run: popen2 :: String - IO (Handle, Handle), yielding two pipes (stdin and stdout). Or more low level, pass the command in a form ready for execve(), i.e. full path to the program (perhaps a ...p variant which still searches the PATH), argument vector, environment vector. That's more secure than having *only* a variant which uses sh -c. Regards, Hannah.
Re: A Haskell-Shell
Hi, my patch for the use of `popen' is just an ad-hoc solution (aka hack) that might be useful for people trying to do some shell-scripting in hugs, before anything more fundamental becomes available. The security problem (thanks to Fergus Henderson and Carl Witty for pointing it out) must be dealt with within Haskell. This should also be possible for dedicated shell-like programs, but of course we cannot expect *every* user of hugs to take care of it. BTW, besides the security problem there is of course also a semantic hole: What if I really want to read a file whose name ends in "|"? Although I did not make that clear explicitly, the patch was actually not meant to be included into an official hugs release (although I admittedly found it flattering when I got mail suggesting that), at least not as-is. There should at least be an option for explicitly enabling it. But of course I would prefer a function `popen' on the Haskell level (which would also make a primitive `openFileOrPipe' unnecessary), or even more, as I wrote in my previous mail, access to the "real thing": the system calls like `fork', `execve', etc. Heribert.
Re: A Haskell-Shell
And there is _no_ handle to the output of the command! An obvious hack is
to use redirecting; here is how you implement a simple date function in
Haskell:
date :: IO String
date =
do system "date /tmp/answer"
readFile "/tmp/answer"
[..]
I implemented these functions and a couple more (dealing with lazily
generating output) in Hugs, using dynamic named pipe generation and
redirecting. This is a hack; it would be much nicer to have a function
like "sysInOut" builtin in Hugs (Haskell98).
There is no need (that I can see) to use named pipes... here is some
code I used (in GHC; haven't tried it in Hugs). Disclaimer: it's
*not* production code, and is ugly [I suspect it doesn't really need
two forks], but works for me. It actually does a few other things as
well, but you should be able to pick out what you need.
import IO
import Posix
import System
-- and maybe a few other things too
teeProcess :: (String - String)
- FilePath - Bool - [String] - Maybe [(String,String)] - IO
(ExitCode,String)
-- as executeFile, but merges stdout and stderr, outputting them together on stdout
-- (via a filter function) and also returning them as a string.
teeProcess f prog pathp args menv
= do { (pin,pout) - createPipe
; mpid - forkProcess
; pid - case mpid of
Nothing - do { mprocPid - forkProcess
; procPid - case mprocPid of
Nothing - do { dupTo pout (intToFd 1)
; dupTo pout (intToFd 2)
; executeFile prog
pathp args menv
; error "teeProcess:1"
}
Just pid - return pid
; status - getProcessStatus True False procPid
; ec - case status of
Just (Exited ec) - do { fdClose pout
; return ec
}
Just (Terminated sig) - do { raiseSignal
sig
; error
"teeProcess:2"
}
Just (Stopped sig)- error "teeProcess:
process stopped"
Nothing - error "teeProcess:
no info"
; exitWith ec
; error "teeProcess:3"
}
Just pid - return pid
; fdClose pout
; hpin - fdToHandle pin
; hSetBuffering hpin LineBuffering
; str - hGetContents hpin -- lazily
; putStr (f str)
; status - getProcessStatus True False pid
; ec - case status of
Just (Exited ec) - return ec
Just (Terminated sig) - do { raiseSignal sig ; error "teeProcess:4" }
; return (ec,str)
}
Hope this is of use.
--KW 8-)
Re: A Haskell-Shell
Heribert Schuetz [EMAIL PROTECTED] writes: Hi, The appended patch to Hugs98 (to be applied in the src subdirectory) might be of some help for those who want to do shell scripting in Haskell. It modifies IO.openFile as follows: - If the name of a file opened in ReadMode ends in "|", then the part before the "|" is considered a program and its standard output is read. - If the name of a file opened in WriteMode begins with "|", then the part after the "|" is considered a program and it is written to its standard input. Several Unix programs have such a behaviour. I'd recommend against this; it's a potential source of nasty security holes. (Suppose somebody uses this version of Hugs to write a system utility...something like "grep", say. And then does "cd /tmp; mygrep whatever *". And suppose somebody else has created a file named "/tmp/rm -rf ..|".) A new function, openFilePipe say, with security warnings in the documentation, would be better. Carl Witty
Re: A Haskell-Shell
Koen Claessen wrote: Hello, | Just wondering if someone uses Hugs for writing Unix-Shell Scripts. Or | what would you think about a Haskell-Shell. These are two quite separate issues of course. I can comment on the first one. Of course you're rigth, and I better had just asked if someone like to have a Haskell Shell. I just thought that this would be a nice application. Regards Friedrich
Re: A Haskell-Shell
Hi,
The appended patch to Hugs98 (to be applied in the src subdirectory)
might be of some help for those who want to do shell scripting in
Haskell. It modifies IO.openFile as follows:
- If the name of a file opened in ReadMode ends in "|", then the part
before the "|" is considered a program and its standard output is
read.
- If the name of a file opened in WriteMode begins with "|", then the
part after the "|" is considered a program and it is written to its
standard input.
Several Unix programs have such a behaviour.
With the patch applied, you can do things like this:
do h - openFile "cat /etc/group|" ReadMode
h' - openFile "|tr aeiou '*'" WriteMode
hGetContents h = hPutStr h'
hClose h
hClose h'
Now for the disclaimers.
The patched program is in no way meant to be elegant. I rather tried to
keep the patch itself as small as possible. I also have not tested it on
any environment other than my Linux machine. And to be honest, I didn't
completely understand what I was doing. (What are, e.g., `ap' and
`HANDCELL'?)
The patch is also not a complete solution to the needs of script
programmers because you can only access the standard input *or* the
standard output of a program. A cleaner solution would be based on the
`pipe', `fork' and `execve' system calls made available as Haskell
primitives. But I don't understand enough of the hugs internals to
implement that.
Heribert.
--
*** storage.c.orig Fri Aug 20 18:34:05 1999
--- storage.c Sat Aug 21 09:33:34 1999
***
*** 2441,2446
--- 2441,2460
ERRMSG(0) "Too many handles open; cannot open \"%s\"", s
EEND;
}
+ else if (hmodeHREAD s[strlen(s)-1]=='|') {
+ s[strlen(s)-1] = (char) 0;
+ /* Is this side effect harmless? */
+ if (handles[i].hfp=popen(s,"r")) {
+ handles[i].hmode = hmode;
+ return (handles[i].hcell = ap(HANDCELL,i));
+ }
+ }
+ else if (hmodeHWRITE s[0]=='|') {
+ if (handles[i].hfp=popen(s+1,"w")) {
+ handles[i].hmode = hmode;
+ return (handles[i].hcell = ap(HANDCELL,i));
+ }
+ }
else { /* prepare to open file*/
String stmode;
if (binary) {
***
*** 2464,2470
Int n; {/* heap references to it remain*/
if (0=n nNUM_HANDLES nonNull(handles[n].hcell)) {
if (nHSTDERR handles[n].hmode!=HCLOSED handles[n].hfp) {
! fclose(handles[n].hfp);
handles[n].hfp = 0;
}
fst(handles[n].hcell) = snd(handles[n].hcell) = NIL;
--- 2478,2488
Int n; {/* heap references to it remain*/
if (0=n nNUM_HANDLES nonNull(handles[n].hcell)) {
if (nHSTDERR handles[n].hmode!=HCLOSED handles[n].hfp) {
! if (pclose(handles[n].hfp) == -1) {
! /* Is there a more elegant way to find out whether a
!FILE is actually a pipe? */
! fclose(handles[n].hfp);
! }
handles[n].hfp = 0;
}
fst(handles[n].hcell) = snd(handles[n].hcell) = NIL;
Re: A Haskell-Shell
Just wondering if someone uses Hugs for writing Unix-Shell Scripts. Or what would you think about a Haskell-Shell. SCSH (a Scheme-Shell) brought me on that idea. Don't you think that would be a nice thing? Yes, it would be a wonderful idea.. but Hugs would need to be madified since a) it has no history, tab compleation, or other nifty interactive features, b) you can not define functions interactivly in Hugs, and c) someone needs to come up with a good set of shellish libraries and whatnot --- this last part is the interesting part from a language point of view. I suppose if someone fixed (a) and (b) (if only to improve the usability of Hugs in general) then (c) could be an evolutionary process. Jeff
A Haskell-Shell
Just wondering if someone uses Hugs for writing Unix-Shell Scripts. Or what would you think about a Haskell-Shell. SCSH (a Scheme-Shell) brought me on that idea. Don't you think that would be a nice thing? Regards Friedrich
Re: A Haskell-Shell
Hello, | Just wondering if someone uses Hugs for writing Unix-Shell Scripts. Or | what would you think about a Haskell-Shell. These are two quite separate issues of course. I can comment on the first one. A while ago, we had a discussion among some Haskell hackers here at Chalmers how we could make the writing of shell scripts in Haskell easier. Some of us had been bitten by the fact that, in Haskell, you _can_ call shell commands like "rm" and "cp", but it is not easy to use shell commands like "date", "grep", "lynx" or "metamail". This is because the only official way to call a shell command in Haskell is: system :: String - IO ExitCode And there is _no_ handle to the output of the command! An obvious hack is to use redirecting; here is how you implement a simple date function in Haskell: date :: IO String date = do system "date /tmp/answer" readFile "/tmp/answer" But this gets hairy after a while. We came to the conclusion that it would be extremely handy to have some kind of library supporting the following functions: module Unix where ( Command --:: String , sys --:: Command - IO () -- using stdin and stdout , sysIn--:: Command - String - IO () , sysOut --:: Command - IO String , sysInOut --:: Command - String - IO String -- ... ) Now we can define nice combinators (monadic composition, etc.) to pipe commands, etc. I implemented these functions and a couple more (dealing with lazily generating output) in Hugs, using dynamic named pipe generation and redirecting. This is a hack; it would be much nicer to have a function like "sysInOut" builtin in Hugs (Haskell98). I have used the module to implement a great number of Haskell shell scripts, including the following: - a mail-filter, redirecting a summary of my e-mail to my mobile phone, and redirecting messages from my mobile phone to e-mail. - a script connecting several theorem provers together, gathering, redirecting and interpreting their respective outputs. - a sort of xbiff, displaying the e-mail's sender's names. - a script managing the weekly functional programming meetings at Calmers. - a script that uses several different search engines on the web to search for a keyword, displaying the resulting URLs. - a script that checks every so many hours popular cartoon sites (Dilbert, Calvin and Hobbes) and displays a new episode if there is one. etc. If people are interested, I can post my Unix module on this list. Note that the module itself is a terrible hack! I would really like it to be possible in Hugs to get a handle to the input and output of a system command. Regards, Koen. -- Koen Claessen http://www.cs.chalmers.se/~koen phone:+46-31-772 5424 e-mail:[EMAIL PROTECTED] - Chalmers University of Technology, Gothenburg, Sweden
Re: A Haskell-Shell
I found an old (and stale) URL lia href="http://www.dcs.gla.ac.uk/~mattson/Hsh.html"Unix shell in GHC/a which may be relevant to this thread. As I dimly recall it was a few screenfulls of code, and only a "proof of concept". Perhaps one can find a non-stale link by a web search? -- Peter
Re: A Haskell-Shell
You also need some type of pipe functionality. There is a paper on arrows (by John Hughes?), that seems like it describes a good way to implement pipes in Haskell. -Alex- ___ S. Alexander Jacobson Shop.Com 1-212-697-0184 voiceThe Easiest Way To Shop On 20 Aug 1999, Marko Schuetz wrote: "Jeff" == Jeff Burdges [EMAIL PROTECTED] writes: Just wondering if someone uses Hugs for writing Unix-Shell Scripts. Or what would you think about a Haskell-Shell. SCSH (a Scheme-Shell) brought me on that idea. Don't you think that would be a nice thing? Jeff Yes, it would be a wonderful idea.. but Hugs would need to be Jeff madified since a) it has no history, tab compleation, or other You can make hugs use readline, giving you many of these interactive features, e.g. incremental search backwards through your history etc. Marko -- Marko Schütz[EMAIL PROTECTED] http://www.ki.informatik.uni-frankfurt.de/~marko/
Re: A Haskell-Shell
I am just learning Hugs/Haskell (Thanks for a great book ST!) but already I am using hugs as script writing tool. It occured to me to use it this way when I saw the 'illiterate' program in the hugs manual. By reading in files and using list comprehensions, it seems you express simple file manipulation programs easily. A shell would be awesome! On Fri, 20 Aug 1999, Friedrich Dominicus wrote: Just wondering if someone uses Hugs for writing Unix-Shell Scripts. Or what would you think about a Haskell-Shell. SCSH (a Scheme-Shell) brought me on that idea. Don't you think that would be a nice thing? Regards Friedrich
