Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.unix.shell
Subject: Re: (shellcheck) SC2103
Date: Thu, 6 Mar 2025 19:50:16 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 106
Message-ID: <20250306112024.879@kylheku.com>
References: <vq9nto$18ps$1@news.xmission.com>
 <20250305103210.358@kylheku.com> <vqc1hn$881$2@news.xmission.com>
Injection-Date: Thu, 06 Mar 2025 20:50:17 +0100 (CET)
Injection-Info: dont-email.me; posting-host="04955cbd15ca2b8c7171511d202c7356";
	logging-data="3284467"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/+kKERdD96xPvjVhEph03DE6K1xkCUiUo="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:zrABoEGAM9FJbjxbfdI5vuXoxJ0=
Bytes: 4268

On 2025-03-06, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <20250305103210.358@kylheku.com>,
> Kaz Kylheku  <643-408-1753@kylheku.com> wrote:
>>On 2025-03-05, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>> All testing done with shellcheck version 0.10.0 and bash under Linux.
>>>
>>> Shellcheck says that you should replace code like:
>>>
>>>     cd somedir
>>>     do_something
>>>     cd ..	# (Or, cd -, which is almost, but not exactly the same thing)
>>>
>>> with
>>>
>>>     (
>>>     cd somedir
>>>     do_something
>>>     )
>>
>>That obviously won't work if do_something has to set a variable
>>that is then visible to the rest of the script.
>
> That's actually mentioned in the rationale on the web page.
> That if you need to set a variable, you can't use subshells.
>
>>Forking a process just to preserve a current working directory
>>is wasteful; we wouldn't do that in a C program, where we might
>>open the current directory to be saved, and then fchdir back to it.
>>
>>However, most of the actions in a shell script fork and exec
>>something anyway.
>
> Yes, but those would be the cheap form of fork(), where if it is quickly
> followed by an exec(), you don't have to do COW.
>
> Note that, in Linux, fork() is actually an alias for vfork().

Nope. In Linux, fork translates to a clone call with a
menu of options to bring about the fork behavior. Whereas
vfork is its own system call. You can easily see this with
strace.

Classic vfork shares address space between the child and parent,
including the stack frame where the the fork is happening.

Linux vfork mitigates the problems which could arise from that
sharing by suspending the parent until the child either
execs or terminates.

Either way, fork cannot be vfork; that is nuts. It would break amost all
programs which do anything other than exec an image in the child.

Of course, fork *can* be vfork when it is vfork that is made
identical to fork.

I have an old vfork test program in my directory of such test
programs. It's showing that vfork does share the stack frame
with parent and child.

The output is "var == 43" showing that the parent sees the
value incremented by the child:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

int main(void)
{
  volatile int var = 42;
  int status;
  pid_t child = vfork();

  if (child > 0) {
    waitpid(child, &status, 0);
    printf("var == %d\n", var);
  } else if (child == 0) {
    var++;
    _exit(0);
  } else {
    perror("vfork");
    return EXIT_FAILURE;
  }

  return EXIT_SUCCESS;
}

If we reorder the declarations like this:

int main(void)
{
  pid_t child = vfork();
  volatile int var = 42;
  int status;

The output is then "var == 42". Why? Because vfork() suspends the parent
until the child shits a new process, or gets off the can.
And only when vfork terminates does the parent execute the effect
of the "volatile int var = 42" declaration. So at that point, it has
clobbered the value to 42. While the parent is suspended, the
child also initializes the value to 42, and increments it to 43.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca