http://www.midnight-commander.org/ticket/2985

Keywords: (none) => UPSTREAM

This bug does not appear for me in any Fedora or openSUSE release using MC up through v4.8.9, the latest available and installed there.

I had the same problem, so I added:

 . ${HOME}/.bashrc

to /etc/mc/mc-bashrc and my aliases worked in mc again.

Not a proper fix. Should probably check to see is home is set and is a valid user directory.

CC: (none) => warrendiogenese

OK, I am able to reproduce this bug: after I added:

alias foo='echo foobar'

to ~/.bashrc , I cannot use it inside an mc session and the command "alias | less" displays a partial selection of the aliases I have at a normal shell.

Regards,

-- Shlomi Fish

I can reproduce it as well.  I thought perhaps mc was using login shells (which don't run .bashrc), but I sourced .bashrc from .bash_profile, and that doesn't work either.  I suspect that mc is starting its shells in some non-standard manner that doesn't run the normal bash user scripts.  If you look in /etc/mc you'll find things like mc-bashrc, which suggests this.

Also, if you start mc in one terminal, and from another execute "ps ax | grep bash", you'll see:

16717 pts/10   Ss+    0:00 bash -rcfile /etc/mc/mc-bashrc

and mc-bashrc contains:

# Start shells in midnight commander with bash
# history option set to ignoreboth
# Bug 1304

. /etc/bashrc

HISTCONTROL=ignoreboth

So, the problem is that mc-bashrc (which was added I think for bug#1304 ) doesn't source the user-level .bashrc, just the global one.

CC: (none) => ftg

Sure enough, if you add ". ~/.bashrc" to mc-bashrc following ". /etc/bashrc", the user alias then works.

(In reply to Frank Griffin from comment #6)
> Sure enough, if you add ". ~/.bashrc" to mc-bashrc following ".
> /etc/bashrc", the user alias then works.

Yes, here is what I discovered after some amount of investigation:

1. A GNU mc compiled from source with no downstream patches, does not exhibit this problem.

2. This mc does not source something like mc-bashrc.

3. The sourcing of mc-bashrc instead of the global "init_file" is caused by this patch:

# Patch by Derek Jennings to fix mga#1304 by spawning subshell with IGNOREBOTH
Patch3:         mc-4.8.8-mga-subshell.patch

Which reads:

<<<<<
--- src/subshell.c	2013-03-07 10:45:57.000000000 +0000
+++ src/subshell.c	2013-06-13 14:44:06.000000000 +0100
@@ -330,7 +330,8 @@
     switch (subshell_type)
     {
     case BASH:
-        execl (mc_global.tty.shell, "bash", "-rcfile", init_file, (char *) NULL);
+        /* Bug 1304 set HISTCONTROL=ignoreboth  */
+        execl (mc_global.tty.shell, "bash", "-rcfile", "/etc/mc/mc-bashrc", (char *) NULL);
         break;
 
     case TCSH:
>>>>>

Now, mc-bashrc only reads /etc/bashrc which is wrong, and it should also read .bashrc and maybe something else that exists in init_file (possibly ~/.mc/bashrc or something).

As noted this was done as a fix to Bug 1304 .

Regards,

-- Shlomi Fish

(In reply to William Murphy from comment #3)
> I had the same problem, so I added:
 
>  . ${HOME}/.bashrc

> to /etc/mc/mc-bashrc and my aliases worked in mc again.

This is not working for me.

(In reply to Felix Miata from comment #8)
> (In reply to William Murphy from comment #3)
> > I had the same problem, so I added:
>  
> >  . ${HOME}/.bashrc
> 
> > to /etc/mc/mc-bashrc and my aliases worked in mc again.
> 
> This is not working for me.

It was, and is now, but had been broken by updates overwriting my change to mc-bashrc.

It's not fixed in the rpm. I added the line back after the last update using the more conventional:

  . ~/.bashrc

Created attachment 4685 [details]
Patch to fix the problem.

This is a patch to fix the problem against "mgarepo checkout mc" :

<<<
shlomif[rpms]:$mageia/mc$ svn info
Path: .
Working Copy Root Path: /home/shlomif/Download/unpack/Mageia/mc
URL: svn+ssh://svn.mageia.org/svn/packages/cauldron/mc/current
Relative URL: ^/cauldron/mc/current
Repository Root: svn+ssh://svn.mageia.org/svn/packages
Repository UUID: 01bf705a-734c-4999-978a-dc8ab10ec44d
Revision: 563258
Node Kind: directory
Schedule: normal
Last Changed Author: luigiwalser
Last Changed Rev: 556375
Last Changed Date: 2013-12-11 23:14:10 +0200 (Wed, 11 Dec 2013)

shlomif[rpms]:$mageia/mc$ 
>>>

What it does is fix /etc/mc/mc-bashrc to also check for .bashrc if it is present, emulating the original mc behaviour.

Regards,

-- Shlomi Fish

Why isn't this fixed in package on mirrors yet? Current mc-4.8.11-1.mga4 is timestamped December 13. :-(

Hi Felix,

(In reply to Felix Miata from comment #12)
> Why isn't this fixed in package on mirrors yet? Current mc-4.8.11-1.mga4 is
> timestamped December 13. :-(

well, I think we have been on a freeze.

Regards,

-- Shlomi Fish

Surely this is a bug fix, not a new feature. Aliases in Fedora and openSUSE work while running MC, like they did once upon a time in Mandrake and Mandriva.

Hi Felix,

(In reply to Felix Miata from comment #14)
> Surely this is a bug fix, not a new feature. Aliases in Fedora and openSUSE
> work while running MC, like they did once upon a time in Mandrake and
> Mandriva.

yes, it is indeed a bug fix. Hopefully, we can provide an update for both Mageia 3 and Mageia 4.

To keep this from recurring I keep having to set my /etc/mc/mc-bashrc files immutable. If this doesn't get fixed soon, I'll probably never be able to notice if or when a fix occurs. Why does this unique to Mageia bug seem to be a problem to eradicate? Why does Mageia even need /etc/mc/mc-bashrc, which neither of Factory nor Rawhide have by default?

(In reply to Shlomi Fish from comment #15)
> Hi Felix,
> 
> (In reply to Felix Miata from comment #14)
> > Surely this is a bug fix, not a new feature. Aliases in Fedora and openSUSE
> > work while running MC, like they did once upon a time in Mandrake and
> > Mandriva.
> 
> yes, it is indeed a bug fix. Hopefully, we can provide an update for both
> Mageia 3 and Mageia 4.

I sent updates to Mageia 3 core/updates_testing and to Mageia 4 core/updates_testing with the patch. Please test.


Suggested advisory:
========================

Updated mc package fixes Bug #11015 where mc ignored ~/.bashrc .

References:
https://bugs.mageia.org/show_bug.cgi?id=11015
========================

Updated packages in core/updates_testing:
========================
***]]]!!! Will be added later after an easy way to get this list from http://pkgsubmit.mageia.org/ will be mentioned in https://wiki.mageia.org/en/Updates_policy . Please add it there (!).

mc-4.8.11-2.mga4.x86_64.rpm tested on Mageia 4 64-bits. The problem described is solved here.

CC: (none) => olivier.delaune

Shlomi, please assign this to QA if it's OK to release.

Version: Cauldron => 4
Assignee: bugsquad => shlomif

(In reply to David Walser from comment #19)
> Shlomi, please assign this to QA if it's OK to release.

Assigning to QA. SRPMs are mc-4.8.11-2.mga5.src.rpm RPMs for x86_64 are:

mc-debuginfo-4.8.11-2.mga5.x86_64.rpm
mc-4.8.11-2.mga5.x86_64.rpm

Assignee: shlomif => qa-bugs

Note when testing mc, you have to hit Ctrl-O to actually see the output of the commands you run in the command line.

Verified the bug and the fix on Mageia 4 i586.

Validating.  Could someone please upload the advisory?

Sysadmins, once the advisory is uploaded, please move to core/updates.  Thanks.

Keywords: (none) => validated_update
Whiteboard: has_procedure MGA4-64-OK => has_procedure MGA4-32-OK MGA4-64-OK
CC: (none) => sysadmin-bugs

(In reply to David Walser from comment #21)
> Note when testing mc, you have to hit Ctrl-O to actually see the output of
> the commands you run in the command line.

Not true. If you change the inane default never for pause after run to always, output will stay visible until striking a key.

I'm only using Cauldron any more, where this is fixed since about a month or so ago.

Unvalidating, this is also an update for Mageia 3.


SRPMS (RPMs are the same):

mc-4.8.7-3.1.mga3
mc-4.8.11-2.mga4


Note to Shlomi: it seems you made a mistake when bumping the release for these updates. By policy, the "Release" should be left as it is in Core Updates and you should define a "subrel" (with %define subrel 1), which is the one to increment for updates.
So the packages should have been mc-4.8.7-2.2.mga3 and mc-4.8.11-1.1.mga4.

Since the mga4 packages have already been tested, it's not worth changing it now IMO, but please keep this in mind for your next update.

Keywords: validated_update => (none)
Source RPM: mc => (none)
Whiteboard: has_procedure MGA4-32-OK MGA4-64-OK => MGA3TOO has_procedure MGA4-32-OK MGA4-64-OK

s/Core Updates/Core Release/

Advisory uploaded.

Whiteboard: MGA3TOO has_procedure MGA4-32-OK MGA4-64-OK => MGA3TOO has_procedure MGA4-32-OK MGA4-64-OK advisory

OK, tested Mageia 3 i586 successfully as well.

Thanks for catching that Rémi.

This has been sufficiently tested to validate.  Re-validating.

Sysadmins, please push to core/updates.  Thanks.

Keywords: (none) => validated_update
Whiteboard: MGA3TOO has_procedure MGA4-32-OK MGA4-64-OK advisory => MGA3TOO has_procedure MGA3-32-OK MGA4-32-OK MGA4-64-OK advisory

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGAA-2014-0193.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED