This works successfully, as I check the umask afterward by typing

Consider the process tree like an outline. Each node in the outline has a set of attributes. Each node is only able to modify its own attributes. When a child process is created, the attributes from the parent node are copied to the child node.

umask is an attribute of the process. Your process is only able to modify the umask of itself. All children started by that process will then inherit the current umask at the time the child process is invoked. You cannot modify any process that is not the current process (ignore kernel hackery for this discussion).

What you are considering behavior that "works" is the following:

• Shell is using the internal directive to change its umask. From that moment on (at least until it is changed again), the shell is running with the new umask. If this were done with an external command, it would not work, since the external command would be on a different node in the outline.
• Every child process started after that point inherits the current umask of the shell at the time the new process is started.

What you are seeing in the terminal is consistent with the outline / attribute analogy. What you are seeing in the perl code is also consistent with the analogy. You are starting a child process (`umask...`), which is inheriting the current umask value of the perl process. Once the child process is complete, the parent continues on, not effected by what the child process did to change its umask attribute.

When the perl process terminates, the parent process that started perl also does not care what perl did to its own umask attribute.

Once you understand that a process is not effected by its children (outside of IPC means), a lot of things become clearer.