>That's what makes them evil to implement in kernel implementation
>of posix_spawn where the path search for posix_spawnp is to be in
>user code (where it belongs).
Why? Our implementation search in the kernel; it is perhaps 20 lines of
code?
> | for the case where PATH, as inherited by
The Solaris posix_spawnp() system call implementation does has an action to
change chdir and it will actually search the PATH in the kernel.
While the kernel has the ability the execute the file actions after the
exec as we are still in control, the native syscall posix_spawn
implementation
>On 4/14/20 9:44 AM, casper@oracle.com wrote:
>> pwd has the -L option:
>>
>> The following options shall be supported by the implementation:
>>
>> -L
>> If the PWD environment variable contains an absolute pathname
>> of the current directory and the pathname does not
>casper@oracle.com wrote, on 14 Apr 2020:
>>
>> It does seems to allow:
>>
>> (cd /; PWD=// pwd -L)
>> //
>> and
>> (cd /home/casper; PWD=/home///casper pwd -L)
>> /home///casper
>>
>>
>> Is this a correct implmentation?
>
>Yes.
Thanks.
>>
pwd has the -L option:
The following options shall be supported by the implementation:
-L
If the PWD environment variable contains an absolute pathname
of the current directory and the pathname does not contain any
components that are dot or dot-dot, pwd shall write
It seems that this bug changes the following commands about a "wf" or "rf"
option for popen(); however, I do not see the additional changes needed
for fopen().
Another question I have is this: in fdopen(), Solaris will NOT change the
file flags even when "e" is given; this makes sense, I
>"casper@oracle.com" wrote:
>> The only ones that makes sense are "kill" & "print".
>
>I would say that "print" is not needed since it is not required to be callable
>via exec(), since it is a ksh88/ksh93 private builtin.
Right "print" is not tested for in the test suite.
Casper
>2020-02-03 12:40:45 +0100, Joerg Schilling:
>[...]
>> > It looks like it's caused by an "optimisation" in its
>> > libc:exec*(), so /usr/xpg4/bin/sh and POSIX are not to blame
>> > after all.
>>
>> To which Solaris version does this apply?
>
>That was 11.4
Yes.
>> > $ ksh -c 'printf %d 1+1'
>This seems like a scenario where you would want system() to require
>pthread_atfork() handlers to be called. Aside from that, it seems somewhat
>contradictory that system() "shall behave as if a child process were created
>using fork()..." but it is undefined if pthread_atfork() handlers
>On Solaris, vfork() is 3x faster than fork(),
This depends very much on application.
In Solaris, vfork() is more or less O(1) where fork() is a O(n)
where "n" is the size of the address space: each r/w page which isn't
shared needs to be marked "read-only" so the first modification clones
>--
> (0003753) shware_systems (reporter) - 2017-06-06 12:14
> http://austingroupbugs.net/view.php?id=1142#c3753
>--
>While this looks reasonable, the
11 matches
Mail list logo
