Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Subshell precmd emulation fills ash/dash/csh/tcsh history with internal pwd commands #2104

Open
mc-butler opened this issue Mar 14, 2010 · 32 comments
Open

Subshell precmd emulation fills ash/dash/csh/tcsh history with internal pwd commands #2104

mc-butler opened this issue Mar 14, 2010 · 32 comments
Labels
area: core Issues not related to a specific subsystem prio: medium Has the potential to affect progress ver: 4.7.1 Reproducible in version 4.7.1
Milestone
Future Releases

Comments

@mc-butler
Copy link

Important

This issue was migrated from Trac:

Origin https://midnight-commander.org/ticket/2104
Reporter doktornotor (notordoktor@….com)
Mentions mc-trac@….de, kyogre1@….ru

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 :)

Note

Original attachments:
@mc-butler
Copy link
Author

Changed by angel_il (@ilia-maslakov) on Mar 14, 2010 at 13:09 UTC (comment 1)

IMHO this bug is by-effect of #213

@mc-butler
Copy link
Author

Changed by adminX (mc-trac@….de) on Mar 16, 2010 at 14:23 UTC (comment 1.2)

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.

@mc-butler
Copy link
Author

Changed by doktornotor (notordoktor@….com) on Mar 16, 2010 at 17:35 UTC (comment 2.3)

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.

@mc-butler
Copy link
Author

Changed by adminX (mc-trac@….de) on Mar 17, 2010 at 8:11 UTC (comment 4)

  • Cc set to mc-trac@….de

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.

@mc-butler
Copy link
Author

Changed by doktornotor (notordoktor@….com) on Mar 17, 2010 at 8:40 UTC (comment 5)

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.

@mc-butler
Copy link
Author

Changed by adminX (mc-trac@….de) on Mar 17, 2010 at 10:17 UTC (comment 6)

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.

@mc-butler
Copy link
Author

Changed by doktornotor (notordoktor@….com) on Mar 17, 2010 at 10:29 UTC (comment 7)

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.

@mc-butler
Copy link
Author

Changed by ossi (@ossilator) on Mar 17, 2010 at 10:39 UTC (comment 7.8)

Replying to doktornotor:

$ echo $HISTCONTROL
ignorespace ignoredups

this is wrong. the separator is a colon.

@mc-butler
Copy link
Author

Changed by doktornotor (notordoktor@….com) on Mar 17, 2010 at 10:46 UTC (comment 9)

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"

@mc-butler
Copy link
Author

Changed by adminX (mc-trac@….de) on Mar 17, 2010 at 11:10 UTC (comment 10)

$HISTCONTROL is evaluated every time a command is executed.

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

@mc-butler
Copy link
Author

Changed by doktornotor (notordoktor@….com) on Mar 17, 2010 at 11:19 UTC (comment 11)

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.

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Mar 17, 2010 at 12:27 UTC (comment 12)

  • Resolution set to invalid
  • Status changed from new to closed

Added answer into FAQ:

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

If answer in FAQ not clean - keep comments here.

@mc-butler
Copy link
Author

Changed by doktornotor (notordoktor@….com) on Mar 17, 2010 at 12:31 UTC (comment 13)

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

@mc-butler
Copy link
Author

Changed by Klimontov (klimontovm@….ru) on Sep 12, 2013 at 6:40 UTC (comment 14)

  • Branch state set to no branch

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.

@mc-butler
Copy link
Author

Changed by Klimontov (klimontovm@….ru) on Sep 16, 2013 at 5:08 UTC

@mc-butler
Copy link
Author

Changed by Klimontov (klimontovm@….ru) on Sep 16, 2013 at 5:11 UTC (comment 15)

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

See Attached: subshell.diff​

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Sep 16, 2013 at 6:16 UTC (comment 16)

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.

@mc-butler
Copy link
Author

Changed by birdie (aros@….com) on Dec 31, 2018 at 18:47 UTC (comment 17)

  • Resolution invalid deleted
  • Status changed from closed to reopened

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.

@mc-butler
Copy link
Author

Changed by birdie (aros@….com) on Dec 31, 2018 at 19:20 UTC (comment 18)

This is reproducible in Fedora 29/MC 4.8.21.

@mc-butler
Copy link
Author

Changed by zaytsev (@zyv) on Jan 1, 2019 at 14:21 UTC (comment 19)

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?

@mc-butler
Copy link
Author

Changed by dmnc (lurid@….net) on Jun 10, 2020 at 14:20 UTC (comment 20)

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

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Apr 7, 2021 at 18:52 UTC (comment 21)

  • Milestone changed from 4.7 to Future Releases

@mc-butler
Copy link
Author

Changed by Kyogre (kyogre1@….ru) on Sep 8, 2023 at 12:40 UTC (comment 22)

  • Cc changed from mc-trac@….de to mc-trac@….de, kyogre1@….ru

@mc-butler
Copy link
Author

Changed by zaytsev (@zyv) on Oct 6, 2024 at 15:28 UTC (comment 23)

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@busybox.net, 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.

@mc-butler
Copy link
Author

Changed by zaytsev (@zyv) on Oct 6, 2024 at 15:55 UTC (comment 24)

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/

@mc-butler
Copy link
Author

Changed by zaytsev (@zyv) on Oct 6, 2024 at 17:58 UTC (comment 25)

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

@mc-butler
Copy link
Author

Changed by zaytsev (@zyv) on Oct 18, 2024 at 7:28 UTC (comment 26)

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

@mc-butler
Copy link
Author

Changed by zaytsev (@zyv) on Oct 21, 2024 at 19:17 UTC (comment 27)

  • Summary changed from using subshell makes bash clobber its history with some PS1-related (?) junk to Using subshell makes ash/dash/csh clobber its history with some PS1-related (?) junk

@mc-butler
Copy link
Author

Changed by zaytsev (@zyv) on Oct 21, 2024 at 19:18 UTC (comment 28)

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

@mc-butler
Copy link
Author

Changed by zaytsev (@zyv) on Oct 21, 2024 at 19:20 UTC (comment 29)

csh/tsch ideas:

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

@mc-butler
Copy link
Author

Changed by zaytsev (@zyv) on Oct 22, 2024 at 12:07 UTC (comment 30)

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

@mc-butler
Copy link
Author

Changed by zaytsev (@zyv) on Feb 6, 2025 at 10:07 UTC (comment 31)

  • Summary changed from Using subshell makes ash/dash/csh clobber its history with some PS1-related (?) junk to Subshell precmd emulation fills ash/dash/csh/tcsh history with internal pwd commands

@mc-butler mc-butler reopened this Feb 27, 2025
@mc-butler mc-butler marked this as a duplicate of #3063 Feb 28, 2025
@mc-butler mc-butler marked this as a duplicate of #4066 Feb 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area: core Issues not related to a specific subsystem prio: medium Has the potential to affect progress ver: 4.7.1 Reproducible in version 4.7.1
Milestone
Future Releases
Development

No branches or pull requests
1 participant
@mc-butler