I can't reproduce this issue, the same patch that fixed the bug in Mandriva is applied in the Mageia package.

Could post a test case on how the bug happened?

Keywords: (none) => NEEDINFO

Also what's the output of 'env | grep HISTCONTROL'? executed as user

(In reply to comment #1)
> I can't reproduce this issue, the same patch that fixed the bug in Mandriva is
> applied in the Mageia package.
> 
> Could post a test case on how the bug happened?

Indeed, on the computer with which I work today, I have no problem. 
Friday I'll be back in my second home and I remake the tests.

(In reply to comment #3)
> (In reply to comment #1)
> > I can't reproduce this issue, the same patch that fixed the bug in Mandriva is
> > applied in the Mageia package.
> > 
> > Could post a test case on how the bug happened?
> 
> Indeed, on the computer with which I work today, I have no problem. 
> Friday I'll be back in my second home and I remake the tests.

I complete my answer:
I'm back 24 times in the history (up arrow) in a terminal.
I get the following line:
cd "`printf "%b" '\0057var\0057ftp\0057pub\0057personal\0057cauldron\0057i586\0057media\0057core\0137release'`"

Here is the result of the command env | grep HISTCONTROL :
HISTCONTROL=ignoredups

I think the problem has disappeared during one of the last update

I am not sure updates changed anything with this regard...

I do not quite understand myself either.

What is certain:
- The problem has existed on this machine.
- Today, it's gone

I'll watch the thing and I will post again if I have news

issue still present ?

Source RPM: (none) => mc

Yes the problem persists. But it is not systematic.
It breeds from time to time.
I have not been able to reproduce it intentionally.
I can not explain under what exact circumstances.
I think we should keep this report pending "NEED INFO"

ok, thanks for the reply.

I'm facing this problem too and I will provide as many info, as you guys need to fix this, because it brothers me a ton.
How can I help?

CC: (none) => zoltan.ilyes

I found that there is a problem if:
- I open a console first in order to execute a program
- I open a second console with mc

It has been several times that this happens

I know the problem does exist, as I have seen it myself.

It always seems to happen when I'm in the middle of something else,
and haven't paid attention to what I did leading up to it.

We need to figure out what combination of events leads to it, in
order to figure out exactly where the problem is, so it can be
fixed.  Until we figure out how to recreate the problem, in a
consistent manner, it will be hard to fix, let alone test a possible
fix.

CC: (none) => davidwhodgins

For me happens all the time. But i always open MC from Konsole ( I use KDE ), and almost always have more than one tab opened. I will run some test cases, but I don't know when, I won't have too much time @ weekend.

J' have note several times the operations that j' made to have the defect.

I work under Xfce, but I do not know if that has importance. 

1- I open a terminal. I make the update of my personal mirror with a script which uses rsync. 

2- While the update is done on the first terminal (that can last more than one hour), 
I open a second terminal. 
On this second terminal, I work with mc.

 I can now say that the defect is repetitive

Assigning to maintainer now that our maintainers database has an entry for
this package. Please assign back to bugsquad@mageia.org in case of a mistake
from me.

CC: (none) => stormi
Assignee: bugsquad => olav

What does 'movements' mean? All keyboard output is logged?

(In reply to comment #16)
> What does 'movements' mean? All keyboard output is logged?
Yes
in exemple :
cd "`printf "%b" '\0057var\0057ftp\0057pub\0057personal\0057cauldron\0057i586\0057media'`"
or
 PROMPT_COMMAND='pwd>&7;kill -STOP $$'

The problem is when I have two sessions with mc

cc'ing one of the committers because of the NEEDHELP on the whiteboard

CC: (none) => fundawang

Created attachment 2189 [details]
/root/.bash_history

This history begins in Mandriva. I copied .bash_history to a fresh Cauldron installation from 2010.2 while booted from openSUSE 11.4.

This problem is routine for me. I use MC both on ttys and in Konsole tab 2, and often have more than one MC session open. The problem began in Mandriva sometime after 2009 and before 2010.2. /root/.bashrc includes "shopt -s histappend; export PROMPT_COMMAND='history -s'; setterm -background blue -foreground white -bold -blank 59 -store". # env | grep HISTCONTROL -> HISTCONTROL=ignoredups. It doesn't happen in any openSUSE or Fedora with same .bashrc content.

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

The bug still exists in 2, but so does Cauldron: http://mirrors.kernel.org/mageia/distrib/cauldron/.

(In reply to comment #21)
> The bug still exists in 2, but so does Cauldron:
> http://mirrors.kernel.org/mageia/distrib/cauldron/.

Next time I'll try to choose better words :)

I wanted to use the time cauldron and Mageia 2 were frozen and identical, to get a new status on our cauldron bugs.

It has  been annoying for me to see open cauldron bugs from before Mageia 1, long after Mageia 1 was released and without any indication whether they were valid for Mageia 1 or for cauldron after Mga 1 release.

Whiteboard: NEEDHELP => NEEDHELP, MGA2TOO

I think I found the solution.
By searching on the internet, I discovered the variables HISTIGNORE and HISTCONTROL.

In reviewing my file.bash_history, I saw that the controls relating MC begin with a space.

So I added the line
export HISTCONTROL=ignorespace
in the ~ /. bashrc file

I think it is not useless to adding ignoredups, which gives:

export HISTCONTROL=ignorespace:ignoredups

I think this must be changed in /etc/skel/.bashrc to be generalized


This must be a valid for both mageia1 mageia2 and cauldron

We must also add in /root/.bashrc

(In reply to comment #23)
> So I added the line
> export HISTCONTROL=ignorespace
> in the ~ /. bashrc file
I used this workaround because I had that bug in mageia1 and after upgrade to mageia2 that still happened.

If that will work reliably I'm fine.

It has been one month since I use with succes this correction, on Mageia 1, on Mageia 2 and on cauldron.
I think that we can now correct the package in three versions.

(In reply to comment #26)
> It has been one month since I use with succes this correction, on Mageia 1, on
> Mageia 2 and on cauldron.
> I think that we can now correct the package in three versions.

@ Olav

WDYT?

Keywords: (none) => PATCH
Whiteboard: NEEDHELP, MGA2TOO => NEEDHELP, MGA2TOO, MGA1TOO

(In reply to comment #25)
> > So I added the line
> > export HISTCONTROL=ignorespace
> > in the ~ /. bashrc file
> I used this workaround because I had that bug in mageia1 and after upgrade to
> mageia2 that still happened.
> 
> If that will work reliably I'm fine.
Unfortunately it doesn't work. For user and root.

@ Filip

Did you add well the line 
export HISTCONTROL=ignorespace:ignoredups
in the .bashrc file of every user and root?

It is also necessary to add the line in /etc/skel/.bashrc 
to be applied during the creation of a new user.

@Georges
I did. I checked if it is SET too. It is. Strange is that other commands with leading space also go in .bash_history. So this workaround for me obviously can't work either.

But I didn't add ignoredups as you can see in comment #25. But I think it's not needed.

(In reply to comment #30)
> @Georges
> I did. I checked if it is SET too. It is. Strange is that other commands with
> leading space also go in .bash_history. So this workaround for me obviously
> can't work either.
It is effectively strange.
My low skills do not allow me to help you.

> 
> But I didn't add ignoredups as you can see in comment #25. But I think it's not
> needed.
Ignoredups is not indispensable. It is simply interesting to eliminate copies.

Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D

(In reply to comment #32)
> @ the reporter and persons in the cc of this bug:
 
> If you have any new information that wasn't given before (like this bug being
> valid for another version of Mageia, too, or it being solved) please tell us.
 
Since this bug actually predates the existence of Mageia (inherited from Mandriva), the likelihood that it magically disappeared in Cauldron after 2 was released is extremely remote.

(In reply to comment #32)

From my part, I made a new test with a new installation.
Environment: Xfce 4.10 with cauldron.

Without correction, the problem persists.
But the correction which I make is effective.

(In reply to comment #28)
> (In reply to comment #25)
> > > So I added the line
> > > export HISTCONTROL=ignorespace
> > > in the ~ /. bashrc file
> > I used this workaround because I had that bug in mageia1 and after upgrade to
> > mageia2 that still happened.
> > 
> > If that will work reliably I'm fine.
> Unfortunately it doesn't work. For user and root.

I rechecked again why this doesn't work here for user and root:
$set | grep HISTC
HISTCONTROL=ignoredups

Reason for that lied in /etc/profile.d/95bash-extras.sh which has line HISTCONTROL=ignoredups.

I updated it with ignorespace and I'll test again.

This behaviour seems intentional. See mc FAQ[1]:
</quote>
    6.8 I see lot of strange 'cd "printf ' lines into my .history file

    Add export HISTCONTROL="ignoreboth" into your ~/.profile file (.bash_profile) for avoid this.
</quote>


After last bash update[2] in the end of july file /etc/profile.d/95bash-extras.sh was modified again (see comment #35) to HISTCONTROL=ignoredups and this reappeared. After setting this back to HISTCONTROL=ignorespace this has stopped for me.

As far as I'm concerned we can close this bug. It would be nice if bash upgrade would respect HISTCONTROL state or at least notify us about that as I have seen with other updates. I'm talking about rpmnew differences dialog.


[1] https://www.midnight-commander.org/wiki/doc/faq#a6.8Iseelotofstrangecdprintflinesintomy.historyfile
[2] bash-4.2-5.1.mga2.i586.rpm

For my part, I am always obliged to make the correction, because /etc/profile.d/95bash-extras.sh do not correct any more.

I thus think that the problem remains with mageia 2.

@Georges

Sorry. I don't understand you fully. Can you explain once more what goes on with your file /etc/profile.d/95bash-extras.sh?

So basically output of "$set | grep HISTCONTROL" changes over time. When exactly?

Did you already try solution from comment #36? What are the results?

I have just made a quite new installation of the xfce desktop (But I think that xfce is unimportant), with some utilities, of which mc.

The file /etc/profile.d/95bash-extras.sh contains "export HISTCONTROL=ignoredubs", but not "export HISTCONTROL=ignorespace"
$ set -> HISTCONTROL=ignoredubs
bash_history -> with cd print...

I then realized several tests:
1) I add "export HISTCONTROL=ignoreboth" -> ~/.bash_profile
  $ set -> HISTCONTROL=ignoredubs
  bash_history -> with cd print...

2) I add "export HISTCONTROL=ignorespace" -> ~/.bash_profile
  $ set -> HISTCONTROL=ignoredubs
  bash_history -> with cd print...

3) I add "export HISTCONTROL=ignoreboth" -> ~/.bashrc
  $ set -> HISTCONTROL=ignoreboth
               _HISTCONTROL=
  bash_history -> without cd print...

4) I add "export HISTCONTROL=ignorespace" -> ~/.bashrc
  $ set -> HISTCONTROL=ignorespace
               _HISTCONTROL=
  bash_history -> without cd print...


In summary,
- Lines added in bash_profile are ignored
- In bashrc, lines ignoreboth and ignorespace work

I think I know why some people are able to replicate this bug and others are not.

According to this bug report
https://www.midnight-commander.org/ticket/2830
Exiting mc with F10 causes the bash_history to be written, while if exiting by closing the terminal window bash_history is not written.


For me changing /etc/profile.d/95bash-extras.sh to set HISTCONTROL=ignoreboth works OK


To test I modify etc/profile.d/95bash-extras.sh , erase ~/.bash_history, Log out, Log in, open a terminal, run mc exiting with F10, view ~/.bash_history

CC: (none) => derekjenn

I return to this bug, after installation mga3. (I am at present with IceWM)
For me bash_history registers as well by closing with F10 that by closing the terminal. But I believe that this has no big importance.

The important is that for me too, changing /etc/profile.d/95bash-extras.sh to set HISTCONTROL=ignoreboth works OK

I pushed to cauldron an updated mc with a patch by Derek.
Please test if it fixes the issue. If it does, we can consider providing an update for mageia 2 and 3.

Status: NEW => ASSIGNED
CC: (none) => pierre-malo.denielou
Assignee: olav => derekjenn

Having, at present, a problem of installation of cauldron, I tested the package with a new installation of Mageia2.

For me, it works correctly

SRPMS  mc-4.8.7-2.1.mga3.src.rpm
       mc-4.8.1-2.1.mga3.src.rpm  

RPMS  mc-4.8.7-2.1.mga3.i586.rpm
      mc-4.8.7-2.1.mga3.x86_64.rpm
      mc-4.8.1-2.1.mga3.i586.rpm
      mc-4.8.1-2.1.mga3.x86_64.rpm

packages for testing are in mga2 and mga3 core/updates_testing

Advisory
--------
This is a bugfix update for midnight commander (mc). It corrects a bug which allowed the bash history to fill up with mc internal commands.






Info for QA
------------
The ~/.bash_history file records all the commands you type. It is useful because if you use the up/down buttons on the keyboard you can quickly call up an old command.  mc corrupts the history by filling it up with useless internal commands.

Test Procedure
-------------

Install mc from core/updates/testing

Before starting it give the command
$ echo $HISTCONTROL
observe the response is 'ignoredups'

Now start mc. While in mc give the  same command again
 echo $HISTCONTROL

The response will not be visible yet because it is behind the display of mc. Exit mc with F10 (If you are using Gnome terminal the F10 button will not work. You will have to use the mouse to click on F10)

Observe the output from the last command is now visible
$ echo $HISTCONTROL
ignoreboth

The correct response is 'ignoreboth' which confirms that bash will not log mc internal commands

Finally confirm mc is working normally by using it as a file manager. (Hint - Use the TAB key to switch panes and look at what the function keys do)

If you use mc to examine the file ~/.bash_history  you can confirm that the history is not filling up with rubbish commands.  (Note the history is only written when mc exits cleanly with F10)

Assignee: derekjenn => qa-bugs

Thanks for the nice advisory Derek, I think some were meant to be mga2, can you check these are correct please.

SRPMS  mc-4.8.7-2.1.mga3.src.rpm
       mc-4.8.1-2.1.mga2.src.rpm  

RPMS  mc-4.8.7-2.1.mga3.i586.rpm
      mc-4.8.7-2.1.mga3.x86_64.rpm
      mc-4.8.1-2.1.mga2.i586.rpm
      mc-4.8.1-2.1.mga2.x86_64.rpm

(In reply to claire robinson from comment #45)
> Thanks for the nice advisory Derek, I think some were meant to be mga2, can
> you check these are correct please.
> 
> SRPMS  mc-4.8.7-2.1.mga3.src.rpm
>        mc-4.8.1-2.1.mga2.src.rpm  
> 
> RPMS  mc-4.8.7-2.1.mga3.i586.rpm
>       mc-4.8.7-2.1.mga3.x86_64.rpm
>       mc-4.8.1-2.1.mga2.i586.rpm
>       mc-4.8.1-2.1.mga2.x86_64.rpm

Yes your list is correct. I must be more careful checking suffixes :-)

Testing complete mga3 64

Confirmed 'ignoreboth' and that it returns to 'ignoredups' when quit.
Confirmed that it no longer fills ~/.bash_history and seems to work as it should.

Well done :)

Whiteboard: MGA2TOO => MGA2TOO mga3-64-ok

Testing complete mga3 32

Whiteboard: MGA2TOO mga3-64-ok => MGA2TOO mga3-64-ok mga3-32-ok

Testing complete mga2 64

Whiteboard: MGA2TOO mga3-64-ok mga3-32-ok => MGA2TOO mga3-64-ok mga3-32-ok mga2-64-ok

Testing complete mga2 32

Ok for 'ignoreboth' and that it returns to 'ignoredups' when quit.
Ok for that it no longer fills ~/.bash_history and seems to work as it should.

CC: (none) => geiger.david68210

Tested on Mag2 32Bit ok
Ok for 'ignoreboth' and that it returns to 'ignoredups' when quit.
Arrow completion in seperate konsole and in the tab after MC was closed does not show mc history.

CC: (none) => led43john

Validating. Advisory from comment 44 & 45 uploaded.

Could sysadmin please push from 2 & 3 core/updates_testing to core/updates

Thanks!

Keywords: (none) => validated_update
Whiteboard: MGA2TOO has_procedure mga3-64-ok mga3-32-ok mga2-64-ok mga2-32-ok, mga2-32bit-OK => MGA2TOO has_procedure mga3-64-ok mga3-32-ok mga2-64-ok mga2-32-ok
CC: (none) => sysadmin-bugs

http://advisories.mageia.org/MGAA-2013-0051.html

Status: ASSIGNED => RESOLVED
CC: (none) => boklm
Resolution: (none) => FIXED

Without [mc] in summary this Bugzilla is too broken to find midnight commander bugs that do not also find an overabundance of unrelated bugs:
mcc
memcache
nmcli
pcmcia
spamc
systemctrl
systemctl
tomcat
xbmc
xdmcp

Summary: The bash history records all movements with mc (midnight commander). => [mc] The bash history records all movements with mc (midnight commander).