On Mon, Dec 18, 2006 at 05:50:01PM -0700, Oleksandr Moskalenko wrote:
> * Lionel Elie Mamane <[EMAIL PROTECTED]> [2006-12-16 06:15:02 +0100]:
>> Here is an example session:
>> bashdb<21>
>> (/usr/sbin/mkinitramfs:81):
>> 81: . /usr/share/initramfs-tools/hook-functions
>> bashdb<22>
>> (/usr/sbin/mkinitramfs:83):
>> 83: . "${CONFDIR}/initramfs.conf"
>> bashdb<23> break copy_exec
>> File /usr/share/initramfs-tools/hook-functions not found in read-in files.
>> See 'info files' for a list of known files.
>> bashdb<24> break /usr/share/initramfs-tools/hook-functions:61
>> File /usr/share/initramfs-tools/hook-functions not found in read-in files.
>> See 'info files' for a list of known files.
>> bashdb<25> info files
>> Source files for which have been read in:
>> The said file has just been loaded, the debugger even recognises the
>> function name from it, but doesn't know the file.
> The file has not been sourced since you stepped over that line. If
> you'd like to source it you can get bash to know about that file by
> stepping into the file, and using "finish" to get back out. I will
> add a README to the package to make sure people see this point. This
> behavior may be changed upstream in a future release.
> Below is the information from the upstream author for your
> reference.
>> I'm not sure the user's analysis is correct. He thinks the file is
>> loaded in because merely because he sees a line like this
>> 81: . /usr/share/initramfs-tools/hook-functions
No, I think the file is loaded because fact is that bash sourced it;
because I didn't only "see" the
81: . /usr/share/initramfs-tools/hook-functions
line, but I had it *executed*/run. That the debugger didn't notice is
an imperfection in the debugger and/or the interface between bash and
the debugger and/or bash. I understand Rocky puts it in the "probably
too hard to fix" category, that's unfortunate but not deadly. If this
doesn't get fixed, the next best thing is to document it, as Oleksandr
said he would.
>> For now, the person can get bash to know about that file by
>> stepping into the file, and using "finish" to get back out.
OK, thanks for that information.
>> One possibility for fixing <snip> might be to see if I can redefine
>> the "source" command to track filenames and read them in.
. () { echo I am being called; builtin . "$@"; }
and
source () { echo I am being called; builtin source "$@"; }
seem to function as expected, so there is hope for this solution; you
can put your "track filename" actions in place of my echo?
--
Lionel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
