5 ms·

On the original post he says switching to a "real" PL is probably "right" but onerous. I won't nitpick on whether or not it's onerous, but maybe it's not as one

On the original post he says switching to a "real" PL is probably "right" but onerous. I won't nitpick on whether or not it's onerous, but maybe it's not as onerous as the author thinks. A few years ago I blogged about generating a Markdown changelog based on PRs http://mattdeboard.net/2014/01/14/automatic-changelog-generation-with-git/ http://mattdeboard.net/2014/01/14/automatic-changelog-genera... Though the output is different (just concerned with merge commits), I reckon you could probably do something similar for HTML with a `git log` command modified from what's in my post. No git API library needed. That said, the author wanted to explore doing this just with shell and deal with the problems and stuff that come up there, so, cool! I'm not passing judgment on that or comparing what I wrote to what he did, just throwing it out there.

chubot 9y ago
(author here) That's a very similar problem, but it looks like it's sloppy about escaping. Correct me if I'm wrong, but you could have a change description that looks like: Fix escaping of \*. And it wouldn't be printed correctly because it conflicts with Markdown's own escaping. $ echo 'Fix escaping of \*' |markdown Fix escaping of * Or: Fix parsing of a[i]() $ echo 'Fix parsing of a[i]()' | markdown Fix parsing of a<a href="">i</a> In other words, you have a "markdown injection attack" (which is probably not very consequential, but it leads to bad output.). The whole point of this exercise is that the escaping is 100% correct.
- mattdeboard 9y ago
 Sure, understood.
__david__ 9y ago
I agree—I love pushing shell to its limits as much as anyone, but I had so many shell scripts that grew and grew till the point I got annoyed and rewrote them in perl/ruby and every time I thought it came out better (shorter, more comprehensible). Finding that point where it's better to be a "real" language is a bit of an art form though. For me it's heuristics like needing arrays or hashes or parsing command line arguments.
- chubot 9y ago
  Yup, that is exactly the point of Oil. In fact I promised I would write an "elevator pitch" but I haven't done that yet [1]. In short: It's the "upgrade path" from bash. That is, the ONLY language you can automatically convert shell to. Rewriting even a 30 line bash script in Perl/Ruby/Python isn't trivial, and of course there are many 1000+ lines bash scripts laying around. People even write new ones today (e.g. for setting up clusters and Linux distros.) I'm current looking at running the 2500 line 'abuild' shell script which builds and deploys Alpine Linux packages [2]. Although many people like to avoid shell, if you use Unix, it's at the foundation of everything you do. The bash clone OSH is actually close to done (although it's slow). But I still have to work on the new Oil language [3] which you can convert shell to. Hopefully that won't take as long as OSH :) [1] http://www.oilshell.org/blog/2017/07/31.html http://www.oilshell.org/blog/2017/07/31.html [2] https://git.alpinelinux.org/cgit/abuild/tree/abuild.in https://git.alpinelinux.org/cgit/abuild/tree/abuild.in [3] http://www.oilshell.org/blog/2017/02/05.html http://www.oilshell.org/blog/2017/02/05.html

chubot 9y ago

(author here) That's a very similar problem, but it looks like it's sloppy about escaping. Correct me if I'm wrong, but you could have a change description that looks like: Fix escaping of \*. And it wouldn't be printed correctly because it conflicts with Markdown's own escaping. $ echo 'Fix escaping of \*' |markdown Fix escaping of * Or: Fix parsing of a[i]() $ echo 'Fix parsing of a[i]()' | markdown Fix parsing of a<a href="">i</a> In other words, you have a "markdown injection attack" (which is probably not very consequential, but it leads to bad output.). The whole point of this exercise is that the escaping is 100% correct.

mattdeboard 9y ago
Sure, understood.

__david__ 9y ago

I agree—I love pushing shell to its limits as much as anyone, but I had so many shell scripts that grew and grew till the point I got annoyed and rewrote them in perl/ruby and every time I thought it came out better (shorter, more comprehensible). Finding that point where it's better to be a "real" language is a bit of an art form though. For me it's heuristics like needing arrays or hashes or parsing command line arguments.

chubot 9y ago
Yup, that is exactly the point of Oil. In fact I promised I would write an "elevator pitch" but I haven't done that yet [1]. In short: It's the "upgrade path" from bash. That is, the ONLY language you can automatically convert shell to. Rewriting even a 30 line bash script in Perl/Ruby/Python isn't trivial, and of course there are many 1000+ lines bash scripts laying around. People even write new ones today (e.g. for setting up clusters and Linux distros.) I'm current looking at running the 2500 line 'abuild' shell script which builds and deploys Alpine Linux packages [2]. Although many people like to avoid shell, if you use Unix, it's at the foundation of everything you do. The bash clone OSH is actually close to done (although it's slow). But I still have to work on the new Oil language [3] which you can convert shell to. Hopefully that won't take as long as OSH :) [1] http://www.oilshell.org/blog/2017/07/31.html http://www.oilshell.org/blog/2017/07/31.html [2] https://git.alpinelinux.org/cgit/abuild/tree/abuild.in https://git.alpinelinux.org/cgit/abuild/tree/abuild.in [3] http://www.oilshell.org/blog/2017/02/05.html http://www.oilshell.org/blog/2017/02/05.html