From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id eMBlDKKNhmYYRgAA62LTzQ:P1 (envelope-from ) for ; Thu, 04 Jul 2024 11:55:14 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id eMBlDKKNhmYYRgAA62LTzQ (envelope-from ) for ; Thu, 04 Jul 2024 13:55:14 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=InMqJynL; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1720094114; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=L1S6FfBOIW4F5OvhYoL5Q7NOt1pSZPJ9ZBT3aYJ8/GE=; b=YOK5XzdDgBh5HFgvikA4c/W7GkTyHeMq90G3ImME+WfwQ0Az4SSvNOLXZmrQ5Tni2phuaD pbVHq6qRPftVfhfn6eIbYgeZBbnhjv7sIKD2L8NMRLAEfZUxjbb5DIrb0ZhSOdQ29fpBa7 M4m8GzK+BkUtldniL0dJPqbjosh9DFDQty3ySlfxFojdQQnA+uZOfGN4VPBCzHyoMMg+zE bf9eewQH2LIHhAM+GUNPnWpfPi/y1itEBl5aXaJLwp8VPwHzGuNzjdRHtZiF9Ffzjtouab vOLgnbKaxw6ZH2OKwMQuY6KsIkLb2WsmPKlZgn0IvnaSSPCTQQNXJjxPNwzUSw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1720094114; a=rsa-sha256; cv=none; b=TIwcZvwFx2y0mj2/dUrewadKEeuukr//4SSan0bzP7RtA2TdxJOYTERySEV0Vw0MYTqLXK zHHGQxGSoinasR6xOHrXC3evQiMNpHVl87lLOb1PCmy8L4989M9cplRHfOCv4aNKUMbxyY 8jEabWTcIGDvh7Km4yqDlw0MrP1sYPbN2iCCXQR+BZLdsdJv8gWwOI9lFKMuLbIf6KyN+7 i+3BjH55h7vgbeJL7a+pEOVRXU87EtBFEK7Ze7HOBfjHeTtEfZMTcJTROrKTpfG6nAVV+n /ek8XdAAwc8uBT/zuV3x7OLR4hF7wBJhPBPIvP0SjBhYX5lL9RQOxBVjPau8Qw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=InMqJynL; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 20D0D63FA4 for ; Thu, 4 Jul 2024 13:55:14 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sPL2M-0004oh-8h; Thu, 04 Jul 2024 07:54:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sPL2L-0004oW-0x for emacs-orgmode@gnu.org; Thu, 04 Jul 2024 07:54:05 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sPL2B-0005NQ-02 for emacs-orgmode@gnu.org; Thu, 04 Jul 2024 07:54:04 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id A417C240029 for ; Thu, 4 Jul 2024 13:53:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1720094030; bh=Yel6qOLL8/l+kmtSBR09IpxA3MtQEo8i8uG+isSPuLw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=InMqJynLMizD67VN7Bn3KfDPjo+8qlQor6SBznhJ/WjwNyOJJKUdMM4o+3fvnKCwR nY6iZqL36jSW3DCXAkPWQc+PxCVefr5PtRn3sD7Dw7n+SQfc9jKvkA8pJZ5oMG6ezP yPnK6Pxfuxcqk8DLwAeh7mdCQdMb0GlHS7aKTCXhmZ0SOfd00UNfjJTvRapw7wFggt Tgrh6QZPdCmpWQZBAX4+hgACTJNUg6vgQEV2FAR/PxPBYJXqOwep0v6C2/fdmGGZ7W ICphdsR9OFe+XwGKI3FUNDkG4LeojLslpt/gzWP63hG3M6ECUK00qWOrWnebu99BKh V7RR61JLLPa4Q== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WFFRK72mfz9rxP; Thu, 4 Jul 2024 13:53:49 +0200 (CEST) From: Ihor Radchenko To: Phil Cc: emacs-orgmode@gnu.org Subject: Re: org-babel-execute-src-block filters characters from :session *shell* output In-Reply-To: References: <87ikybk44c.fsf@localhost> <87o782gx7o.fsf@localhost> <87h6dra1ut.fsf@localhost> <874j9al08g.fsf@localhost> <5d3c8cce-b79d-43c2-baaa-459fea1ed3d9@7d.nz> <87bk3fa7ap.fsf@localhost> Date: Thu, 04 Jul 2024 11:55:26 +0000 Message-ID: <87wmm1pe1d.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Queue-Id: 20D0D63FA4 X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -8.11 X-Spam-Score: -8.11 X-TUID: HNNvzB0pV3D1 Phil writes: > The error management channel is important. Only a very > small fraction of errors should be silenced, and we > must not have feedback displaying that a function ran > correctly when it did not. Sure. I completely agree. > Let's decouple an interactive shell from its > compiler/interpreter (setting aside a Lisp > evaluator that can dodge most of the problems): > > In many programming languages the source code can > indeed be assimilated line by line by the > interpreter through an interactive shell. > - It returns nothing or an error after a definition > or a silent directive, then the prompt. > - One or more values as a result or errors, then the prompt, > when calling functions and procedures. > - It can expect more input and more lines before > terminating a statement, returning a secondary > prompt until that statement completes or fails. > > The terminal display is organized from programming > interactions but the separation of channels is needed > for further processing. > > 1) We should avoid filtering output with regexp acrobatics. It is indeed not ideal. But it is hard to do better. We simply do not have the means. Of course, if someone can find a more robust way to decouple errors, actual evaluation results, prompts (primary, secondary, etc), and the interpreter echoing the input, it would be a patch we will happily accept. > 2) Communication with the process should go > through a function that can display > inputs and outputs and errors in three different channels > before sending it to the process. > Communicating directly to the process should remain > possible, but it's a short-circuit. Yes, of course. But how? > + Err : file, line, error code, message, > including the prompt which goes to stderr. > + The line number where the error occurs > related to a source block. There may be extra code > wrapping a block and noweb may complicate > things even more. > The situation to avoid is a line number unrelated > to the edited source block. > (Weaving and tangling programs is fine for me > I'm only thinking out loud here). > Example: > Errors goes in one file buffer > and a filter wraps them in blocks. > file:/tmp/babel-uuid/fiction.err > #+begin_err :lang fiction :err 5 :line 2 > Parse error: near "?": syntax error > ? ; > ^--- error here > #+end_err This would be nice to have for sessions, yes. We already have this for many non-session code blocks. > Should all commands in a block be run ? > It depends on the language of course, but usually, no, > the execution stops and drops into a backtrace > or raises an exception pointing to the stack frames. > Dash has =set -e= (that doesn't always behave as expected). > Sqlite has =.bail= for noninteractive sessions. I am not sure if I agree, but your preference is a valid preference some people might have. Our defaults are to send the whole block, which is an ok option as well. > And now here is my problem. > Am I missing something about carriage return ? > A differentiation problem between what happen > when pressing C-q C-j in a shell, and ? > > If ob-sql-session concatenates the SQL > commands on one line, sqlite is able to stop on error. > #+begin_src sql-session :engine sqlite :session A > select 1; raise; select 2; > select 33; > #+end_src > > #+RESULTS: > : 1 > : Parse error: near "raise": syntax error > : raise; select 2; select 33; > : ^--- error here > > If it does not, a newline terminates the command, > the prompt is displayed and the next line is > an other command. Which is not the desirable effect > as there's no way to halt the remaining commands. This is simply how comint.el buffers work. C-q C-j will enter literal newline. will send the command entered so far (including literal newlines) as input stream to the interpreter. All at once. The reason why comint does not do line-by-line is simply because it has limited notion of the interpreter syntax - multiple lines may or may not be several commands. Think of \ continuation in bash. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at