Re: Mc Digest, Vol 23, Issue 6

[Pavel Roskin <proski gnu org>]

Hello!

On Wed, 2006-03-15 at 15:36 +0000, Reynir Stefansson wrote:
> Pavel Tsekov wrote:
> > On Wed, 2006-03-08 at 23:08 +0000, Reynir Stefansson wrote:
> >   
> > > What does MC need from a shell for subshell support to work, at least in 
> > > theory?
> > >     
> >
> > The ability to notify mc that it has finished executing a command.
> >   
>
> I'll assume it's a signal and refer to it here as SIGBURP. And since MC 
> can not be hacked to raise an alert box on return from shell-out before 
> a SIGBURP (or let you know some other way), I'll have to either live 
> with occasionally wanting to Dragu Slave the directory-hold function or 
> patch the shell to fire SIGBURP whenever the command line empties.

I don't understand what you mean.  Perhaps you should read
src/subshell.c (look for "precmd").

> > > I recall a case (see MC Digest v7n3 for *that* little episode) 
> > > where MC wouldn't go subshell with /bin/sh. At that time /bin/sh was a 
> > > link to /bin/bash. It's of course possible that bash masqueraded as sh 
> > > when run as /bin/sh. I didn't look into it then. I just wanted to 
> > > un-fubar the subshell.
> > >
> > > Thought: Does the subshell *have* to be the same as the login shell? Or 
> > > am I being stupid again? Both? Banner news, that.
> > >     
> >
> > No, the subshell can be different, but you would need to "fool" mc
> > because it tries to use the login shell and it checks shells by name,
> > not by actual functionality.
> >   
>
> That appears to be the only easy way to do it. A config option ('login' 
> (stays with login shell), 'auto' (if the login shell is unsuitable; 
> looks for a known suitable shell) or '/path-to/shell' (for a specific 
> shell)) might help - and not just shell developers.

You guess you have never added an option to mc.  There are still several
options (check mc manual for "torben") that were never added to the user
interface because the user interface is very fragile and hard to extend.

> Stray thot: Could one build a harness that goes through /etc/shells and 
> tests each shell to see if it fires SIGBURP? Do I feel hedgehogged 
> enough to do it myveryownself?

Testing shells every time would be an overkill.  I think the user
visible option would be the best solution, but don't expect it to be
easy to implement.  If the mighty Torben couldn't add his option to the
user interface, do you think you would succeed? :-)))

-- 
Regards,
Pavel Roskin