From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Milan Zimmermann Newsgroups: gmane.emacs.bugs Subject: bug#59612: 29.0.50; Eshell: The behavior of conditionals depends on whitespace Date: Sat, 26 Nov 2022 21:16:42 -0500 Message-ID: References: <8fec9d79-4118-eaa5-b762-c57f11f41aef@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a791de05ee6a5aaa" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1965"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 59612@debbugs.gnu.org To: Jim Porter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 27 03:18:30 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oz7FU-0000Kr-VQ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 27 Nov 2022 03:18:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oz7F9-0001q6-HJ; Sat, 26 Nov 2022 21:18:07 -0500 Original-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 1oz7F6-0001pg-2S for bug-gnu-emacs@gnu.org; Sat, 26 Nov 2022 21:18:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oz7F5-0004Dn-QQ for bug-gnu-emacs@gnu.org; Sat, 26 Nov 2022 21:18:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oz7F4-0001ob-H8 for bug-gnu-emacs@gnu.org; Sat, 26 Nov 2022 21:18:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Milan Zimmermann Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Nov 2022 02:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59612 X-GNU-PR-Package: emacs Original-Received: via spool by 59612-submit@debbugs.gnu.org id=B59612.16695154546649 (code B ref 59612); Sun, 27 Nov 2022 02:18:02 +0000 Original-Received: (at 59612) by debbugs.gnu.org; 27 Nov 2022 02:17:34 +0000 Original-Received: from localhost ([127.0.0.1]:41759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oz7EX-0001iy-VC for submit@debbugs.gnu.org; Sat, 26 Nov 2022 21:17:34 -0500 Original-Received: from mail-vk1-f171.google.com ([209.85.221.171]:35803) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oz7ES-0001iq-7o for 59612@debbugs.gnu.org; Sat, 26 Nov 2022 21:17:28 -0500 Original-Received: by mail-vk1-f171.google.com with SMTP id r13so3743234vkf.2 for <59612@debbugs.gnu.org>; Sat, 26 Nov 2022 18:17:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5tBTbPFEYgzC1irDyx/AVjoKS+soXIKodzEFYJMGyL0=; b=eIh2PyxbPDlmcOSO/TbFp3MIE7Wp5YnEjMWmNChF0+GkLu2oFEd7voT6pLCB5+oO33 7QItuXZrLwpr5o1jdSODTwSStb4qp7Yu7pAVYczzkGqCKygOfiIbhOtol21BIq60fmMP 4o1lz0kmFi3v1jZ8DNdjVHkIWUl30sTuVu451uCWucwX9m6ybwmoNRwbRx7GTvc1Lste lOfX8T49KkTOo5pok69Nx91ZGhn+QSEiBUCdF3ZwF/2ft1nHXk1xxnQKPzR+iIK1Lk6b T97q5PBkezs9eyEUI/vS1BIjpLoPHM/AzU6LR8EkqtiZeXc4hd7CxQtZGPJvx547AXB3 197g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5tBTbPFEYgzC1irDyx/AVjoKS+soXIKodzEFYJMGyL0=; b=H0pv/ApA3Tr3DZ3b1UyRNEgjlLtKbHZVlIzXUKiBSUaDZVf56nzrUecxU+avRhJtP2 4+majueSK7xpqvGiJH/mMjKLqpWCCcbf6YqoQCL3dcgBps1Csy1HPbojdtKDoi9/mXHz +BZ7gzyJyGQ357VV3pY8uwnfjG5IT3mu39+looR/oJ4YgpW/6HsOjLKMuc238cOh8+br QIMdLOA97YEEHMPpK/AuxdBrM1YwoKEsDh0ElMqEVDIQMviXM3PQt86ORiP0gh6Lzh/7 DqL62V8loHTOngF5jJhy5f1UhDFYSQx3FCcZeg99inV8uotIwCAG70BHbwgoNLwLmkH/ xsag== X-Gm-Message-State: ANoB5plgnnJUaqw5IoK3QvUwr4RdolbeX1q24bA3ybN4l+RS4B/LTDB3 HfQ34FvQ5/14u6cwPq3A8SD+cl+GNdmA2KNwLTyKm6ed0rE= X-Google-Smtp-Source: AA0mqf7kOd/OM88IyD97grbOeX8eUZTF635Hqf0mXeZqgkfAFvxtpgo3o59xJRTHw9Ecrvv6fg75q1SUFeY44O7MLfE= X-Received: by 2002:a1f:1e01:0:b0:3bc:b857:af63 with SMTP id e1-20020a1f1e01000000b003bcb857af63mr6387520vke.32.1669515438427; Sat, 26 Nov 2022 18:17:18 -0800 (PST) In-Reply-To: <8fec9d79-4118-eaa5-b762-c57f11f41aef@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:249160 Archived-At: --000000000000a791de05ee6a5aaa Content-Type: text/plain; charset="UTF-8" Jim, thanks for the follow-up. Please feel free to close this. A few comments inline though: On Sat, Nov 26, 2022 at 1:42 PM Jim Porter wrote: > On 11/26/2022 7:52 AM, Milan Zimmermann wrote: > > # Result: > > # "It is 3" > > # "It is NOT 3" > > # > > > > if { = 3 3 } { > > echo "It is 3" > > } > > { > > echo "It is NOT 3" > > } > > According to Eshell's logic, I think this is correct (though > inconvenient). Because Eshell treats a newline as the end of a command > whenever possible, it just sees these as two separate commands. > Yes, I agree. From the way of thinking "whitespace should not matter" it is a surprising behavior though. > > > # BUT we get the same incorrect result if we place the whole if > > expression into {} > > { > > if { = 4 4 } { > > echo "It is 4" > > } > > { > > echo "It is NOT 4" > > } > > } > > This is really the same as the above: {...} allows multiple commands, so > it sees this as two separate commands nested inside the {}. > Yeah, I realized the same during my hike today. The wrapping {..} should not make a difference, asking for that would make things worse. > > Ultimately, I think this is closer to a feature request: adding an > "else" token would disambiguate this: > > if { = 2 2 } { > echo "good" > } > else { > echo "bad" > } > > Actually making this work in Eshell's internals might be painful though... > Yes. Well, personally I feel the current behavior means that "lisp-iness" seeps through too much into the scripting behavior. So a feature request for adding and "else" would work for me. I will abstain from doing that at the moment, as I feel asking something like that requires a deeper review of how close eshell should behave like lisp syntax-wise. But if someone files such a request, I will not complain :) BTW, a slightly related question if I may: A further diversion of lisp-iness, I do not suppose there is a way to do a "return"? In bash, the ability to "return" from sourced bash scripts or functions allows us to deal with errors at the beginning, then process the main logic. In Eshell , I am doing things like: ============= if ${ not { = {length $*} 3 } } { echo "Invalid arguments: $*" echo "Usage: $0 file-to-generate.dart snippet.dart template.dart" } { if ${ not { file-exists-p $2 || file-exists-p $3 } } { echo "File $2 or $3 does not exist." } { ##### The main logic here is indented 2 levels deep export file-to-generate=$1 export snippet="${cat $2}" export template="${cat $3}" echo $file-to-generate echo $snippet echo $template # todo : check if template contains string %s # format string template, substitute snippet, place to generated-code # echo generated-code to file-to-generate } } ============= > > I do also see a potential bug. I'd expect this to work, but it doesn't: > > if { = 2 2 } \ > { echo "good" } \ > { echo "bad" } > Yeah, you are right. I just tried that. Thanks, Milan --000000000000a791de05ee6a5aaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jim, thanks for the follow-up. Please feel fre= e to close this.=C2=A0 A few comments inline though:3D""


