GNU bug report logs - #59666
29.0.50; Eshell: comparisons such as {> 3 2} do not work in Eshell context

Previous Next

Package: emacs;

Reported by: Milan Zimmermann <milan.zimmermann <at> gmail.com>

Date: Tue, 29 Nov 2022 00:17:02 UTC

Severity: normal

Found in version 29.0.50

Done: Milan Zimmermann <milan.zimmermann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Milan Zimmermann <milan.zimmermann <at> gmail.com>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 59666 <at> 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
[Message part 1 (text/plain, inline)]
On Thu, Dec 1, 2022 at 8:53 PM Jim Porter <jporterbugs <at> 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
[Message part 2 (text/html, inline)]

This bug report was last modified 2 years and 195 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.