I've seen a number of option parsing libraries out there for ruby, but they all come with weird constraints about them.
'executable' gem claims that all command line binaries must have a syntax "binary
'micro-optparse' can't handle trailing list of filenames and requires you have defaults for all non-boolean commands. Strange.
Some other one I used made it impossible to run a command without arguments.
And so on and so on. And I don't want to parse ARGV myself.
Is there anything close to a specification or standard for command line options and arguments? And then what option parsing library complies to that standard?
Do you know about optparse? It's included in stdlib - as standard as it gets.
But there is no unix standard set in stone as to parsing command-line parameters.
You should define your requirements more clearly and then choose a library that suits them.
There's no standard I have ever heard of, but AFAIR Trollop was started out of the frustration with the other command line parsers.
+1 for Michael Kohl's mention of Trollop. Trollop makes it very easy to write command line options that conform to the gnu style.
I wrote a simple self-contained example in How do I make a Ruby script using Trollop for command line parsing?.
Related
The scala documentation shows that the way to create a scala script is like this:
#!/bin/sh
exec scala "$0" "$#"
!#
/* Script here */
I know that this executes scala with the name of the script file and the arguments passed to it, and that the scala command apparently knows to read a file that starts like this and ignore everything up to the reversed shebang !#
My question is: is there any reason why I should use this (rather verbose) format for a scala script, rather than just:
#!/bin/env scala
/* Script here */
This, as far a I can tell from a quick test, does exactly the same thing, but is less verbose.
How old is the documentation? Usually, this sort of thing (often referred to as 'the exec hack') was recommended before /bin/env was common, and this was the best way to get the functionality. Note that /usr/bin/env is more common than /bin/env, and ought to be used instead.
Note that it's /usr/bin/env, not /bin/env.
There are no benefits to using an intermediate shell instead of /usr/bin/env, except running in some rare antique Unix variants where env isn't in /usr/bin. Well, technically SCO still exists, but does Scala even run there?
However the advantage of the shell variant is that it gives an opportunity to tune what is executed, for example to add elements to PATH or CLASSPATH, or to add options such as -savecompiled to the interpreter (as shown in the manual). This may be why the documentation suggests the shell form.
I am not on the Scala development team and I don't know what the historical motivation for the Scala documentation was.
Scala did not always support /usr/bin/env. No particular reason for it, just, I imagine, the person who wrote the shell scripting support was not familiar with that syntax, back in the mid 00's. The documentation followed what was supported, and I added /usr/bin/env support at some point (iirc), but never bothered changing the documentation, it would seem.
Does anybody know of a Haskell library which can parse arbitrary Bash scripts?
A cursory search of Hackage indicates that there's a package called bash for writing scripts, but I don't see anything for parsing them.
Basically I've just had a large collection of Bash scripts dumped on me, and I'd like to do some code analysis on it. But the first stage is obviously to be able to parse this stuff.
I don't know Bash very well personally. I suppose I could sit down and wage through the volumous man-page to get the complete BNF grammar for it. (I imagine it's very complex, given the shell's long and backwards-compatible history.) I was just wondering whether somebody else has already done this work for me...
Perhaps extend language-sh.
Language.Sh is a collection of modules for parsing and manipulating
expressions in shell grammar. This is part of a larger project, shsh.
Please note that the API is somewhat unstable until we reach version
1.0.
Looking for a command line code formatter that can be used for bash code. It must be configurable and preferably usable from command line.
I have a big project in bash, which I need to use Q in mind for. So far I am happy with a program written in python by Paul Lutus (a remake of his previous version in Ruby).
See http://arachnoid.com/python/beautify_bash_program.html (also cloned here https://github.com/ewiger/beautify_bash).
but I would like to learn any serious alternative to this tool if it exists. Requirements: it should provide robust enough performance and behavior of treating/parsing rather complicated code.
PS I believe full parsing of bash code is generally complicated because there exists no official language grammar (but please correct me if I am wrong about it).
You could give shfmt a try. It implements its own shell parser including Bash support, so it's more robust than plaintext-based tools.
And both the parser and printer are available as Go packages, so it should be easy to write a 20-line Go program to manipulate or play with shell code.
Please note that I'm the author, so the advice may be a bit biased :)
you can script vim to do: "gg=G" that means "indent all the file"
I discovered that the type builtin will print functions in a formatted manner.
#/usr/bin/env bash
source <(cat <(echo 'wrapper() {') - <(echo '}'));
type wrapper | tail -n +4 | head -n -1 | sed 's/^ //g'
https://github.com/bas080/flush
On the contrary the shell does have a rigorous grammar.
It is described both in English in the ISO standard and documentation for Bash and other shells, and in formal terms in the shell.y file in the Bash source tree.
What makes it "hard" is that where one normally thinks of, say, a quoted string as single lexical token, In the shell every meta character is a separate lexical token, so the meaning of a character can change depending on its grammatical context.
So the parsing tokens do not align with the "shell words" that a user thinks of, and a simple quoted string is at least 3 tokens.
The implementations typically take some shortcuts involving using multiple lexical analysers chosen by whether the grammar is inside quotes, inside numeric context, or outside both.
I have a sizable vim script (a .vim file, in viml syntax). I'd like to check (but not execute!) the file for simple syntax errors.
How do I accomplish this?
I just want a very rough syntax check. Something along the lines of perl -c or pyflakes.
Here is a syntax checker for VimL.
https://github.com/syngan/vim-vimlint/
I don't think (I'm relatively sure, as much as one can be) one exists. VimL is an internal language of Vim (and only Vim), and there aren't many tools developed for it.
I tried searching on vim.org and several other places, with no luck. Not suprising, because I've never heard of one either.
So you're either stuck with running the script, or switching to an outside language like Python, Perl or Ruby.
https://github.com/osyo-manga/vim-watchdogs
vim-watchdogs, apparently, is a syntax checker for vim, it says that it supports many languages, including vimL
if you use vundle, you can just drop this into your vimrc:
Plugin 'git://github.com/osyo-manga/vim-watchdogs.git'
..and then run:
:PluginInstall
..to set it up (vundle is a very nifty plugin manager) If you have syntastic, you might want to be careful and disable it first, and then see if it is an adequate replacement (since it says it supports all those languages anyway).
It is a safe bet that when you have multiple syntax checkers going, you will need to put your "dogs on a leash", so to speak; by configuring one to check languages that the other one does not, and vice-versa. If you do not, there will be at best collisions, duplications, or misdirections. At worst, you will have all of the above and more.
Make sure that you always backup your ~/.vim directory (or your VIMRUNTIME directory if you install things on a global level), you will be glad you did. Hope that helped you or someone else out, good luck! Sorry you had to wait 7.5 months for a response, heh :)
There's now a second option: vim-lint (as opposed to vimlint)
I'm looking for a gem that allows to compile tex files (TeLaTeX or just LaTeX) into pdf. I don't need any templating or partial rendering, just simple compiler. Is there any bindings for latex2pdf or something.
Are you looking for a TeX-Compiler written in ruby or a ruby script, that calls LaTeX?
If you look for the 2nd one:
http://rubygems.org/gems/rake4latex
Defines a rake-task to generate a pdf, based on tex-sources. It checks, how many TeX-runs are needed, makeindex, bibtex... is done if required.
Supports splitindex, gloss...
Can be used with LaTeX, pdfLaTeX, XeLaTeX...
Can't you just call the command line directly with backtick notation?
`latex2pdf <options>`
It shows that TeX's syntax is so horrible flexible, that you actually will need TeX or any of its variants to interpret TeX files in general.
So actually calling the command line pdflatex or xelatex (or any wrapper around this, like in peakxu's answer) is the best bet here.
I have no idea if someone packaged a TeX distribution (like TeX Live) into a Ruby Gem, I suppose not.