setting current dir of remote shell

[Dave Yost]

Thanks for pointing out the subtleties of exec -l.

But there's a problem.

Zsh doesn't support exec -l but instead supports "zsh -l".
Doing what you propose doesn't work when the remote shell is zsh.
And doing it the way that works for remote zsh fails with remote bash.

Is this the unsolvable problem it appears to be?

Thanks again.

Dave

At 06:25 PM -0600 2007-04-29, Bob Proulx wrote:
>Dave Yost wrote:
>> Bob Proulx wrote:
>> >For me the following works:
>> >  ssh -t someserver "cd $(pwd) && exec -l \$0"
>> >  $ echo $0
>> >  -bash
>>
>> I assume you mean
>>
>>   ssh -t someserver "cd $(pwd) && exec \$0 -l"
>
>No, I really did mean 'exec -l \$0'.  Your transposition is similar
>and will have similar effects but is not identical.  (Very close to
>though, and the difference is quite subtle.)
>
>  help exec
>  exec: exec [-cl] [-a name] file [redirection ...]
>      Exec FILE, replacing this shell with the specified program.
>      If FILE is not specified, the redirections take effect in this
>      shell.  If the first argument is '-l', then place a dash in the
>      zeroth arg passed to FILE, as login does.  If the '-c' option
>      is supplied, FILE is executed with a null environment.  The '-a'
>      option means to make set argv[0] of the executed process to NAME.
>      If the file cannot be executed and the shell is not interactive,
>      then the shell exits, unless the shell option 'execfail' is set.
>
>The magic part is:
>
>  "If the first argument is '-l', then place a dash in the zeroth arg
>  passed to FILE, as login does."
>
>The classic /bin/login program has always placed a dash as the first
>character of the shell when starting up login shells.  Shells inspect
>their first argument, their own name, and look for a '-' in the
>leading part of the name.  If the shell finds a '-' there then they
>assume they were started by login and configure themselves as a login
>shell.  Login shells read the defined list of environment files such
>as /etc/profile and others.
>
>The transposition of using 'exec \$0 -l' instead of 'exec -l \$0'
>won't place a dash in the leading part of the shell's name.  Therefore
>the shell won't think it is a login in the same way that it would if
>it were really a login shell started by /bin/login.  However the shell
>will by the -l option be told to behave as a login shell.  At that
>point the shell will behave fully as a login shell and there is no
>difference.  However if child programs want to deduce if the parent
>shell is a login shell or not they usually look at $0, as I did in my
>example, and look to see if the shell's name starts with a dash or
>not.  This difference is probably insignificant but child processes
>won't be able to tell if the parent is a login shell in that case.
>
>The problem is that POSIX does not specify any options to exec and
>therefore use of 'exec -l' is non-standard by definition.  I do not
>know which shells support it and which do not.  Bash supports it and
>so if it is known to be working with bash then it is fine to use.  But
>if it must be completely portable to unspecified shells then of course
>it would be a problem.
>
>Meanwhile, the very reason I like it is that 'exec -l $SOMESHELL' can
>spawn a random, unknown, unspecified shell as $SOMESHELL and guarantee
>that it will be a login shell even if $SOMESHELL does not take the -l
>option.  Because of the /bin/login interface of placing a leading dash
>all shells will respect that interface.  The classic csh is an example
>of a shell that does not accept a -l option to behave as a login
>shell.  Therefore 'exec csh -l' would fail while 'exec -l csh' would
>succeed in producing csh running as a login shell.  (I think newer csh
>variants have added the -l option for compatibility.)
>
>Bob