Bug#821057:

[Fedor Uvarov]

Control: fixed -1 18.04.5-1

This bug seems to no longer occur in 18.04.5-1.

Bug#821057: command-not-found: Under zsh, given "VAR=value command", cnf looks for "VAR=value" if "command" exits with non-zero code

[Fedor Uvarov]

I think that this bug (probably as well as #813331 and #706731) could be 
resolved if zsh_command_not_found defined a
command_not_found_handler (a built-in zsh feature) instead of a preexec hack. 
That would make zsh provide the actual
command instead of an entire line that has to be manually lexed.

command_not_found_handler is actually pretty old, available since zsh 4.3.5 or 
earlier. There shouldn't be any
compatibility problems.

command-not-found 0.3 in Ubuntu already does this. It's probably a good idea to 
upgrade. Note that for this bug to be
fixed, a configuration file (/etc/zsh_command_not_found) would have to be 
replaced.

Bug#821057: command-not-found: Under zsh, given "VAR=value command", cnf looks for "VAR=value" if "command" exits with non-zero code

[Fedor Uvarov]

Package: command-not-found
Version: 0.2.38-3
Severity: normal
Control: affects -1 zsh

Hello,

Under zsh with command-not-found enabled, if you enter a command preceded by a
variable assignment, and that command exits with a non-zero status (whether
because it's missing or because it has finished with an error), then
command-not-found will start looking for the variable assignment as if it
were the missing command.

Here is a simple demonstration ("%" is the shell prompt):

% VAR=value false
VAR=value: command not found

"VAR=value: command not found" is produced by command-not-found, not zsh (if I
replace "false" with "true", I get no output). In this case command-not-found
obviously shouldn't search for anything at all.

Here is a demonstration with a non-existent command:

% VAR=value ttt
zsh: command not found: ttt
VAR=value: command not found

In this case the command is indeed not found, but command-not-found is
searching for the wrong thing. When I type just "ttt", command-not-found finds
a number of candidates.


The expected result is, obviously, that:

1. If a command is valid and exits with a non-zero status, command-not-found
shouldn't look for it at all.
2. If a command is actually not found, command-not-found should look for it
instead of trying to look up the variable assignment as if it were a command.


The version of the package "zsh" is 5.2-3.


This may or may not be related to bug #813331:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813331



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (101, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages command-not-found depends on:
ii  apt-file 3.0
ii  lsb-release  9.20160110
ii  python-gdbm  2.7.11-2
pn  python:any   

command-not-found recommends no packages.

command-not-found suggests no packages.

-- no debconf information