
Many-a-time, have I used higher level languages to generate Bash scripts. Here, for the first time, I have taken the time to write a structured and safe Bash pretty printer, leveraging some work on shell escaping I did some months ago. http://hackage.haskell.org/packages/archive/bash/0.0.0/doc/html/Language-Bas... A wide range of Bash constructs are supported. It's easiest to point out what's not supported at present: . Arithmetic substitutions (those within "$(( ))"). . Bash's test special form (using "[[ ]]"). Ordinary uses of the test command are of course fully supported. . Specialized expression de-referencing forms that allow substitution and substring selection; the only thing supported in this domain is defaulting and length: ${#var} # Length of var in bytes. ${var:-} # If var is not set, yield the empty string. Many other forms that are tedious to get right -- special variable names, array expansions, even eval -- are fully supported. I'll be using this tool to support a config generation system. Another interesting application is generating Bash completion scripts. If you decide to use it and have trouble please let me know; this is the first Language.Something that I have written and it may not present the friendliest interface. Do let me know, also, if the omitted syntactic structures would be helpful to you and I will see what I can do to include them. -- Jason Dusek Linux User #510144 | http://counter.li.org/

On 6 March 2011 14:57, Jason Dusek
Many-a-time, have I used higher level languages to generate Bash scripts. Here, for the first time, I have taken the time to write a structured and safe Bash pretty printer, leveraging some work on shell escaping I did some months ago.
http://hackage.haskell.org/packages/archive/bash/0.0.0/doc/html/Language-Bas...
Maybe this could be integrated with language-sh [1] to get parsing support as well? [1]: http://hackage.haskell.org/package/language-sh -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On Sun, Mar 6, 2011 at 04:27, Ivan Lazar Miljenovic
Maybe this could be integrated with language-sh [1] to get parsing support as well?
It's hard to say without testing it; but anything labeled Sh probably won't parse real Bash very well. Would parsing a subset be enough? There are certain kinds of unescaped variable references that I don't plan to support in the Syntax; so there'd be nothing to parse them in to. Maybe I will have to rethink this part; I considered a Quoted (Expression t) constructor for Expression. A real parser should probably preserve comments, too. It is normal to include parsers in Language.Something modules; in this particular case, I assumed Bash analysis would not be used much. If you are interested in a way to wrap Bash you pull out of a file into a script you construct with the Syntax, you might try the Language.Bash.Annotations.Lines datatype. -- Jason Dusek Linux User #510144 | http://counter.li.org/

* Ivan Lazar Miljenovic
On 6 March 2011 14:57, Jason Dusek
wrote: Many-a-time, have I used higher level languages to generate Bash scripts. Here, for the first time, I have taken the time to write a structured and safe Bash pretty printer, leveraging some work on shell escaping I did some months ago.
http://hackage.haskell.org/packages/archive/bash/0.0.0/doc/html/Language-Bas...
Maybe this could be integrated with language-sh [1] to get parsing support as well?
There's also Loker[2]. (I haven't done a proper hackage release yet.) Unfortunately, I wasn't aware of language-sh effort when I started Loker. [2]: https://github.com/feuerbach/loker -- Roman I. Cheplyaka :: http://ro-che.info/ Don't worry what people think, they don't do it very often.

Version 2.7.0 was uploaded to hackage. From the CHANGELOG: Version 2.7.0 Improvement: change of error correction at end of amb (which deals with ambiguous parsers) combinator; available lookahead is better taken into account Relatively large change: • Change to Data.ListLike inputs, so a general stream input structure is possible; hence we can now parse all instances from Data.ListLike • Simplified and generalised implementation of merging/permuting parsers; any kind of parsers can now be merged/permuted • New class IsParser was introduced which captures the basic properties of our parsers, thus simplifying the types • Inclusion of a module Text.ParserCombinators.UU.Utils containing common Char based parsers • Removal of the class Provides, and replaced by separate pSym, pSatisfy and pRange; this may require some rewriting of existing parsers. Readability is supposed to improve from that. Types become simpler. For an example see the module Text.ParserCombinators.UU.Utils. • Included a Demo directory, with one module for demonstrating normal parsers and one aimed at showing merging parsers • Added the module Text.ParserCombinaors.UU.Idioms, which contains specialised version for the idiomatic notation; it infers the sequental composition operators from the types of the operands; String-s and Char-s are not supposed to contribute to the result (hence <*), function parameters are lifted using `pure`, and normal parsers are composed with `<*>`. • Many other small changes, mostly upwards compatible or invisible (code cleanup) For some examples see: http://hackage.haskell.org/packages/archive/uu-parsinglib/2.7.0/doc/html/Tex... and: http://hackage.haskell.org/packages/archive/uu-parsinglib/2.7.0/doc/html/Tex... and: http://hackage.haskell.org/packages/archive/uu-parsinglib/2.7.0/doc/html/Tex...
participants (4)
-
Ivan Lazar Miljenovic
-
Jason Dusek
-
Roman Cheplyaka
-
S. Doaitse Swierstra