0

I use bash v590 in Kubuntu 20.04 and KNOPPIX 9.1. In KDE under Konsole many Terminal Emulators xterm-256color are running, in each one a shell bash.

In such a shell a very long script is running sourced. And sometimes this script sources another script.

Over a few years all went well.

Now I am making some extensions. Thereby happened errors, basics erroneus behavior of bash.

Since very many days I am searching what of my code changes are the couse and what are the relationships.

The point is: what is written into the bash history list.

I have set HISTSISIZE to -1, HISTFILESIZE to number of seconds since epoche.

HISTCONTROL and HISTIGNORE I make unset.

At each test run, I list and set all bash "set" options and "shopt" options relevant to history.

It turned out that the (or one of the) implementation of

set -o history

is the key problem.

Perhaps even if I do not make setting but only an inquiry.

The mis-behavior of bash goes in two different directions:

Either nothing is written to the history list, only what I write by

history -s "abc"

Or all lines beginning with a hash ("#") instead to be taken as comment, are written to the history list.

And it depends on how often the code line

set -o history

exists.

E.g. if in the parent shell this is set and then a sourced script additionally brings such line in.

(as said: perhaps only for a request, if it is set or not)

I have googled in internet and can nothing find that relates to this.

Please, does someone know something about this.


== addendum_1 04.01.2023:

Very odd:

A:

In another of the existing terminals, one only for tests, at beginning shell bash showed the same mis-effects as described above.

Then I have in the parent shell turned off "history" by

set +o history

Thus

set -o | grep history

Shows that off.

In my test script, which is running sourced,

I additionally make

set +o history

Thus

set -o | grep history

Shows that off.

Now out-commented lines are no more written to bash history list.

And command "date" is written to history list.

i.e. behavior as it should be for setting history on by

set -o history

B:

In Konsole I create a new, an additional window with a terminal an shell bash.

set -o | grep history

Shows that on.

I use my test script. I do nothing regarding set .. history.

I run this script

set -o | grep history

Shows that on.

The test script writes normally, correctly commands into the histtory list, but not comments.

Now I change the test script: I add

set -o history

Now the mis-behavior occures: by hash character "#" out-commented lines are written into the history list, in addition to commands, e.g."date".

Not only the test script, but from then on the parent shell has also this mis-behavior.

Please, what is the couse and how can I repair the system.

I do not want to boot anew. KDE and his Konsole are not able to preserve all my settings. It was a hard work to make all settings for the windows and terminals under Konsole, and I have not yet found a way to store all my settings.


== addendum_2 04.01.2023:

Is there a way to check if bash will behave normally or will mis-behave before I run a long script, or at least at the beginning of the script.

Since when bash mis-behaves and writes the very many non-command lines into the history list, the history list is crammed full. And it is a hard work to find and delete thesse lines.

1
  • 1
    This question seems to be self-answered, but this question is really waaaay too long. It would be better for you to shorten and simplify it if there is any expectation of others being able to assist you here. Jan 15, 2023 at 15:42

1 Answer 1

0

For one of the two bad behaviors of bash in connection with

set -o history
set +o history

I have found a solution that works for me.

In some more details this means:

The one bad behavior is, that bash sometimes does not write commands to history list, though it should.

The other bad behavior is that sometimes bash writes out-commented lines to the history list as if they were commands. This seems to be controllable with HISTIGNORE.

For the first problem my approach is:

(1)

In a shell script make at beginning and other locations a test if test-commands had been written to history by reading back history lines with

history n

and

fc -l histindex_1 histindex_2

If comparision results in fault, then

(2)

In a for loop apply ten times

set +o history

And after checking apply once

set -o history

After that, for a certain, unknown time bash works correctly.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .