`info args` displays `$1 = /home/user/file.sh` for first line of debugged script

[jansorg]

When I run the debugger with any script:

./bashdb -L . /home/user/test.sh
info args

then info args displays this:

$1 = /home/user/test.sh

I'm not sure, but shouldn't this display an empty list?
The filename is never passed as first argument and displaying that there's a $1 with such value is confusing to uses

[jansorg]

When bashdb is invoked like above, is sourcing the debugged script, which makes the input arguments the path to the sourced file.

[rocky]

Personally, I am ambivalent about this.

In debuggers, two competing issues work at odds with one another. A Debugger can mask the true state of things to hide its appearance. That is often done when showing the state of the call stack. Some of the most recent frames that go into the debugger are hidden. I think there are cases when the debugger is called at the outset where we might also do this.

I think this is the principle that advocates for changing the behavior of "info args" here.

On the other hand, I want a debugger to be transparent as well. The reason this is shown as an argument is because that is how the mechanism works: the filename is an argument to a "source" command.

So an advantage of keeping things as they are right now is that it is apparent whether the debugger was called from the outset or was called from within the altered source. We could make that information available by more direct means though.

Since I don't have a strong feeling here - I don't use this enough where it would confuse me one way or other other, I am open to hiding the initial "source call" to see how it goes.

[jansorg]

Thank you for your input.
Let's keep info args as it is. I'll probably add a new info command and only call it for the script's top-level frame, which I should be able to detect in the frontend.

[rocky]

Thank you for your input. Let's keep info args as it is. I'll probably add a new info command and only call it for the script's top-level frame, which I should be able to detect in the front end.

The gdb command show args seems to be the closest to what you describe.

[jansorg]

I think the underlying problem is that currently no command can show the current values of $@, $1, ...

For a script

echo "$@"
shift
echo "$@" # <- breakpoint here

none of "info variables", "info args" or "show args" displays the updated value of $@.

I guess that gdb is different here because an "info variables" is (probably) not excluding special variables like Bash and would show re-assignments to parameters.

In Bash "info variables" excludes $@, because "typeset -p" excludes them AFAIK.

"info args" only displays the initial values passed to the current frame. The output does not change after a "shift".

"show args" prints the values passed to the script and doesn't change after a shift in the top-level frame.

I'm currently testing BashSupport-Pro@0c3a385#diff-04f0a93571f0a3df4198cce8525ffe18de186469c96497fd293e604a4f20e58cR34 as alternative.
But it's only a workaround.

Thoughts or ideas how to treat $@, perhaps?

[rocky]

If the debugger was called at the outset, i.e. then save $@ at the outset around https://github.com/Trepan-Debuggers/bashdb/blob/bash-5.2/bashdb.in#L105