Hi András and Eric, András Major wrote: > >> If we did return the value of shell scripts then ":results value" would >> almost always simply return 0 (or possibly an error message). For this >> reason shell code blocks do not implement value returns, but rather will >> always collect results from STDOUT. > > I think that this unnecessarily throws away potentially useful > functionality. Example: I want to fill a table with data such that the value > of a cell depends on whether a file (whose path is specified by another > cell, for instance) exists or not. This would be most easily done using an > sh block which returns a numeric exit code. I don't see a reason for making > clandestine exceptions to the rules in the manual and strongly suggest that > the output and value options be honoured for every language.
I must admit that I was not aware of this peculiarity for sh blocks. And I guess there must be a reason for not honoring value vs output here. If not, I'd prefer it to exist -- even if Achim showed that both are always possible. > In order not to break existing Org files, I would suggest that the default > choice between value and output (when not explicitly specified) depend on > the language. With this functionality, sh code blocks that don't specify > ":results output" will still work as they did before. That possibility already exist. It can be done like this: #+begin_src emacs-lisp (add-to-list 'org-babel-default-header-args:sh '((:results . "value"))) #+end_src Best regards, Seb -- Sebastien Vauban
