From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Amidon Subject: Problem with bash arrays from list-valued org-babel :var assignments? Date: Thu, 08 Jun 2017 21:56:34 -0700 Message-ID: <1496984194.5909.4.camel@picnicpark.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42785) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dJByp-0003lD-PN for emacs-orgmode@gnu.org; Fri, 09 Jun 2017 00:57:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dJBym-00052b-Mx for emacs-orgmode@gnu.org; Fri, 09 Jun 2017 00:57:03 -0400 Received: from sub5.mail.dreamhost.com ([208.113.200.129]:37127 helo=homiemail-a79.g.dreamhost.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dJBym-00052J-Bw for emacs-orgmode@gnu.org; Fri, 09 Jun 2017 00:57:00 -0400 Received: from homiemail-a79.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a79.g.dreamhost.com (Postfix) with ESMTP id 2AAFB600661F for ; Thu, 8 Jun 2017 21:56:55 -0700 (PDT) Received: from gw.picnicpark.org (108-225-17-54.lightspeed.sntcca.sbcglobal.net [108.225.17.54]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mailer@picnicpark.org) by homiemail-a79.g.dreamhost.com (Postfix) with ESMTPSA id 0DC90600661C for ; Thu, 8 Jun 2017 21:56:55 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org Cc: camalot@picnicpark.org With current org-mode, when I try to execute the following org-babel block: #+begin_src bash :var lst='(1 2 3 4 5 6 7) printf "%s\n" "${lst[*]}" #+end_src I get result and the following error in the minibuffer: Wrong type argument: listp, 1 This, on the other hand works fine: #+begin_src emacs-lisp :var lst='(1 2 3 4 5 6 7) lst #+end_src In investigating this, I looked into the code for how bash variables are set from the org variables and found this code in ob-shell that I don't really understand: (defun org-babel--variable-assignments:bash (varname values &optional sep hline) "Represents the parameters as useful Bash shell variables." (if (listp values) (if (and (listp (car values)) (= 1 (length (car values)))) (org-babel--variable-assignments:bash_array varname values sep hline) (org-babel--variable-assignments:bash_assoc varname values sep hline)) (org-babel--variable-assignments:sh-generic varname values sep hline))) I *think* that the org-babel--variable-assignments:bash_assoc function is supposed to allow initializing bash arrays with arbitrary key/value mappings when each element of the list is itself a list where the first element of the sublist is the key of the mapping and the remaining elements form the value, whereas the org-babel--variable- assignments:bash_array function is supposed to create integer-indexed bash arrays for simple lists. However, if that is the case, the logic for picking between them doesn't work as I would expect, since a simple list like the example at the beginning of this email, '(1 2 3 4 5 6 7), will will fail the test (listp (car values)) and result in the bash_assoc version being called when the list is not of the correct form for that function. The following version of the function that replaces the current test with a simpler one seems to do what I think the expected behavior should be for both types of lists, but it isn't clear to me whether the current code is trying to support some other use cases that I don't understand: (defun org-babel--variable-assignments:bash (varname values &optional sep hline) "Represents the parameters as useful Bash shell variables." (if (listp values) (if (not (listp (car values))) (org-babel--variable-assignments:bash_array varname values sep hline) (org-babel--variable-assignments:bash_assoc varname values sep hline)) (org-babel--variable-assignments:sh-generic varname values sep hline))) In any case, it seems like the simple example at the beginning of this message should work. Is this a bug or am I missing something? Thanks, Keith