Re: Add non-interactive PROMPT_COMMAND

[積丹尼 Dan Jacobson]

> "AKK" == Andreas Kusalananda Kähäri  writes:
AKK> Does setting a DEBUG trap not do what you want? Such a trap would be
AKK> executed before each simple command...

OK! I guess it does! Thanks.

Re: command_not_found_handle() flaw

[Phi Debian]

Hi All,

Ok I got the picture now, and I owe you some apologize, but with what I got
in front of me (ubuntu 20.04, bash-git latest) mistake from my side was
easy to do.

Regarding the docco, I admit I got the latest bash source (git) BUT I read
the ubuntu 20.04 doc, that still DON'T mention the separate context (for
the 2 years to come :) ), when reading the 5.x latest bash.1 I reckon the
separate context is there, and up to that point (i.e with old doc in mind)
I could not think that this function was a "separate context"

Then the $$ vs $BASHPID confusion was a consequence of this.

So now the questionning about the implementation of this 'feature' that
seems to be, 'how to do something when a command is not found in an command
interpreter' and the idea behind is the implementation of a mechanism for
command interpreter (at large) to be able to suggest 'distro package
suggestion', or if the goal was not that at least this is how it is used a
the moment.

To me, to fullfil the feature as stated here, 2 implementation where
possible.

- A pure 'handler' like a trap handler, then executed in the top shell
context. This handler has then to be installed (sourced) in the shell
startup (similar to now)
- A pure script/prog invocation, then in a separate process, then separate
context. Something along the line of
BASH_CNF && $BASH_CNF "$@", this is pseudo code done in
execute_disk_command(), i.e check for BASH var for user liking doing CNF
and if so, simply prepand $BASH_CNF (likely to be command-not-found)  (as
currently it prepand command_not_found_handle) and retry
search_for_command() once with the new run string, this way it would go and
chase command-not-found in whatever place distro place it in the PATH, (Or
user replacement), The distro would simply source
BASH_CNF=command-not-found, and the user have control in her rc path for
sdjusting the setting.

A function invocation in a sub-shell (separate context) is the worst idea,
simply because
1) It require doc fixup, what was done for 5.x and a clear refresh of the
users mind, misleading path.
2) It need some ugly code in execute_disk_command()

I think in the current logic (distro sugestion) a pure chase of
command-not-found in PATH would have been simpler to document and implement.

Yet I personnaly prefer the 'trap logic', because it serve the same
services as current (distro sugestions) yet open the door for other things,
like function autoloading, customised error handling on CNF.

After all a CNF situation is an error, and a trap 'blah' ERR is correctly
trigged, and the handler executed in the top shell context. But we don't
want to implement CNF handling via trap ERR, because trap '' ERR is a bit
heavy.
So as an 'enhancemen't 'may be dreamin', having an ERRCNF pseudo signal
would be ideal, could even keep the 'old' half hearted
command_not_found_handle() (not a handler, not a script) and work together.
I noted the subtility in that function name, it is not called
command_not_found_handler() just because it is not an handler :) that's
what should have warned me from the beginning :)


Anyway, I will cope with that, and I have an implementation of lazy
function autoload that works with the current implementation,
command_not_found() simply sending a signal to main shell, saying we got a
CNF :) ugly but it works.

I love bash and all the evolution of it.
Cheers,
Phi

numerical comparison missing in bash and expr

[Joseph A. Russo]

From: jar
To: bug-bash@gnu.org,b...@packages.debian.org
Subject: numerical comparison missing in bash and expr

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -Wdate-time 
-D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-N2nMjo/bash-4.4.18=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall 
-Wno-parentheses -Wno-format-security
uname output: Linux rrl 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 
UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.4
Patch Level: 20
Release Status: release

Description:
all numerical tests using -ne, -lt, -le, -gt, or -ge fail. It appears 
that only string comparison is used. 

Repeat-By:
# the following two lines work  
[ 5 < 10 ] && echo true || echo false
[ 5 > 10 ] && echo true || echo false
# the next three lines fail
n=5
[ $n < 10 ] && echo true || echo false
[ $n > 10 ] && echo true || echo false