On Sat, Nov 26, 2022 at 1:42 PM Jim Porter <jporterbugs@gmail.com> wrote:
On 11/26/2022 7:52= AM, Milan Zimmermann wrote:
> # Result:
> # =C2=A0"It is 3"
> # =C2=A0"It is NOT 3"
> #
>
> if { =3D 3 3 } {
>=C2=A0 =C2=A0 =C2=A0echo "It is 3"
> }
> {
>=C2=A0 =C2=A0 =C2=A0echo "It is NOT 3"
> }

According to Eshell's logic, I think this is correct (though
inconvenient). Because Eshell treats a newline as the end of a command
whenever possible, it just sees these as two separate commands.

Yes, I agree. From the way of thinking "white= space should not matter" it is a surprising behavior though.=C2=A0

> # BUT we get the same incorrect result if we place the whole if
> expression into {}
> {
>=C2=A0 =C2=A0 if { =3D 4 4 } {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0echo "It is 4"
>=C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0echo "It is NOT 4"
>=C2=A0 =C2=A0 }
> }

This is really the same as the above: {...} allows multiple commands, so it sees this as two separate commands nested inside the {}.

Yeah, I realized the same during my hike today. The wr= apping {..} should not make a difference, asking for that would make things= worse.
=C2=A0

Ultimately, I think this is closer to a feature request: adding an
"else" token would disambiguate this:

