"Cannot change to" directory\n warning when entering directory ending with newline

[mc-butler]

Important

This issue was migrated from Trac:

Origin	https://midnight-commander.org/ticket/2325
Reporter	gotar (gotar@….pl)

1. create directory with trailing newline,
2. get into it.

The warning appears, although nothing unexpected happens and works as expected.

[mc-butler]

Changed by andrew_b (@aborodin) on Aug 26, 2010 at 11:29 UTC

Replying to gotar (#2325):

The warning appears, although nothing unexpected happens and works as expected.

For me. MC hangs up when tries enter to the directory with newline in the its name. This is known problem related to the subshell support. Try you testcase with mc -u.

[mc-butler]

Changed by gotar (gotar@….pl) on Aug 26, 2010 at 11:34 UTC (comment 2)

I got hangup on different machine with 4.6.2. Indeed, without subshell the warning's gone.

[mc-butler]

Changed by andrew_b (@aborodin) on Aug 26, 2010 at 11:45 UTC (comment 3)

Related to #184.

[mc-butler]

Changed by andrew_b (@aborodin) on Aug 26, 2010 at 17:35 UTC

• Blocked by set to #184

[mc-butler]

Changed by andrew_b (@aborodin) on Oct 31, 2011 at 10:56 UTC (comment 5)

• Milestone changed from 4.7 to Future Releases
• Branch state set to no branch

[mc-butler]

Changed by zaytsev (@zyv) on Jan 3, 2016 at 18:17 UTC (comment 6)

• Version changed from 4.7.3 to 4.8.15

Now the subshell is garbled, need to resize the window after exiting from the directory to restore it, but no warnings or hangs are happening. Without subshell (mc -u), everything is fine now.

[egmontkob]

subshell_name_quote() produces a string that looks like

cd "`printf '%b' 'ABC\0nnnDEF\0nnnXYZ'`"

The problem is that `...` a.k.a. $(...) command substitution strips off all trailing newlines. So it's not a binary safe method.

Quite a few shells (at least bash, zsh and tcsh) support $'' string definitions with escape characters, e.g.

cd $'abc\n\n'

which is also much simpler. We should do this on at least those shells that support this (or some similar syntax for this).

[egmontkob]

fish:

cd 'abc'\n\n

or any \nnn (octal) or \xnn (hex) outside of quote marks / apostophes.

[zyv]

@mirabilos, maybe with your knowledge of shells, you could help us out here: off the top of your head, do you know the equivalent of cd $'abc\n\n' (bash / zsh / tcsh) for our supported subshells receiving least love like *ksh, ash, dash, and friends?

[egmontkob]

The following would almost certainly be a wrong solution. Let me mention it before someone goes with it and doesn't see the downsides :)

Simply have literal newlines between single quotes. E.g. to enter the directory abc\n\n, it would be something like

cd 'abc

'

Why is it wrong?

We're targeting plain / simple / old-fashioned shells, and they don't have line editing, so we're entering these to the kernel's cooked mode. Depending on platform and stty settings, it might perform weird cr/lf conversions. Other special bytes (like ^C interrupt, ^U yank etc.) couldn't work this way either.

[egmontkob]

dash, ksh93, mksh:

I can't see how to specify string constants with embedded special characters in dash (except for a literally typing them, which we cannot do as per the previous comment).

What I've found though is that these shells support ${parameter%word} to remove a suffix from a variable. Is this standard POSIX sh, supported by other shells too?

So what we could do: use printf in command substitution to print the working directory, but with an additional character (_ in this example). This prevents chopping off trailing newlines. Intermediate newlines are preserved as expected. E.g. to enter the directory abc\n\n:

newdir_="$(printf '%b_' 'abc\n\n')"

Then strip off that trailing _. It works because here we don't use command substitution, but rather string operations which are fine with keeping a trailing newline:

newdir="${newdir_%_}"
cd "$newdir"

The last two could obviously be combined into a single statement.

How portable would this be?