From: Matt <matt@excalamus.com>
To: "Ihor Radchenko" <yantar92@posteo.net>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: bash source code block: problem after ssh commands
Date: Wed, 08 Nov 2023 20:41:43 +0100 [thread overview]
Message-ID: <18bb07473e2.1007b1565819307.6938164403009000496@excalamus.com> (raw)
In-Reply-To: <875y2e2b9y.fsf@localhost>
---- On Tue, 07 Nov 2023 09:53:46 +0100 Ihor Radchenko wrote ---
> Matt matt@excalamus.com> writes:
>
> > ---- On Mon, 06 Nov 2023 14:32:16 +0100 Ihor Radchenko wrote ---
> > > I am wondering about the possible downsides of using script approach
> > > instead of stdin redirection.
> >
> > I'm curious to hear more about what you're thinking.
>
> I am thinking to change the
> (t (org-babel-eval shell-file-name (org-trim body)))
> clause in `org-babel-sh-evaluate' to something that uses a script file.
>
> It will clearly solve the discussed problem, possibly at the cost of
> small overhead to write the script file to disk.
Thanks for clarifying. I've been away from the codebase for a bit and, now that the FSF paperwork is signed (still need to get Craig a copy), I'm reviewing =ob-shell= with an eye for what could be cleaned or improved. I feel like =org-babel-sh-evaluate= could use some attention.
I'm open to your suggestion. The good is that using a script is how :shebang and :cmdline are processed currently (like you pointed out) so there's precedence and experience with it. Also, it would make all non-session execution use the same model (script versus comint). I like how that would create a clean separation.
For bad, nothing jumps out to me as obviously a problem. Let me "think out loud" for a moment. We'd need to write to disk. Like you say, this incurs overhead opening, writing, and closing the file. It's not like we'd forget to close it, though. Nor is running out of space or inodes our problem. Writing requires permission. That's not an issue with /tmp. Then, it needs to execute. Aside from permission, any code we insert needs to be correct. For example, a shebang would need to point to the correct application and any arguments would need to correspond to the implementation being called. I doubt we'd need anything beyond /bin/<shell>. FWIW, it looks like there's been at least one instance where :shebang's formatting was questioned (https://yhetil.org/orgmode/CA+A2iZZ1vMmKiUf4Fem1AU7CA1m9GQap+BkvrOsz+0BxRt6rRA@mail.gmail.com/). We'd also need to control for what environment the script runs in. That was another issue I saw raised in the list (https://yhetil.org/orgmode/87609ug5ae.fsf@luisa.c0t0d0s0.de/). Of course, we'd need to read the stdout and stderr. This is handled by =process-file=. Any step I missed or some kind of failure I didn't consider?
next prev parent reply other threads:[~2023-11-08 19:42 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-25 11:17 bash source code block: problem after ssh commands Alain.Cochard
2023-10-25 15:12 ` Leo Butler
2023-10-25 16:14 ` Alain.Cochard
2023-10-25 16:47 ` Leo Butler
2023-10-25 16:59 ` yaxp
2023-10-26 8:44 ` Ihor Radchenko
2023-10-26 13:23 ` Alain.Cochard
2023-10-26 13:44 ` Ihor Radchenko
2023-10-27 18:26 ` Alain.Cochard
2023-10-28 5:22 ` Max Nikulin
2023-10-30 10:50 ` Bruno Barbier
2023-11-06 13:32 ` Ihor Radchenko
2023-11-06 18:25 ` Matt
2023-11-07 8:55 ` Ihor Radchenko
2023-11-08 19:41 ` Matt [this message]
2023-11-09 12:14 ` Ihor Radchenko
2023-11-09 17:48 ` Matt
2023-11-15 16:32 ` Matt
2023-11-15 18:04 ` Matt
2023-11-16 9:32 ` Ihor Radchenko
2023-11-16 19:03 ` Matt
2023-11-16 19:46 ` Alain.Cochard
2023-11-16 20:54 ` Matt
2023-11-17 9:22 ` Ihor Radchenko
2023-11-17 9:55 ` Alain.Cochard
2023-11-17 10:17 ` Ihor Radchenko
2023-11-17 15:32 ` Leo Butler
2023-11-17 15:47 ` Bruno Barbier
2023-11-18 10:37 ` Ihor Radchenko
2023-11-21 19:01 ` Bruno Barbier
2023-11-22 17:06 ` Max Nikulin
2023-11-19 4:17 ` Non-emacs shell (Re: bash source code block: problem after ssh commands) Max Nikulin
2023-11-21 15:33 ` Bruno Barbier
2023-11-18 8:04 ` bash source code block: problem after ssh commands Max Nikulin
2023-11-18 10:43 ` Ihor Radchenko
2023-11-18 16:18 ` Max Nikulin
2023-11-17 22:07 ` Matt
2023-11-18 3:11 ` Forget about "bash -c bash file.sh" (Re: bash source code block: problem after ssh commands) Max Nikulin
2023-11-18 8:11 ` Matt
2023-11-18 8:29 ` Bruno Barbier
2023-11-18 8:43 ` Matt
2023-11-18 8:54 ` Bruno Barbier
2023-11-18 9:09 ` Matt
2023-11-18 9:11 ` Bruno Barbier
2023-11-18 10:47 ` Ihor Radchenko
2023-11-18 8:19 ` bash source code block: problem after ssh commands Bruno Barbier
2023-11-18 9:02 ` Matt
2023-11-18 15:51 ` Matt
2023-10-26 14:44 ` Russell Adams
2023-10-27 11:47 ` Alain.Cochard
2023-11-06 18:01 ` Matt
2023-11-07 0:51 ` Alain.Cochard
2023-11-18 8:09 ` Max Nikulin
2023-11-18 8:36 ` Bruno Barbier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18bb07473e2.1007b1565819307.6938164403009000496@excalamus.com \
--to=matt@excalamus.com \
--cc=emacs-orgmode@gnu.org \
--cc=yantar92@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).