Bug 731911 - PackageKit-command-not-found makes bash cache filepaths to programs deleted in session
Summary: PackageKit-command-not-found makes bash cache filepaths to programs deleted i...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-19 02:33 UTC by Jens Petersen
Modified: 2011-12-02 04:26 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-19 11:04:48 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jens Petersen 2011-08-19 02:33:41 UTC
Description of problem:
If I run a program in a bash shell and then delete and try
to run it again, bash complains that the file no longer exists!
While this is true it is rather annoying when the
deleted file was shadowing another binary further down PATH.
One has to start a new shell in order to run it which is annoying.

Version-Release number of selected component (if applicable):
PackageKit-command-not-found-0.6.17

How reproducible:
100%

Steps to Reproduce:
1. start a shell in recent Fedora default install
$ mkdir -p ~/bin
$ cat > ~/bin/myprog
#!/bin/sh
echo This is myprog
$ chmod u+x ~/bin/myprog
$ myprog
This is myprog
$ rm ~/bin/myprog
$ myprog
2.
$ sudo yum remove PackageKit
3. Repeat (1)

Actual results:
1.
bash: /home/liveuser/bin/myprog: No such file or directory
3.
bash: myprog: command not found...

Expected results:
1.
bash: myprog: command not found...

Comment 1 Jens Petersen 2011-08-19 02:35:24 UTC
This also happens with F15, and I have probably seen it on F14 too
and maybe even earlier.

Comment 2 Richard Hughes 2011-08-19 09:02:49 UTC
Isn't bash just calling the command-not-found callback erroneously? PackageKit doesn't do anything smart, it just runs when bash tells it to.

Comment 3 Roman Rakus 2011-08-19 10:50:29 UTC
Bash is calling command not found handler whenever (it is defined and when) you try run a command which is not found. The problem is in way how bash is trying to found it. Bash is using hash table to remember commands already run. You can clear that hash table, don't use it all, but default is hash table turned on. That means, you run a command, bash will remember full location and then will try tu run it on that location.
The strange thing here is;
$ rm ~/bin/myprog
$ myprog
2.

I will expect here "command not found" message.

Comment 4 Roman Rakus 2011-08-19 11:00:24 UTC
(In reply to comment #3)
> The strange thing here is;
> $ rm ~/bin/myprog
> $ myprog
> 2.
> 
> I will expect here "command not found" message.

I'm getting this message.
You have three solutions;
1) turn off hash tables (set +h)
2) clear hash table (hash -d)
3) turn on option that will force lookup for binary when the binary is not found on location specified in hash table - look at man page (shopt -s checkhash)

I will close this bug as notabug.

Comment 5 Jens Petersen 2011-12-02 04:26:39 UTC
Did this behaviour change at some point in the not so distant past?
I am pretty sure this was not always the case
- I still assumed not needing to (run) rehash
was one of the advantages of bash.

Is the default for security reasons or to avoid superfluous stat'ing?

It seems I should run "hash myprog" to workaround this.


Note You need to log in before you can comment on or make changes to this bug.