=C2=A0 =C2=A0if { =3D 2 2 } {
=C2=A0 =C2=A0 =C2=A0echo "good"
=C2=A0 =C2=A0}
=C2=A0 =C2=A0else {
=C2=A0 =C2=A0 =C2=A0echo "bad"
=C2=A0 =C2=A0}

Actually making this work in Eshell's internals might be painful though= ...

Yes. Well, personally I feel the cu= rrent behavior means that "lisp-iness" seeps through too much int= o the scripting=C2=A0behavior. So a feature request for adding and "el= se" would work=C2=A0for me.=C2=A0 I will abstain from doing that at th= e moment, as I feel asking something like that requires a deeper review of = how close eshell should behave like lisp syntax-wise. But if someone files = such a request, I will not complain :)=C2=A0=C2=A0

BTW, a slightly=C2=A0related question if I may: A further diversion of lis= p-iness, I do=C2=A0not suppose=C2=A0there is a way to do a "return&quo= t;? In bash, the ability to "return" from sourced bash scripts or= functions allows us to deal with errors at the beginning, then process the= main logic. In Eshell , I am doing things like:

= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
if ${ not { =3D {length $= *} 3 } } {
=C2=A0 =C2=A0echo "Invalid arguments: $*"
=C2=A0= =C2=A0echo "Usage: $0 =C2=A0file-to-generate.dart =C2=A0snippet.dart = =C2=A0template.dart"
} {
=C2=A0 =C2=A0if ${ not { file-exists-p = $2 || file-exists-p $3 } } {
=C2=A0 =C2=A0 =C2=A0 echo "File $2 or = $3 does not exist."
=C2=A0 =C2=A0} {
=C2=A0 =C2=A0 =C2=A0 ##### = The main logic here is indented 2 levels deep
=C2=A0 =C2=A0 =C2=A0 expor= t file-to-generate=3D$1
=C2=A0 =C2=A0 =C2=A0 export snippet=3D"${ca= t $2}"
=C2=A0 =C2=A0 =C2=A0 export template=3D"${cat $3}"=

=C2=A0 =C2=A0 =C2=A0 echo $file-to-generate
=C2=A0 =C2=A0 =C2=A0= echo $snippet
=C2=A0 =C2=A0 =C2=A0 echo $template

=C2=A0 =C2=A0 = =C2=A0 # todo : check if template contains string %s
=C2=A0 =C2=A0 =C2= =A0 # format string template, substitute snippet, place to generated-code=C2=A0 =C2=A0 =C2=A0 # echo generated-code to file-to-generate
=C2=A0 = =C2=A0}
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I do also see a potential bug. I'd expect this to work, but it doesn= 9;t:

=C2=A0 =C2=A0if { =3D 2 2 } \
=C2=A0 =C2=A0{ echo "good" } \
=C2=A0 =C2=A0{ echo "bad" }

Y= eah, you are right. I just tried that.=C2=A0

Thank= s,
Milan
--000000000000a791de05ee6a5aaa--