Using Zsh, it doesn't show an error message when command not found

Bug #1766068 reported by Ricardo Pérez López
54
This bug affects 9 people
Affects Status Importance Assigned to Milestone
command-not-found (Debian)
Fix Released
Unknown
command-not-found (Ubuntu)
Fix Released
Low
Unassigned
Bionic
New
Undecided
Unassigned
Eoan
Won't Fix
Undecided
Unassigned
Focal
New
Undecided
Unassigned

Bug Description

[Impact]
In zsh, typing a command that is unknown to command-not-found does not trigger a command not found message, but does nothing. If your command were silent, you might think it was executed.

[Test case]

Type a command in zsh that command-not-found does not know about, and check there is an error message that says command not found.

[Regression potential]

Given that this only affects a cnf handler, any regressions that could arise would be confined to that.

There should not be any regressions, as anything that would regress now should have also regressed when zsh itself changed behavior and caused this bug.

[Original bug report]

- Using latest Ubuntu Bionic, full updated.

- Using Zsh.

My ~/.zshrc includes the following line:

  . /etc/zsh_command_not_found

When I type (for example):

  $ sdlkfjslkdfjkdslf

it doesn't say nothing. No error message.

If I change the line #11 of /etc/zsh_command_not_found and I remove '--no-failure-msg' option, then it works OK:

  /usr/lib/command-not-found -- ${1+"$1"} && : (line 11, without --no-failure-msg option)

I think the above option should be removed from /etc/zsh_command_not_found.

tags: added: command-not-found zsh
tags: removed: zsh
tags: added: zsh
tags: added: bionic
Revision history for this message
Ricardo Pérez López (ricardo) wrote :

It works out-of-the-box in Ubuntu Xenial.

Revision history for this message
Ricardo Pérez López (ricardo) wrote :

I've found the origin of the problem.

Since Zsh 5.3, the command_not_found_handler() behavior has changed, as you can see here:

https://github.com/zsh-users/zsh/blob/9e2afb92987d7fd96a838c15b6641cc1b634a825/README#L207-L214

Copy & paste:

  6) Previously, if the function command_not_found_handler was run
  in place of a command-not-found error, and the function returned
  non-zero status, zsh set the status to 127 and printed an error message
  anyway. Now, the status from the handler is retained and no additional
  message is printed. The main reasons for this change are that it was not
  possible to return a non-zero status to the parent shell from a command
  executed as a replacement, and the new implementation is more consistent
  with other shells.

So now, when you define a custom command_not_found_handler() function in Zsh, the shell never print an error message by itself, i.e., the error message must be printed by the handler function.

According to the above, I think the only solution is by remove the '--no-failure-msg' option from the /etc/zsh_command_not_found and therefore the command_not_found_handler() function is the only responsible to print error messages to the user.

Revision history for this message
Ricardo Pérez López (ricardo) wrote :

It worked in Ubuntu Xenial because it ships Zsh 5.1 and the new behavior was introduced in Zsh 5.3.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in command-not-found (Ubuntu):
status: New → Confirmed
Changed in command-not-found (Ubuntu):
importance: Undecided → Low
status: Confirmed → Triaged
Revision history for this message
Shuhao (shuhao) wrote :

The first line of the handler is also somewhat problematic. Namely:

[[ -x /usr/lib/command-not-found ]] || return 1

If command-not-found package is removed and this file is not, it will stop printing the message even if --no-failure-msg is removed.

Revision history for this message
Shuhao (shuhao) wrote :

Actually, maybe I spoke too soon: there's an if guarding the definition of the function at the top of that file.

Revision history for this message
Ricardo Pérez López (ricardo) wrote :

Any news about this issue?

Revision history for this message
Ricardo Pérez López (ricardo) wrote :

The bug is still reproducible with Ubuntu 19.04.

Revision history for this message
Joel Cross (ukch) wrote :

I raised the equivalent bug in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927876

Revision history for this message
Joel Cross (ukch) wrote :
Revision history for this message
Joel Cross (ukch) wrote :

I have added the above patch to remove the --no-failure-message flag, which seems to fix the problem (I have also bumped compat and standards versions).
Please consider applying the patch and releasing a new version of the package.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "Remove --no-failure-message from zsh_command_not_found" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubuntu:
status: New → Confirmed
Mathew Hodson (mhodson)
affects: command-not-found → ubuntu
no longer affects: ubuntu
Changed in command-not-found (Debian):
status: Unknown → New
Revision history for this message
Simon Quigley (tsimonq2) wrote :

Please submit this patch to Debian, where it will flow down to Ubuntu.

Unsubscribing the Ubuntu Sponsors Team.

Revision history for this message
Julian Andres Klode (juliank) wrote :

Simon was a bit wrong, as the upstream situation is reversed, but either way, I guess it's me taking a look at it :)

Revision history for this message
Joel Cross (ukch) wrote :

@juliank is there any update on this bug? Did you ever get the chance to look at my patch?

Revision history for this message
Nathan Collins (ntc2) wrote :

Bump, @juliank !

Revision history for this message
Ricardo Pérez López (ricardo) wrote :

Two years now since I submit this bug report. Any news?

Revision history for this message
Joel Cross (ukch) wrote :

Unfortunately not. @juliank seems to have gone incommunicado on this issue.
Since I have a patch that fixes this issue, would it be helpful to people if I make a PPA containing the patched command-not-found? Then at least there will be a solution for people until someone from Ubuntu eventually picks this up (which realistically isn't looking likely any time soon).

Changed in command-not-found (Ubuntu):
status: Triaged → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package command-not-found - 20.10.0

---------------
command-not-found (20.10.0) groovy; urgency=medium

  * zsh: Do not pass --no-failure-msg, non-existing commands were not getting
    any output at all (LP: #1766068) (Closes: #927876)

 -- Julian Andres Klode <email address hidden> Mon, 01 Jun 2020 13:44:25 +0200

Changed in command-not-found (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Ricardo Pérez López (ricardo) wrote :

Thank you very much, juliank!

Could this fix be backported to 20.04?

description: updated
Revision history for this message
Brian Murray (brian-murray) wrote :

The Eoan Ermine has reached end of life, so this bug will not be fixed for that release

Changed in command-not-found (Ubuntu Eoan):
status: New → Won't Fix
Changed in command-not-found (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.