Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15575 > unrolled thread

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

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [FR] save command times and exit status in history automatically Clint Hepner <clint.hepner@gmail.com> - 2019-11-07 17:05 -0500

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

> 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

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web