In Kubuntu 20.04, bash 5.0.17, since some days I have various problems to write working bash scripts. Now I found that bash is faulty. E.g. after keyword "export" a name or any characters are ignored, so that the list is printed as if no name given or option -p given.
In searching for the cause I have called dmesg as follows:
dmesg -s $((10*1024*1024)) -T | less +G
1986 lines were output.
Usual my dmesg output is a great deal longer and begins at the very beginning with some lines that shows its at beginning and its at boot time.
But this dmesg output begins with following lines:
+++++
[Wed Jan 12 03:07:46 2022] microcode: microcode updated early to revision 0x28, date = 2019-11-12
[Wed Jan 12 03:07:46 2022] Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 (Ubuntu 5.4.0-42.46-generic 5.4.44)
[Wed Jan 12 03:07:46 2022] Command line: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/kubuntu.seed maybe-ubiquity persistent splash ---
[Wed Jan 12 03:07:46 2022] KERNEL supported cpus:
[Wed Jan 12 03:07:46 2022] Intel GenuineIntel
[Wed Jan 12 03:07:46 2022] AMD AuthenticAMD
[Wed Jan 12 03:07:46 2022] Hygon HygonGenuine
[Wed Jan 12 03:07:46 2022] Centaur CentaurHauls
[Wed Jan 12 03:07:46 2022] zhaoxin Shanghai
[Wed Jan 12 03:07:46 2022] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[Wed Jan 12 03:07:46 2022] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
I have run ClamAV on this device; on this device no virus found.
Does this dmesg output realy mean that microcode was changed while OS is contunuously running ?
Is it possible that indeed a microcode upgrade on my computer is possible silently ?
Regards antondhidh
=====
I have to add:
a)
type -a export yields
export is a shell builtin
b)
I have four virtual desktops. In one of the virtual desktops the terminal emulator "konsole" is running.
Under this konsole eight windows, in each window one bash shell.
All these eight shellls bash behave same faulty.
c)
If in a unused desktoo I call ALT-F2 to execute a command, the shell is same faulty.
d)
If I use one of the basic terminals tty1..tty4, which are direct and not under GUI and under "konsole" then bash shell is not faulty, my same code
export VAR
works normally.
e)
When in a unused GUI desktop I invoke "konsole" a bash is opened in a terminal for user kubuntu.
In this bash shell
export WEx1="111"
gives no error, and
declare -p WEx1
correctly shows
declare -x WEx1="111".
and
printenv | grep We
correcly shows
WEx1=111
When I create a subshell for root (as I always do) by
sudo su
With
export WEx2="222"
all is correct all the same as in the parent shell of user kubuntu.
f)
Now I see that this issue is to be subdivided into two parts:
1.
in a non-faulty bash, if one writes
export VAR
without an assignment like VAR="vvv" then VAR is not in printenv, but all other work with no error.
That is normal and that was not the reason of my question.
2.
the reason of my question was this erronious behavior:
if one writes
export abcd \<newline\>
then all between export and <newline> was ignored by bash so that bash printed the list
declare -x ...
declare -x ...
etc
as should be if after the keyword export no name was specified or the option -p given.
Regards antondhidh
=====
Two points have happened in the meantime, without any relevant action of myself: a bad one and a good one.
The bad one is:
Some of my 8 bash shells got a distinct failure, which is:
I have the bash history files saved in an USB stick in the directory
/media/WE_MNT_HISTFIL/.bash_history.WE-01
When I wrote
echo $HISTFILE
in the faulty shells the answer was
/media/ MNT HISTFIL/root/.bash_history
with 3 blanks and 1 blank instead of characters.
This is not only a matter of display, this is an internal problem.
Though various checks show that the directory on the USB stick has still the correct name, some internal applications do not work with this name.
E.g. FCEDIT is defined since long time as:
vim -u /media/WE_MNT_HISTFIL/root/.vimrc
and in the faulty shells this does no more work.
The remedy is: I have upon the first-level shell of user kubuntu always a child shell for user root.
I have to exit, kill this child shell and to invoke a new one.
But this lucks not on first attemp.
The good point is:
Now, in contrast to days ago, if under the same, old "konsole" I create an additional window by going with the mouse on one of the tabs of "Fensterleiste" and right click to get the context menue and choose "create new window", then the first and second level shells work correctly.
So I have a new set of shells created, and the histories and all my work tranfered to the new shells.
I am very happy not to need new boot.
Regards antondhidh
