-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Save more file information from initial call... #56
Save more file information from initial call... #56
Conversation
4a499ba
to
f41e58a
Compare
In particular, resolve the initial source directory and store that as _Dbg_init_dir. Resolve the name of main bash program and add that to canonicalized filenames.
f41e58a
to
3838e65
Compare
@rocky Thank you, this is fixing the problem! I've attached a screenshot of my session. |
Co-authored-by: Joachim Ansorg <[email protected]>
Co-authored-by: Joachim Ansorg <[email protected]>
Co-authored-by: Joachim Ansorg <[email protected]>
Thanks for checking and the changes. I will try to look at and address this problem over the weekend. |
@jansorg When I went to look at this over the weekend the image was missing. Would you upload it again or give a sequence of instructions?
The key issue is that the "break" command is not finding the file when using a relative path. As you report, using an absolute path works fine. |
In some cases though automatic file loading no longer happens. In particular, on "list" and "break" commands.
@jansorg with 896a12f the example you give now works. However, this also disables the automatic file loading of files with relative file names not previously encountered. Instead, you must specify an explicit "load" here. The automatic loads of relative file names happened in the "list" and "break" commands. With this change, you will get an "internal error" message instead. Addressing that will take more work and effort. I am not sure though it is that important. What do you think? |
I'll be able to test your changes end of this week. Thank you for looking into this! No automatic loading of relative paths seems okay to me, unless I misunderstood what how it works. |
lib/fns.sh
Outdated
@@ -197,6 +197,9 @@ function _Dbg_linespec_setup { | |||
typeset -ri is_function=${word[1]} | |||
line_number=${word[0]} | |||
full_filename=$(_Dbg_is_file "$filename") | |||
if [[ -z "$full_filename" ]] ; then | |||
full_filename=$(_Dbg_resolve_expand_filename "$filename") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is quoting needed here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested with quoting and it doesn't seem to hurt. Personally, I find the quotes within quotes confusing, and more generally the multiple substitution passes weird, but this is bash after all.
So I've now made the change.
In stepping, the debugger may encounter relative paths in BASH_SOURCE. It turns these into absolute paths and saves the mapping as soon as possible, to avoid the problem of the current working directory changing inside the debugged program. So in that respect, the auto conversion always happens, and has to happen. In addition, a user can issue debugger commands like "list" or "break" fabricating any name the user wants. It is here that I guess we hitting places where we are not converting the filename to its full name or storing canonical information about the file. |
I've tested your branch and as far as I can tell, it's working great! Thank you for fixing this problem! |
In particular, resolve the initial source directory and store that as _Dbg_init_dir. Resolve the name of main bash program and add that to canonicalized filenames.
@jansorg I think this fixes the second problem you mentioned in #50 Please double check though.