Pascal Fleury writes: > I was wondering how it would behave if the string that is put into a > variable contains newlines, backslashes and other things that bash > (and other shells) treats specially.
Exactly like it does with the earlier method, except it doesn't fork and doesn't require certain versions of bash. > The trick with cat and BABEL_TABLE is resistant to this. I don't think so, some older versions of bash had a parsing bug that made it croak on single quotes in here documents. Single quoting the variable content only reuires special handling of single quotes. While that is tedious and error prone to do by hand, we're doing it with elisp anyway so this doesn't pose a problem. Also, it works for just about any shell, not only those that know about $( ) command substitution and implement here documents within the substitution correctly. > As in many cases (when I use it at least) the variable come from other > parts of the org file and are computed through another language > (python in my case) I have such cases that would break. If you have an example, please show it. > Also, I think the test coverage for such things is limited for > ob-shell.el in the org test suite. > We should probably add some test cases for this, and then make sure it > works with your implementation as well. By all means, please add such tests. While you're at it, you might want to double quote the variable expansions, which will show you that the shell is wholly capable of returning a list and even a table to Org, with or without associative arrays. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
