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:


type -a export yields

export is a shell builtin


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.


If in a unused desktoo I call ALT-F2 to execute a command, the shell is same faulty.


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.


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".


printenv | grep We

correcly shows


When I create a subshell for root (as I always do) by

sudo su


export WEx2="222"

all is correct all the same as in the parent shell of user kubuntu.


Now I see that this issue is to be subdivided into two parts:


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.


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 ...


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


When I wrote


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

  • It is difficult to understand what the problem is. You seem to have multiple questions, one about dmesg and microcode updates, the other about how she’ll variable exports work. Also, you give very little details about the actual issue.
    – jsbillings
    Mar 5, 2022 at 12:47
  • Please put code and commands in the appropriate tags when editing your question. Mar 5, 2022 at 13:54


You must log in to answer this question.

Browse other questions tagged .