Fix:
[Description of how to fix the problem.  If you don't know a
fix for the problem, don't include this section.]

numerical comparison missing in bash and expr

[Joseph A. Russo]

From: jar
To: bug-bash@gnu.org,b...@packages.debian.org
Subject: numerical comparison missing in bash and expr

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -Wdate-time 
-D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-N2nMjo/bash-4.4.18=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall 
-Wno-parentheses -Wno-format-security
uname output: Linux rrl 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 
UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.4
Patch Level: 20
Release Status: release

Description:
all numerical tests using -ne, -lt, -le, -gt, or -ge fail. It appears 
that only string comparison is used. 

Repeat-By:
[ 5 < 10 ] && echo true || echo false
[ 5 > 10 ] && echo true || echo false

n=5
[ $n < 10 ] && echo true || echo false
[ $n > 10 ] && echo true || echo false


[ 5 -lt 10 ] && echo true || echo false
[ 5 -gt 10 ] && echo true || echo false

n=5
[ $n -lt 10 ] && echo true || echo false
[ $n -gt 10 ] && echo true || echo false

The above lines work in the following bash version:
GNU bash, version 4.3.11(1)-release (i686-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


Fix:
[Description of how to fix the problem.  If you don't know a
fix for the problem, don't include this section.]

Re: numerical comparison missing in bash and expr

[Greg Wooledge]

On Wed, Mar 11, 2020 at 07:29:38AM -0400, Joseph A. Russo wrote:
> # the following two lines work
> [ 5 < 10 ] && echo true || echo false
> [ 5 > 10 ] && echo true || echo false

You've misunderstood the syntax here.  The < sign introduces a
redirection of standard input, from a file named "10".

What you've written is equivalent to

[ 5 ] < 10 && echo true || echo false

The command [ 5 ] tests whether the string "5" has a non-zero length.
It does, and so the command returns "true" (exit status 0).

The SECOND command uses > which introduces an output redirection, to
a file named "10".  I believe you will find there is an empty file
named "10" in your working directory now, assuming you didn't delete
it after your tests.

> # the next three lines fail
> n=5
> [ $n < 10 ] && echo true || echo false
> [ $n > 10 ] && echo true || echo false

These commands are identical to the previous set.  The only difference
is whether the file named "10" existed or not.

If these "failed", it's perhaps because you ran these commands first,
before the file existed.  And you ran the first set of commands second,
after the file was created, which suppresses the error you would have
got from the input redirection when the file was missing.

There are various correct ways to perform integer comparisons in
bash.  From oldest to newest:

test "$n" -lt 10

[ "$n" -lt 10 ]

[[ $n -lt 10 ]]

((n < 10))

The first two are POSIX compatible.  The second two are bash extensions.

Re: numerical comparison missing in bash and expr

[Joseph A. Russo]

Hi,

Thank you

I appreciate the explanation and the prompt response.

Joe

On 3/11/20 9:24 AM, Greg Wooledge wrote:

On Wed, Mar 11, 2020 at 07:29:38AM -0400, Joseph A. Russo wrote:

# the following two lines work  
[ 5 < 10 ] && echo true || echo false
[ 5 > 10 ] && echo true || echo false

You've misunderstood the syntax here.  The < sign introduces a
redirection of standard input, from a file named "10".

What you've written is equivalent to

[ 5 ] < 10 && echo true || echo false

The command [ 5 ] tests whether the string "5" has a non-zero length.
It does, and so the command returns "true" (exit status 0).

The SECOND command uses > which introduces an output redirection, to
a file named "10".  I believe you will find there is an empty file
named "10" in your working directory now, assuming you didn't delete
it after your tests.


# the next three lines fail
n=5
[ $n < 10 ] && echo true || echo false
[ $n > 10 ] && echo true || echo false

These commands are identical to the previous set.  The only difference
is whether the file named "10" existed or not.

If these "failed", it's perhaps because you ran these commands first,
before the file existed.  And you ran the first set of commands second,
after the file was created, which suppresses the error you would have
got from the input redirection when the file was missing.

There are various correct ways to perform integer comparisons in
bash.  From oldest to newest:

test "$n" -lt 10

[ "$n" -lt 10 ]

[[ $n -lt 10 ]]

((n < 10))

The first two are POSIX compatible.  The second two are bash extensions.