Menu

#124 Timestamps appear as history commands

closed
nobody
2015-02-17
2015-02-12
Anonymous
No

Originally created by: nkoester
Originally owned by: dvorka

When changing the history format as in

HISTTIMEFORMAT='%F %T'

the content of a .bash_history looks like this

[#1423741350]
echo "x"
[#1423741355]
echo "y"

Issue: hstr will put the timestamp entries as previous history commands. E.g:

nkoester@calcit$ 
Type to filter, UP/DOWN move, DEL remove, TAB select, C-f add favorite, C-g cancel
- HISTORY - view:ranking (C-/) - match:exact (C-e) - case:insensitive (C-t) - 17/20/1 ------------------------------------------------
 [#1423741893]
 [#1423741355]
 [#1423741350]
 echo "y"
 echo "x"
 [#1423741141]
 [#1423741139]

The manpage says:


HISTTIMEFORMAT
If this variable is set and not null, its value is used as a format string for strftime(3) to print the time stamp associated with each history entry displayed by the history builtin. If this variable is set, time stamps are written to the history file so they may be preserved across shell sessions. This uses the history comment character to distinguish timestamps from other history lines.

Maybe its a good idea to support the genereal history comment character "#" and therefore allow timestamped histories.

A further addition could be to add a date prefix possibility in hstr view?

Related

Tickets: #120
Tickets: #128

Discussion

  • Anonymous

    Anonymous - 2015-02-12

    Originally posted by: dvorka

    Thank you for the comprehensive bug report! I think that I will have to check HISTTIMEFORMAT variable first and the decide how to process the history (most probably I will parse out the command).

     
  • Anonymous

    Anonymous - 2015-02-12

    Originally posted by: nkoester

    I don't think you have to check the variable. The history will always save the timestamp format and only use the variable content to print it.

    Of course it's nice to have the same format in a hstr time prefix as described in $HISTTIMEFORMAT, but simply removing the # TIMESTAMP entries should always be the same and variable indipendent?

     
  • Anonymous

    Anonymous - 2015-02-12

    Originally posted by: dvorka

    Got it - you are right. Striping all the ^#1423772846$ lines should be just fine.

     
  • Anonymous

    Anonymous - 2015-02-12

    Ticket changed by: dvorka

    • status: open --> closed
     
  • Anonymous

    Anonymous - 2015-02-13

    Originally posted by: livibetter

    @dvorka I was trying c69ee8559320872d2eb95fbe8f36ff85a2c69356, waiting to try {} regrex, but got this error:

    hstr_utils.c: In function 'isZshParentShell':
    hstr_utils.c:148:5: error: unknown type name 'pid_t'
         pid_t parentPid=getppid();
         ^
    

    I checked with man getppid, it listed the inclusions of:

    #include <sys/types.h>
    #include <unistd.h>
    

    I added them to hstr_utils.c, which made the compilation successful.


    That line of regex can be as simple as just:

    // HISTTIMEFORMAT defined > ^#1234567890$
    const char *histtimeformatTimestamp = "^#[[:digit:]]\\{10,\\}$";
    

    If you want me to submit a PR, I could do that, by the way I also noticed a couple of warnings:

    hstr_utils.c:151:5: warning: passing argument 1 of 'free' discards 'const' qualifier from pointer target type [enabled by default]
         free(cmdline);
         ^
    In file included from include/hstr_utils.h:14:0,
                     from hstr_utils.c:10:
    /usr/include/stdlib.h:483:13: note: expected 'void *' but argument is of type 'const char *'
     extern void free (void *__ptr) __THROW;
                 ^
    
    hstr_history.c: In function 'get_prioritized_history':
    hstr_history.c:132:15: warning: 'line' may be used uninitialized in this function [-Wmaybe-uninitialized]
                 if(line && strlen(historyList[i]->line)>itemOffset) {
                   ^
    

    Using:

    % gcc --version
    gcc (Gentoo 4.8.3 p1.1, pie-0.5.9) 4.8.3
    
     
  • Anonymous

    Anonymous - 2015-02-13

    Originally posted by: dvorka

    My apologies for pushing changes too early and thank you @livibetter for all the suggestions! I just pushed stable version with your regexp optimization included.

     
  • Anonymous

    Anonymous - 2015-02-16

    Originally posted by: livibetter

    The commit 92cfb0f seems to cause segfault when switching to view:history, up to the latest 3e1edfc9d9aa54ac789dbed99b0ecfc55aba879c, with the following history:

    #1234567890
    foobar
    

    With the above, invoke hh, press [Ctrl+/] to switch and 'Segmentation fault' is printed out immediately.

     
  • Anonymous

    Anonymous - 2015-02-17

    Originally posted by: dvorka

    Reproducible - opening new defect.

     

Log in to post a comment.