bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [FR] save command times and exit status in history automatically


From: Clint Hepner
Subject: Re: [FR] save command times and exit status in history automatically
Date: Thu, 7 Nov 2019 17:05:53 -0500


> On 2019 Nov 7 , at 3:18 p, Daniel Colascione <dancol@google.com> wrote:
> 
> On Thu, Nov 7, 2019 at 12:09 PM Chet Ramey <chet.ramey@case.edu> wrote:
>> 
>> On 11/5/19 12:49 PM, Daniel Colascione wrote:
>>> Right now, bash history saves only the command line actually executed.
>> 
>> This isn't quite the case. What it saves is the line returned from
>> readline, before it's expanded or executed.
> 
> Fair enough.
> 
>>> Why not also, optionally, save command execution times and exit
>>> statuses? This information is practically free to collect.
>> 
>> Because by the time you gather this information, the command has already
>> been saved completely.
>> 
>> There have been various proposals to extend the timestamp with additional
>> information, but it's all data you can gather when the timestamp is saved
>> before the command is executed.
> 
> That's how history works today, yes. I'm wondering whether it'd be
> possible to maintain an auxiliary history that included not only the
> command lines read, but also their execution time and outcome. Doing
> something in PROMPT_COMMAND doesn't seem quite accurate. Maybe what I
> really want is something like $?, but instead of containing exit
> status, it would contain information from a struct rusage (derived
> from wait4) for the last command. Or something like that anyway. The
> larger point is that the shell could gather this information
> proactively almost for free and I don't think user code running in
> existing shell extension points can do the same job.
> 

Conceptually, this is quite a leap. Right now, the history list doesn't
require *any* effort beyond logging the input. What you are suggesting
may be readily accessible, but it's still *additional* work that must be
done.

Furthermore, a few issues off the top of my head:

* How would handle background jobs? Would they appear in the order they
are started, or the order they are completed?

* Suppose I start a loop like

   for x in 1 2 3; do
     someCommand "$x"
   done

  Do you want to store the result of the for loop? Each of the commands run
  in the loop? What would that look like?

* Would you want some way of linking the result of a `wait -n` command with
  the command it waited for? What would that look like?

* Would you want to store *any* output from a command in your log?

I think the design of such a feature would require a lot of careful thought
to be useful.

--
Clint




reply via email to

[Prev in Thread] Current Thread [Next in Thread]