2

The problem context:

  • always active ignoreboth and erasedups
  • HIST_SIZE and FILESIZE with desired/practical limits of different history lines for our user
  • almost always have multiple parallel sessions and (commonly) nested sessions¹

Expected behavior:

  • after closing any session and reopening other(s), there should be no duplicates on the history of any session.

  • we don't need to close all sessions before openning another

  • active sessions' histories must not be affected by other running/closed sessions (so that option to a single history for all is not a solution)

  • new sessions, on the other hand, should (naturally) have history lines of all sections closed before the time it open (but without dups, of course)

Behavior:

  1. Start a session without any other parallel sessions in some machine

  2. Assume a saved history² with these last 3 lines:

    ./reference-point  # anything, just to use as a reference
    ls
    la
    ll
    
  3. Start a nested session (ssh or even a bash command, also to be kept on history). I'll do a simple:

    ssh machine
    
  4. Make 3 commands, at least one time each, and on a possibly different order. For example:

    ll
    ls
    la
    ll
    
  5. Our last 4 lines should be:

    ./reference-point  # anything, just so we know
    ls
    la
    ll
    
  6. Now we close this session (with CTRL+D or anything not kept on history). Now, on our first session, our 5 last lines should be:

    ./reference-point  # anything, just so we know
    ls
    la
    ll
    ssh machine
    
  7. Close this session (which is the only active session right now)

  8. Start another session and check the last 10 history lines:

    ./reference-point  # anything, just so we know
    ls
    la
    ll
    ls
    la
    ll
    ssh machine
    

This example makes history dups stick near each other. But the practical uses, of course, would not make. The bad side effect is that history size cannot be guessed from the configuration we can use. Further, the behaviour is clearly wrong.

What can I do to solve it, or (at least) to gently deal better with this issue, besides increasing a LOT more than I wanted my "HIST*SIZE" config?


Some notes I would like to make:

This bug is very old, and I don't know anyone who has come with a real solution for it. And, for my specific case, there could be problem or little "catches" with some solutions given around the web.

This issue has been reported on Savannah in 2014. But it seems that nobody there have even read it until today. You may check it (and, maybe be, even make some useful comment there too, since it's an official place for Bash).

--

¹ nested sessions are necessary for me, and should be very common. For example: ssh to closed network access machine, and after that login again to one or more machines (in parallel sessions, also common)

² to check history lines without affecting kept commands, you can use 'ignoreboth' Bash config and just do a " history 10" (note the space before the command!) or similar. I used this to make the test while writing this question.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.