Description of problem: If you execute command `foo bar` and foo is not installed. PackageKit should install foo and execute `foo bar` after the installation. Except of this only `foo` is being executed. Version-Release number of selected component (if applicable): PackageKit-command-not-found-0.6.9-4.fc14.x86_64 How reproducible: BE SURE THAT GIT IS NOT INSTALLED Steps to Reproduce: 1. git clone ssh://git.fedorahosted.org/git/smat.git 2. y 3. y Actual results: [lkocman@hoth workspace]$ git clone ssh://git.fedorahosted.org/git/smat.git Command not found. Install package 'git' to provide command 'git'? [N/y] * Running.. * Resolving dependencies.. The following packages have to be installed: perl-Error-1:0.17016-3.fc14.noarch Error/exception handling in an OO-ish way perl-Git-1.7.3.1-1.fc14.noarch Perl interface to Git Proceed with changes? [N/y] * Waiting for authentication.. * Running.. * Resolving dependencies.. * Downloading packages.. * Testing changes.. * Installing packages.. * Scanning applications.. usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path] [-p|--paginate|--no-pager] [--no-replace-objects] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [-c name=value] [--help] COMMAND [ARGS] The most commonly used git commands are: add Add file contents to the index bisect Find by binary search the change that introduced a bug branch List, create, or delete branches checkout Checkout a branch or paths to the working tree clone Clone a repository into a new directory commit Record changes to the repository diff Show changes between commits, commit and working tree, etc fetch Download objects and refs from another repository grep Print lines matching a pattern init Create an empty git repository or reinitialize an existing one log Show commit logs merge Join two or more development histories together mv Move or rename a file, a directory, or a symlink pull Fetch from and merge with another repository or a local branch push Update remote refs along with associated objects rebase Forward-port local commits to the updated upstream head reset Reset current HEAD to the specified state rm Remove files from the working tree and from the index show Show various types of objects status Show the working tree status tag Create, list, delete or verify a tag object signed with GPG See 'git help COMMAND' for more information on a specific command. Expected results: Cloning into smat... Warning: Permanently added 'git.fedorahosted.org,66.135.52.17' (RSA) to the list of known hosts. remote: Counting objects: 296, done. remote: Compressing objects: 100% (153/153), done. remote: Total 296 (delta 192), reused 209 (delta 138) Receiving objects: 100% (296/296), 79.68 KiB | 52 KiB/s, done. Resolving deltas: 100% (192/192), done. Additional info: This could potentially lead to an unexpected behaviour of application and lost of data. And should be fixed.
Hmm, this used to work. If you install an older version of bash, does the feature work? I'm asking because if you manually do: /usr/libexec/pk-command-not-found meld Makefile.am1 Makefile.am2 And then install meld, it comes up as expected. I think bash might be stripping the arguments before invoking the CNF handler.
It have to be some kind of bash stripping issue. I tried following version of f14 and run into the same problem bash-4.1.2-4.fc13.x86_64 /usr/libexec/pk-command-not-found foo bar1 bar2 works as expected.
The problem is in command_not_found_handle() function. From the man page of bash: If the search is unsuccessful, the shell searches for a defined shell function named command_not_found_handle. If that function exists, it is invoked with the original command and the original command’s arguments as its arguments, and the function’s exit status becomes the exit status of the shell. If that function is not defined, the shell prints an error message and returns an exit status of 127. In the handler in PackageKit is: # run the command, or just print a warning if [ $runcnf -eq 1 ]; then @LIBEXECDIR@/pk-command-not-found $1 retval=$? else echo "bash: $1: command not found" fi So you are using only $1 what is command name, but not command arguments. I will suggest to use: @LIBEXECDIR@/pk-command-not-found $@ (or $*) or something similar
(In reply to comment #3) > So you are using only $1 what is command name, but not command arguments. I > will suggest to use: > @LIBEXECDIR@/pk-command-not-found $@ (or $*) > or something similar I've tried both $@ and $*, and neither seems to work. Sorry.
$@ works for me with PackageKit-0.6.6-2.fc13.x86_64
Sorry, my bad - $@ will create wrong number of arguments. Use "$@" Anyway, why is this bug still open? :) Proper should be: @LIBEXECDIR@/pk-command-not-found "$@" And a nitpick: pk-command-not-found binary is adding dots after command not found message. So it looks like `bash: dfhfghj: command not found...' Also I'm not sure about return code. It's returning 0.
Created attachment 598419 [details] Fix for incorrect number of arguments and print error message to stderr Please apply the patch. Also the C code should be improved. When you try to run something which is not command and will not be installed, the binary should return with something else than retcode 0. Example: ksjfksfd && echo WHAT? || echo OK bash: sfdsdf: command not found WHAT? It should print OK.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.