Re: turning on file+line for functions with shopt -s extdebug gives error
On 2/27/19 4:19 PM, L A Walsh wrote: >>> Are they defined "somewhere"? Maybe a short note as to what they >>> are might be added to the manpage where the terms are used (under >>> description of shopt+extdebug)? >>> >> >> They're described in the FUNCTIONS section, since they affect function >> behavior... >> >> 5. Function tracing is enabled: command substitu- >>tion, shell functions, and subshells invoked with >>( command ) inherit the DEBUG and RETURN traps. >> 6. Error tracing is enabled: command substitution, >>shell functions, and subshells invoked with ( >>command ) inherit the ERR trap. >> >> To be clear, you're suggesting that I add something to the `extdebug' >> section to explain how these features can be enabled separately from >> `extdebug'? > > > Not exactly, just that "set -o func/errtrace and -T/-F are under "set". > > A "forward pointer" to the behavior described under 'shopt-extdebug' > would be useful. If you are reading from top to bottom, something > under "set-T" saying: > > "SEE ALSO, behavior description under 'shopt-extdebug', below" Why? The description of the behavior is identical in both cases. If anything, the description of extdebug should note that it is possible to get the functrace and errtrace behaviors independently, and that's a back reference. >More important than the doc forward-definition suggestion, is the > ability for bash to toggle behaviors independent of invoking the > debugger (From (On 2/26/2019 4:26 PM, L A Walsh wrote:), reposting:) > > The part about turning on filenames+line numbers for function definitions > is in bash. If those aren't on, the debugger can't find them. BASH_SOURCE and BASH_LINENO are available even when the debugger is not running, as is the `caller' builtin. The declare -F stuff is not, but I don't see that as generally useful outside the debugger. > Also, the desire to retain the original source format of code is another > "in bash" issue. Perhaps it could be tied or related to the turning on > of function definition locations. The debugger goes back to the original source file to find the function definitions, doesn't it? It's wasteful and not particularly useful to have the function definition text stored internally when you can regenerate an equivalent form from the compiled function definition. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: history -a misbehaves with $HISTSIZE
On 2/28/19 5:53 PM, Айрат Васбикарамов wrote: >> It seems like what you want is min(history_lines_this_session, >> history_offset), >> kind of like what you say below. Try the attached patch and see if it >> does what you want. > > Yes, that's what I mean. > >> I don't think this would happen too much in practice, though, because if >> you wait until you have more than $HISTSIZE history entries, you'll lose >> information no matter what you use. > > I don't think that happens frequent either. But it's possible. Someone set > HISTSIZE to 1000 as he don't care about too old commands and it's happened > that he typed more than 1000 command. Then he run "history -a" to synchronize > current history with another started bash for example. And lost recent > commands. Possibly he notice it. But may not. > > Anyway I don't see downsides of this behavior comparing to current. And it > seems more intuitive to me. So should it be default? It's in the devel branch. Try it and see if it does what you want. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Simple exit trap doesn't run in newer versions of bash
> > (trap "echo WORKS" EXIT; touch x)
> > (trap "echo WORKS" EXIT && touch x)
> > bash -c 'trap "echo WORKS" EXIT; true'
> > bash -c 'trap "echo WORKS" EXIT; false'
> > bash -c 'trap "echo WORKS" EXIT; touch x && a'
> > bash -c 'trap "echo WORKS" EXIT; touch x; a'
> >
> > They all produce the output "WORKS" as the trap runs on exit. (Where "a"
> > is not a command or in the path and produces an error.)
> >
> > Now consider this command:
> >
> > bash -c 'trap "echo WORKS" EXIT && touch x'
> >
> > On newer versions of bash, it produces no output. Substituting different
> > commands in the trap or tracing it seems to indicate that the trap never
> > runs.
>
> It's a case of bash being too aggressive optimizing the last command in
> the AND_OR list. Here's a patch that disables that optimization attempt
> while I look at alternatives.
Here's a better patch that doesn't just disable the fork optimization. Please
let me know how it works in your testing.
Chet
*** ../bash-5.0-patched/command.h 2018-07-20 21:16:31.0 -0400
--- command.h 2019-02-20 11:09:36.0 -0500
***
*** 187,190
--- 188,192
#define CMD_LASTPIPE 0x2000
#define CMD_STDPATH 0x4000 /* use standard path for command lookup
*/
+ #define CMD_TRY_OPTIMIZING 0x8000/* try to optimize this simple command
*/
/* What a command looks like. */
*** ../bash-5.0-patched/builtins/evalstring.c 2018-12-26 11:19:21.0
-0500
--- builtins/evalstring.c 2019-01-29 14:15:19.0 -0500
***
*** 101,104
--- 101,113
}
+ int
+ can_optimize_connection (command)
+ COMMAND *command;
+ {
+ return (*bash_input.location.string == '\0' &&
+ (command->value.Connection->connector == AND_AND ||
command->value.Connection->connector == OR_OR ||
command->value.Connection->connector == ';') &&
+ command->value.Connection->second->type == cm_simple);
+ }
+
void
optimize_fork (command)
***
*** 106,110
{
if (command->type == cm_connection &&
! (command->value.Connection->connector == AND_AND ||
command->value.Connection->connector == OR_OR) &&
should_suppress_fork (command->value.Connection->second))
{
--- 115,120
{
if (command->type == cm_connection &&
! (command->value.Connection->connector == AND_AND ||
command->value.Connection->connector == OR_OR ||
command->value.Connection->connector == ';') &&
! (command->value.Connection->second->flags & CMD_TRY_OPTIMIZING) &&
should_suppress_fork (command->value.Connection->second))
{
***
*** 413,418
command->value.Simple->flags |= CMD_NO_FORK;
}
! else if (command->type == cm_connection)
! optimize_fork (command);
#endif /* ONESHOT */
--- 423,438
command->value.Simple->flags |= CMD_NO_FORK;
}
!
! /* Can't optimize forks out here execept for simple commands.
!This knows that the parser sets up commands as left-side heavy
!(&& and || are left-associative) and after the single parse,
!if we are at the end of the command string, the last in a
!series of connection commands is
!command->value.Connection->second. */
! else if (command->type == cm_connection &&
can_optimize_connection (command))
! {
! command->value.Connection->second->flags |=
CMD_TRY_OPTIMIZING;
! command->value.Connection->second->value.Simple->flags |=
CMD_TRY_OPTIMIZING;
! }
#endif /* ONESHOT */
*** ../bash-5.0-patched/execute_cmd.c 2018-12-05 09:05:14.0 -0500
--- execute_cmd.c 2019-01-25 15:59:00.0 -0500
***
*** 2768,2771
--- 2768,2773
(exec_result != EXECUTION_SUCCESS)))
{
+ optimize_fork (command);
+
second = command->value.Connection->second;
if (ignore_return && second)
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: turning on file+line for functions with shopt -s extdebug gives error
Date:Fri, 1 Mar 2019 11:00:41 -0500 From:Chet Ramey Message-ID: <91e964e9-a7e3-4f4e-ae9f-9ff3e3627...@case.edu> | It's wasteful and not particularly useful to have | the function definition text stored internally when you can regenerate an | equivalent form from the compiled function definition. I actually much prefer to see the shell regenerated form - if I want the original I have the sources, but seeing the shell "reverse compiled" form gives a different perspective to the code, and sometimes allows bugs to be made obvious which get hidden by the formatting of the original. kre
Please store source file name + line number for all functions defined whether or not bashdb is running.
On 3/1/2019 8:00 AM, Chet Ramey wrote:
> On 2/27/19 4:19 PM, L A Walsh wrote:
>
>
> BASH_SOURCE and BASH_LINENO are available even when the debugger is
> not running, as is the `caller' builtin.
They are available, but have the wrong information. Though for the current
line number shouldn't one use 'LINENO'? Example:
(with
PS4='>${BASH_SOURCE:+${BASH_SOURCE/$HOME/\~}}#${LINENO}${FUNCNAME:+(${FUNCNAME})}>')
>apply_patch#9> include stdalias
>>environment#0(include)> :
>>environment#0(include)> :
>environment#0(include)> [[ -n stdalias ]]
>>environment#1(include)> :
>environment#1(include)> local fnc=stdalias.shh
>>environment#2(include)> :
>environment#2(include)> [[ s == \/ ]]
Note that BASH_SOURCE does not show the name of the file you are
tracing through. Also, the line number is from the start of the function
that was called -- not from the start of the file.
At this point, the source and line of where the traced code comes from
(in bashdb as well) has been lost. The 'include' function is at line 427
in the file it is in -- not 0.
Furthermore, it appears the line numbers may be based on the "reconstituted
source" rather than the original source. Either way -- this is why I want
to be able to turn on storing of the definition from the beginning of the
login session.
If I add shopt -s extdebug at the beginning of /etc/profile, the correct
filename and line number are stored and displayed with '-F'.
As for storing the original source -- for the reasons above. As a
safety to allow the debugger to operate under adverse conditions.
Storing all of the
scripts in my bin and lib dirs (including duplicates) would cost about 10MB.
Cutting to ones with extensions cuts that to a bit over 100K. Compared
to the
memory on my machine, that's trivial if it gives access to the source
under the adverse conditions listed above.
But 1st, you need to realize that the BASH variables are just as "lost"
as bashdb. If source-file and line numbers of definitions are turned on
from the beginning of a login session, then no matter what function is
called, it will be known to bash -- and, thus, bashdb -- which can at least
try to read in the original source.
I.e. doc issues, and source issues aside, the real source+line numbers for
defined functions need to be kept from the start -- then a debugger has a
chance of finding things. As it stands right now, not even bash knows
where things came from 'environment'? functions always at line 0?
Naw...I don't think so.
Apart from source formatting, it would be infrequent that the source file
and line shown in "-F", would not be accessible -- at least the debugger
would
have a chance of using that info to display what is happening.
Thanks!
Linda
> The declare -F stuff is not,
> but I don't see that as generally useful outside the debugger.
>
>
>> Also, the desire to retain the original source format of code is another
>> "in bash" issue. Perhaps it could be tied or related to the turning on
>> of function definition locations.
>>
> The debugger goes back to the original source file to find the function
> definitions, doesn't it? It's wasteful and not particularly useful to have
> the function definition text stored internally when you can regenerate an
> equivalent form from the compiled function definition.
>
>
