From: Milan Zimmermann <milan.zimmermann@gmail.com>
To: Jim Porter <jporterbugs@gmail.com>
Cc: 59666@debbugs.gnu.org
Subject: bug#59666: 29.0.50; Eshell: comparisons such as {> 3 2} do not work in Eshell context
Date: Fri, 2 Dec 2022 02:33:11 -0500 [thread overview]
Message-ID: <CAEc2VK1dz6Omy9EMnRV3sQVSLeMRse5Pqa78==f+mXDLS7ADkw@mail.gmail.com> (raw)
In-Reply-To: <af010c91-65da-8005-8a64-a33736c2b25a@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3182 bytes --]
On Thu, Dec 1, 2022 at 8:53 PM Jim Porter <jporterbugs@gmail.com> wrote:
> On 12/1/2022 5:38 PM, Milan Zimmermann wrote:
> > Would it be reasonable to suggest removing existing functionality as
> > follows:
> [snip]
> > The currently allowed
> >
> > 3. {command-call}
> > 4. (function-call)
> >
> > would represent syntax error.
> >
> > (3. is outright wrong as it brings silent invalid results)
>
> Both 3 and 4 are valid forms, although I think (lisp) and $(lisp) are
> equivalent. In particular, 3 is important for being able to check the
> exit status of external programs:
>
> ~ $ if {sh -c 'exit 0'} {echo yes} {echo no}
> yes
> ~ $ if {sh -c 'exit 1'} {echo yes} {echo no}
> no
> ~ $ if ${sh -c 'exit 0'} {echo yes} {echo no}
> no ;; Wrong!
> ~ $ if ${sh -c 'exit 1'} {echo yes} {echo no}
> no
>
>
Ah, thanks for pointing this out. I kept searching for a practical
semantics that justifies use of if {}. This is definitely important,
non-replaceable syntax. My suggestion to ban it was definitely incorrect
then.
> I think there's an argument that {lisp-function} should work the same as
> ${lisp-function}, but only for "regular" Lisp functions (i.e. excluding
> eshell/FOO ones; since those are designed to imitate external commands,
> they have different semantics).
>
I agree. I did not find a situation where {lisp-function} and
${lisp-function} would behave differently, but I have not looked yet.
So I put the following to my notes, based on your suggestions. If anyone
else is reading, please disregard my earlier suggestion to disallow the "if
{..}" form. Justified by checking external programs status.
1. use ~if {function-call}~ (only?) to check EXIT STATUS of the EXTERNAL
function (program) call.
2. use ~if ${function-call}~ for everything else Eshell, including internal
functions passed exported variables (as they force Eshell syntax)
3. use ~if (elisp-function-call)~ for everything pure-elisp, including
elisp functions passed setq-ed variables
4. use ~if $(elisp-function-call)~ seems equivalent and interchangeable
with the above
Examples of 1. - check exit status of EXTERNAL program
- if {sh -c 'exit 0'} {echo "external succeeded"} {echo "external failed"}
# external succeeded
- if {sh -c 'exit 1'} {echo "external succeeded"} {echo "external failed"}
# external failed
- if ${sh -c 'exit 0'} {echo "external succeeded"} {echo "external failed"}
# WRONG external failed
- if ${sh -c 'exit 1'} {echo "external succeeded"} {echo "external failed"}
# external failed
- Other example, if we want to check for success/failure in sed before
calling it
- # just to test: echo "aaa" | sed 's/aaa/bbb/' # bbb
- if {echo "aaa" | sed 's/aaa/bbb/'} {echo sed-success} {echo
sed-failure} # sed-success
- # just to test: echo "aaa" | sed 's/aaa/bbb' # /usr/bin/sed: -e
expression #1, char 9: unterminated `s' command
- if {echo "aaa" | sed 's/aaa/bbb'} {echo sed-success} {echo sed-failure}
# sed-failure
Examples
- export a="3"
- Bad use: if {equal $a "0"} { echo YES } { echo NO } # YES --
WRONG!!! (silently!!)
- Good use: if ${equal $a "0"} { echo YES } { echo NO } # NO -- correct
[-- Attachment #2: Type: text/html, Size: 4301 bytes --]
next prev parent reply other threads:[~2022-12-02 7:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 0:15 bug#59666: 29.0.50; Eshell: comparisons such as {> 3 2} do not work in Eshell context Milan Zimmermann
2022-11-29 2:03 ` Jim Porter
2022-12-02 1:38 ` Milan Zimmermann
2022-12-02 1:53 ` Jim Porter
2022-12-02 7:33 ` Milan Zimmermann [this message]
2022-12-03 19:31 ` Jim Porter
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAEc2VK1dz6Omy9EMnRV3sQVSLeMRse5Pqa78==f+mXDLS7ADkw@mail.gmail.com' \
--to=milan.zimmermann@gmail.com \
--cc=59666@debbugs.gnu.org \
--cc=jporterbugs@gmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.