Max Nikulin writes:
> On 22/08/2023 16:46, Ihor Radchenko wrote:
>> See the updated version of the patches attached.
>
> Thank you, I do not see apparent issues with code any more. Commit
> message needs an update, apostrophes in the doc string should be
> escaped. Feel free to ignore other
On 22/08/2023 16:46, Ihor Radchenko wrote:
See the updated version of the patches attached.
Thank you, I do not see apparent issues with code any more. Commit
message needs an update, apostrophes in the doc string should be
escaped. Feel free to ignore other comments since there are other
Max Nikulin writes:
> On 21/08/2023 14:04, Ihor Radchenko wrote:
>> +(defconst org-shell-arg-literal (gensym "literal")
>
> (opinion) Perhaps a better name exists. Maybe
> org-shell-arg-tag-unescaped (or unquoted)
> ...
See the updated version of the patches attached.
>From
On 21/08/2023 14:04, Ihor Radchenko wrote:
+(defconst org-shell-arg-literal (gensym "literal")
(opinion) Perhaps a better name exists. Maybe
org-shell-arg-tag-unescaped (or unquoted)
+ "Symbol to be used to mark shell arguments that should not be escaped.
+See `org-make-shell-command'.")
Max Nikulin writes:
> P.S. Babel backends should be consistent in respect to treating options
> for header arguments:
> - use as is
> - expand ~user and $VAR
> - allow any shell expression
We cannot generally know which header arg values can or cannot be
shell-expanded. It is something only
Max Nikulin writes:
>> Do you have any ideas how to work around the deliberately constructed
>> header argument values like in your example?
>
> Perhaps `gensym' may be used to create a symbol that can not appear in a
> document. I am unsure if the following `pcase' variant may be improved
>
On 18/08/2023 18:05, Ihor Radchenko wrote:
Max Nikulin writes:
Ihor, this is a list, not an expression to be evaluated. There are some
conditions to avoid user prompts for strings, lists, etc. They are
considered safe.
This particular case is handled namely by ob-sqlite and the proposed
Max Nikulin writes:
> Ihor, this is a list, not an expression to be evaluated. There are some
> conditions to avoid user prompts for strings, lists, etc. They are
> considered safe.
>
> This particular case is handled namely by ob-sqlite and the proposed
> function in org-macs.
Do you have
On 18/08/2023 15:43, Ihor Radchenko wrote:
Max Nikulin writes:
#+begin_src sqlite :db '(literal "/tmp/ob.sqlite$(date
>/tmp/ob-sqlite-vuln.log)")
select 1
#+end_src
Handling lisp values in header arguments is much more general issue not
tied to ob-sql or even to running shell commands.
Max Nikulin writes:
> On 13/08/2023 14:52, Ihor Radchenko wrote:
>> What do you think about creating a new API to built shell commands and
>> then using it across all the babel backends?
>
> I support the idea in general, but not its particular implementation as
> `org-make-shell-command' in
On 13/08/2023 14:52, Ihor Radchenko wrote:
What do you think about creating a new API to built shell commands and
then using it across all the babel backends?
I support the idea in general, but not its particular implementation as
`org-make-shell-command' in your patch.
It does not address
On 13/08/2023 14:52, Ihor Radchenko wrote:
+ (when separator (format "-separator %s" separator))
It should be escaped as a whole. It seems sqlite3 command line arguments
parser does not support -separator=| variant, so two words should be
quoted separately. Try :separator |
Max Nikulin writes:
> 8<
> #+begin_src elisp :results none
>(require 'ob-sqlite)
> #+end_src
>
> #+begin_src sqlite :db /tmp/ob.sqlite$(date >/tmp/ob-sqlite-vuln.log)
>select 1
> #+end_src
> >8
>
> Executing of the sqlite code block causes creation of the
>
Consider the following Org file
8<
#+begin_src elisp :results none
(require 'ob-sqlite)
#+end_src
#+begin_src sqlite :db /tmp/ob.sqlite$(date >/tmp/ob-sqlite-vuln.log)
select 1
#+end_src
>8
Executing of the sqlite code block causes creation of the
14 matches
Mail list logo
