Re: optimising "change CWD" algorithm in subshell mode

[Dmitry Smirnov <onlyjob member fsf org>]

Dear Oswald,

On Sun, 4 Nov 2012 21:26:04 Oswald Buddenhagen wrote:
> On Sat, Nov 03, 2012 at 11:34:58AM +1100, Dmitry Smirnov wrote:
> > For example if current working directory is /1/2/3/4/5 and we want to
> > change to /1/2/3/4/5/6 MC sends "cd /1/2/3/4/5/6" to bash when in
> > reality one would likely to use "cd ./6" as long as it is just one hop
> > away from current directory.
> > 
> > Is it feasible?
> 
> i don't like it for two reasons:
> - using an absolute path is an easy error recovery. mc gets confused
>   often enough by errors while changing cwd (especially since shell
>   activity detection was so utterly screwed up). not being able to just
>   hit <enter> twice to recover would be a major PITA.

Even if we have to ask bash for CWD (pwd) when possible it still could be done 
isn't it?
Are you sure it can't be implemented reliably?

> - this is fixing the problem at the wrong place, aka a workaround. there
>   is no way in hell that simple processing of a string with a few tens
>   of utf8 characters could legitimately require billions of cpu cycles.
>   my suspicion is that some utterly inefficient shell functions are
>   being invoked via $PS1 or so - that would also explain why there are
>   problems reproducing it.

First of all there is no problem reproducing it with bash subshell. I clearly 
described how. 

It's not "few tens" but rather a several hundred utf8 characters we're pushing 
to bash every time we change directory. Even though travelling through deep 
long trees may become very uncomfortable comparing to "-u" mode it wouldn't be 
so bad if it were merely an inconvenience of slowness. 

To me much bigger problem is that MC hangs or crashes in this situation.

If the problem is due to bash limitation for max path length then we have 
either legitimate case for workaround or a bug to file against bash.

What do you think would be the best to do about it?

Regards,
Dmitry.