* Lionel Elie Mamane <[EMAIL PROTECTED]> [2006-12-16 06:15:02 +0100]:
> Package: bashdb
> Version: 3.1.0.7-1
> Severity: normal
>
> 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:
>
> /usr/sbin/mkinitramfs (299 lines)
>
>
> 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
>
> This just means that the printed statement is about to be run. The
> debugger makes no attempt to parse the statement to figure out that
> there is a *source* command and what the file is to be used. In the
> session shown, rather than descend into this source which *would* have
> caused the file to be registered, he "next"ed around it. The debugger
> know about files only because it is currently stopped inside one. So
> no, the debugger really doesn't know about that include file.
>
> But as for function names, it queires that from bash, so yes, that
> function name is known.
>
> For now, the person can get bash to know about that file by stepping into
> the file, and using "finish" to get back out.
>
> One possibility for fixing <snip> might be to see if I can redefine the
> "source" command to track filenames and read them in.
>
> If you look at the underlying mechianism "trap DEBUG" though I think
> all you get is line/file info and so that's the only thing we can key
> off of to stop. There is some sort of "functrace" bit that can be set,
> but I don't believe setting that will cause you to *stop* inside the
> function, it just allows "trap DEBUG" to do it's thing.
>
> (I'm not up for going through the process of patching bash and
> submitting a patch to get this fixed - this is where I think it is
> best dealt with.)
Regards,
Alex.
> -- System Information:
> Debian Release: 4.0
> APT prefers unstable
> APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Shell: /bin/sh linked to /bin/bash
> Kernel: Linux 2.6.18-3-amd64
> Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8)
>
> Versions of packages bashdb depends on:
> ii bash 3.1dfsg-8 The GNU Bourne Again SHell
> ii emacsen-common 1.4.17 Common facilities for all emacsen
>
> bashdb recommends no packages.
>
> -- no debconf information
>
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
