[kde-freebsd] Re: patch needed for Xsession

[M. Warner Losh]

  On 10/27/2010 20:30, Raphael Kubo da Costa wrote:
> At Wed, 27 Oct 2010 19:48:40 -0600,
> M. Warner Losh wrote:
>>    On 10/27/2010 18:50, Raphael Kubo da Costa wrote:
>>> At Wed, 27 Oct 2010 18:23:57 -0600,
>>> M. Warner Losh wrote:
>>>>     On 10/27/2010 18:20, Raphael Kubo da Costa wrote:
>>>>> At Wed, 27 Oct 2010 17:39:58 -0600,
>>>>> M. Warner Losh wrote:
>>>>>>      On 10/27/2010 17:38, Raphael Kubo da Costa wrote:
>>>>>>> At Thu, 28 Oct 2010 14:59:37 -0400,
>>>>>>> Kris Moore wrote:
>>>>>>>> I've gone ahead and fixed the Xsession we ship in PC-BSD, however
>>>>>>>> this won't correct it for FreeBSD KDE users. This file is generated
>>>>>>>> when the user runs "genkdmconf", and I confimed that it still produces the
>>>>>>>> broken Xsession. We'll need to get it fixed there for everybody :)
>>>>>>> Do you know when genkdmconf is usually run? I think there is no
>>>>>>> problem in patching the ports tree, but if we're to commit this fix
>>>>>>> upstream, it'd be good to first know the outcome of Warner's
>>>>>>> discussion with jilles@ abou the right POSIX shell behaviour.
>>>>>> It 'accidentally works' on Linux.  'expect' and 'expect -p' produce the
>>>>>> same output.  and /bin/sh -c expect -p really is the same as /bin/sh -c
>>>>>> expect, per POSIX parsing rules of -c.  I'm pretty sure that its
>>>>>> required for other systems as well, since it is broken there as well.
>>>>>>
>>>>>> It sounds like FreeBSD's shell is posix compliant in this regard, so it
>>>>>> isn't a bug to be fixed there.
>>>>> Alright, so the problem's that -p is currently being interpreted as a
>>>>> parameter to /bin/sh itself, not to the export command?
>>>> No.  -p is $0 for the builtin command expect.
>>> Wait, I thought we were talking about export, not expect (I don't see
>>> expect mentioned in genkdmconfig's source code).
>> I mistyped.  It is export.
> I think I've got a little confused here.
>
> In the case we're talking about, /bin/sh is expanding $SHELL to
> */{csh,tcsh}. If I run /bin/tcsh or /bin/csh by hand here, I cannot
> run 'export' because it does not seem to be a valid builtin; if I run
> /bin/sh, I can 'export' and indeed its output is different from
> 'export -p', while they are identical in bash.
It is the second /bin/sh that I'm talking about.  The first $SHELL is 
indeed /bin/csh or /bin/tcsh, which is why the two ifs work their 
magic.  They modify the environment, which is then printed in /bin/sh 
format with the forked /bin/sh export -p (or it would be -p if it were 
quoted).

    $SHELL -c "if (-f /etc/csh.login) source /etc/csh.login; if (-f 
~/.login) source ~/.login; /bin/sh
  -c export -p >! $xsess_tmp"

The second /bin/sh isn't tcsh, but /bin/sh, and is trying to run export 
-p which is builtin to that shell.  However, since Xsession didn't quote 
it, we wind up in the situation that I talked about.  sh runs the 
builtin command export with -p as $0.  This is exactly what /bin/sh is 
supposed to do.

The reason this works with bash is that 'export' and 'export -p' produce 
the same output.  FreeBSD's 'export' produces different output than 
'export -p'.  This conforms to the standards.

That's why the quotes are necessary.

> Do you know if (t)csh has no 'export' builtin and if /bin/sh should
> really be identified as either of them?

Warner