Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Clint Hepner <clint.hepner@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: [FR] save command times and exit status in history automatically
Date: Thu, 7 Nov 2019 17:05:53 -0500
Lines: 67
Approved: bug-bash@gnu.org
Message-ID: <mailman.862.1573164364.13325.bug-bash@gnu.org>
References: <CAKOZuevfhS7veH9+GSc=8StpgrA_vy59Y2fYYGhMDk0OPZb69Q@mail.gmail.com> <8e19b0fc-4183-90fa-b067-9da636998d6f@case.edu> <CAKOZuevFuqrQhH75_-Dpum2VwmUkrP1r7E6b--v=Mg_EVHWuCw@mail.gmail.com> <B41DDB63-4A57-49AC-A3A9-A4752CC41D7D@gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: "bash.bug list" <bug-bash@gnu.org>
To: Daniel Colascione <dancol@google.com>
Envelope-to: bug-bash@gnu.org
In-Reply-To: <CAKOZuevFuqrQhH75_-Dpum2VwmUkrP1r7E6b--v=Mg_EVHWuCw@mail.gmail.com>
Precedence: list
Xref: csiph.com gnu.bash.bug:15575



> 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