Using subshell makes ash/dash/csh clobber its history with some PS1-related (?) junk

[doktornotor]

E.g., if I type cd /usr/portage/distfiles into a subshell in , the folloging will get logged:

cd "printf "%b" '\0057'"
cd "printf "%b" '\0057usr'"
cd "printf "%b" '\0057usr\0057portage'"
cd "printf "%b" '\0057usr\0057portage\0057distfiles'"
cd "printf "%b" '\0057'"

The above is on Gentoo.

On FreeBSD, junk gets logged as well, e.g. cd /var/log produces:

#+1267704528
cd "printf "%b" '\0057var'"
#+1267704528
cd "printf "%b" '\0057var\0057log'"

Have had this problem for ages, valid with any app-misc/mc version incl. the latest masked 4.7.1. Happens semi-randomly and usually doesn't happen if I press Enter before typing into the subshell.

Reproduced on Gentoo and FreeBSD, have had this issue for ages. Currently using bash-4.1_p2 but as said above, it doesn't matter, been so for a long time.

Related downstream bug: ​http://bugs.gentoo.org/show_bug.cgi?id=309261

In case it matters:

$ echo $PS1
\[\033[01;32m\]\u@\h\[\033[01;34m\] \w \$\[\033[00m\]

If you need something else, let me know :)

[angel_il]

IMHO this bug is by-effect of #213

[adminX]

Replying to angel_il:

IMHO this bug is by-effect of #213

It is not only a side-effect of #213 but enables you to all sorts of bad things.

example:

run mc
have somedir in the current panel and your home in the other panel.
Press <Ctrl-O> to get a subshell
Enter rm -rf with trailing space
Press <Ctrl-O> to get back to mc and press <Tab> or <Ctrl-I> to get into the other panel.
This will remove everything in somedir/cd and / or whatever directory was current to the other panel.

[doktornotor]

Replying to adminX:

run mc
have somedir in the current panel and your home in the other panel.
Press <Ctrl-O> to get a subshell
Enter rm -rf with trailing space
Press <Ctrl-O> to get back to mc and press <Tab> or <Ctrl-I> to get into the other panel.
This will remove everything in somedir/cd and / or whatever directory was current to the other panel.

Yikes, indeed... :/ Well, this one really sucks.

[adminX]

After getting some sleep and another look at the patch the bug report itself is not a side-effect of #213. #213 only enables you to accidentally execute unexpected commands. The execution of the commands mentioned in the bug report are needed to change the subshell to the correct directory.

I think it is impossible to remove them and keep the subshell and current panel directories in sync without feeding some sort of command to the subshell.
Without subshell it works fine as there is no need to change the current working directory of a running shell.

[doktornotor]

Hello... I probably was not clear enough. This is NOT about cd only... E.g. pwd does the same thing. Worse yet, it is NOT needed to type cd or any other command manually, simply switching to another dir on the second pane, using (or merely switching to) a subshell there, going back tu first pane and using subshell there spams bash history with tons of junk. E.g., have /usr in first panel, /tmp in second and do the above, you'll get:

cd "printf "%b" '\0057'"
cd "printf "%b" '\0057tmp'"

echo

cd "printf "%b" '\0057usr'"

I don't know whether you realize the severity of the problem, because it currently makes my bash history practically unusable.

$ grep printf ~/.bash_history | wc -l
6709

And there's another thing:

$ grep PROMPT_COMMAND .bash_history | wc -l
174

but that's probably #2027 more than this.

[adminX]

Logging of Midnight Commander's cd and PROMPT_COMMAND lines happens if $HISTCONTROL is unset or otherwise not set to ignorespace or ignoreboth.
HISTCONTROL=ignorespace is set by default in MC but may be overriden in ~/.mc/bashrc or ~/.bashrc or any file included from there.

#2027 has the problem in the other direction as MC overwrites the variable after starting bash.

[doktornotor]

Hmmm... I don't think this is the case.

$ echo $HISTCONTROL
ignorespace ignoredups

on all boxes where I experience this issue. So, HISTCONTROL won't help here. Meanwhile, export HISTIGNORE='cd "\`printf*' will work around logging most of the noise but that's obviously not a real solution.

[ossi]

Replying to doktornotor:

$ echo $HISTCONTROL
ignorespace ignoredups

this is wrong. the separator is a colon.

[doktornotor]

Oh well, a lot if misunderstanding here apparently. So - the above is what bash spits out as ENV variable, so wrt separators you need to talk to bash upstream.

$ grep HISTCONTROL $HOME/.bashrc
export HISTCONTROL="ignoreboth"

[adminX]

$HISTCONTROL is evaluated every time a command is executed.

Your export HISTCONTROL="ignoreboth" in ~/.bashrc seems to be overridden by a sourced script.

[doktornotor]

Well... indeed, figured out. This all junk was caused by sourcing a stale mc.sh wrapper in .bashrc which in turn sourced another stale mc-wrapper.sh which attempted to append stuff to $HISTCONTROL in a broken way. From where did those stale files come - no idea *g*

So, thanks for help and close this, and sorry for wasting your time.

[slavazanko]

Added answer into FAQ:

​http://www.midnight-commander.org/wiki/doc/faq#a6.8Iseelotofstrangecdprintflinesintomy.historyfile

If answer in FAQ not clean - keep comments here.

[doktornotor]

Pretty clean and clear to me... Hopefully this saves other people some trouble. Thanks again. ;)

[Klimontov]

Hello guys!
Take in account, there is issue. Condition is reproduced and this is very very bad.

Replying to adminX:

run mc
have somedir in the current panel and your home in the other panel.
Press <Ctrl-O> to get a subshell
Enter rm -rf with trailing space
Press <Ctrl-O> to get back to mc and press <Tab> or <Ctrl-I> to get into the other panel.

[Klimontov]

Hello again.
I am can propose next fix. This is not very good solve, but you can modify him better.

See Attached: subshell.diff​

[andrew_b]

Well, patches in the closed ticket is not good idea. :)

About patch.

if (strstr (mc_global.tty.shell, "/bash") || getenv ("BASH"))

This is overkill. I (and most bush users) don't have this problem. But this bug is reproducible with (t)csh: #3063. But I personally not so familiar with various shell internals to 1) know what and why this happens exactly and 2) fix this correctly.

[birdie]

How is this still an issue?

HISTCONTROL=ignoredups totally wreaks havoc as I get sh*ty entries in my bash history.

Please fix ASAP.

This is not mentioned anywhere in the documentation - you could at least add this as a warning.

[birdie]

This is reproducible in Fedora 29/MC 4.8.21.

[zaytsev]

Hmmm, I don't have any problems with garbage history entries on Fedora 29 with stock mc package and default user settings. What is the problem that you are facing and how to reproduce it?

[dmnc]

I have this problem too on Alpine Linux 3.11 (default with busybox). But if Bash is installed and set to $SHELL (on runtime or system wide) then the junk issue is no longer present.

# SHELL="/bin/bash" mc

[zaytsev]

I have checked the source code and it seems that BusyBox shells (ash/hush) don't support HISTCONTROL. I've sent a patch to busybox@…, for now it's bounced, no idea what happens next.

From 1165db3b3851e3fece948da669e9b520d4db37f9 Mon Sep 17 00:00:00 2001
From: "Yury V. Zaytsev" <yury@shurup.com>
Date: Sun, 6 Oct 2024 15:03:19 +0200
Subject: [PATCH] lineedit: add basic support for bash-style HISTCONTROL
options

Signed-off-by: Yury V. Zaytsev <yury@shurup.com>
---
libbb/lineedit.c | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/libbb/lineedit.c b/libbb/lineedit.c
index 151208c1c..1cdf16cea 100644
--- a/libbb/lineedit.c
+++ b/libbb/lineedit.c
@@ -1657,6 +1657,7 @@ static void save_history(char *str)
static void remember_in_history(char *str)
{
	int i;
+	char *histcontrol;

	if (!(state->flags & DO_HISTORY))
		return;
@@ -1667,6 +1668,12 @@ static void remember_in_history(char *str)
	if (i && strcmp(state->history[i-1], str) == 0)
		return;

+	if ((histcontrol = getenv("HISTCONTROL"))
+		&& (strstr(histcontrol, "ignorespace")
+		    || strstr (histcontrol, "ignoreboth"))
+		&& str[0] == ' ')
+		return;
+
	free(state->history[state->max_history]); /* redundant, paranoia */
	state->history[state->max_history] = NULL; /* redundant, paranoia */

--
2.46.2

It seems that csh/tcsh only supports this:

beastie@freebsd:~ $ csh
beastie@freebsd:~ $ unset savehist

No idea if we should set it when we fork the shell (but then user commands will be lost as well) or there is some way to do our business forking new instances all the time, but I guess not.

[zaytsev]

Dash also has the same problem, interesting to talk to the developers, maybe they would agree to do HISTCONTROL:

​http://gondor.apana.org.au/~herbert/dash/

[zaytsev]

​https://lore.kernel.org/dash/36590CFE-D82B-4A0D-A3A3-57434BADF6A7@shurup.com/T/#u

[zaytsev]

No luck with Busybox list, posted to Bugzilla instead: ​https://bugs.busybox.net/show_bug.cgi?id=16213

[zaytsev]

Ticket #3063 has been marked as a duplicate of this ticket.

[zaytsev]

csh/tsch ideas:

1. Edit history in precmd hook: insane, but could also work for ash/dash - see #3063
2. Just disable history for subshell, maybe better than filling it with garbage (unset savehist)

[zaytsev]

Ticket #4066 has been marked as a duplicate of this ticket.