3 ms·

Your filesystem question is actually far from simple, due to all manner of edge-cases. In particular, since you say things like "globally accessible to be read

Your filesystem question is actually far from simple, due to all manner of edge-cases. In particular, since you say things like "globally accessible to be read and written to by all programs", I'll assume we're not talking about chroot, bind-mounts, etc. I'll also ignore the case where we open a file path, then delete the path, then open the path again; since that gives us two separate files, though the first can no longer be accessed via its original path (we can hand-wave these by pretending the path has moved to /proc/<pid>/fd or something). If we ignore those, and just stick to normal FS operations in an ordinary Linux process, then those filesystem objects are globals, since the filesystem is a global namespace: a name (or path, in this case) will always refer to the same filesystem object (modulo the caveats above). --- > If I am understanding you correctly, you are stating that a given shell, specifically a subshell -- may not in some cases see the same shell variables as other shells... No, that's not what I'm saying. I'm talking about env vars: bound via `execve`, stored near the spawned process's stack). Not shell variables, or any other language-specific/internal variables (whether a shell, like Bash, or otherwise). That's the entire reason why my code example used `export`.

peter_d_sherman 1y ago
>No, that's not what I'm saying. I'm talking about env vars: bound via `execve`, stored near the spawned process's stack). Not shell variables, or any other language-specific/internal variables (whether a shell, like Bash, or otherwise). That's the entire reason why my code example used `export`. OK, fair enough! >"If we ignore those, and just stick to normal FS operations in an ordinary Linux process, then those filesystem objects are globals , since the filesystem is a global namespace : a name (or path, in this case) will always refer to the same filesystem object (modulo the caveats above)." Now, here you make an excellent point (and one that escaped my perception at the start of this dialogue, when I focused mostly on considering shell variables as globals), which is simply this: Any OS system object (which includes but is not limited to files, environment variables, shared memory, synchronization objects, lists of things (and other objects) produced by API calls, sockets, OS data structures in memory, etc.) which is global in scope, that is, accessible to processes/programs -- is potentially a global variable...because programs/processes can potentially treat them as global variables... (Now, let me nuance that statement, and import some of your arguments!) ...at least a good percentage of the time... ...that is (and here's the import of some of your arguments!), at least, not when edge-cases and other special circumstances and caveats apply (of which you've given many that could potentially apply!) So is any global OS object -- the same as a global variable? The short answer might be "a good percentage of the time, yes". The longer answer might be "a good percentage of the time, yes -- but it can depend on many other factors..." And the longest, most nuanced answer, might start something like this: "a good percentage of the time, yes, but it can depend on many other factors -- and what follows is a list of all of those potential factors..." Anyway, you make a whole lot of very excellent, interesting, and certainly thought-provoking points! I appreciate your engagement in this discussion! (You genuinely broadened my perception in this area!)

peter_d_sherman 1y ago

>No, that's not what I'm saying. I'm talking about env vars: bound via `execve`, stored near the spawned process's stack). Not shell variables, or any other language-specific/internal variables (whether a shell, like Bash, or otherwise). That's the entire reason why my code example used `export`. OK, fair enough! >"If we ignore those, and just stick to normal FS operations in an ordinary Linux process, then those filesystem objects are globals , since the filesystem is a global namespace : a name (or path, in this case) will always refer to the same filesystem object (modulo the caveats above)." Now, here you make an excellent point (and one that escaped my perception at the start of this dialogue, when I focused mostly on considering shell variables as globals), which is simply this: Any OS system object (which includes but is not limited to files, environment variables, shared memory, synchronization objects, lists of things (and other objects) produced by API calls, sockets, OS data structures in memory, etc.) which is global in scope, that is, accessible to processes/programs -- is potentially a global variable...because programs/processes can potentially treat them as global variables... (Now, let me nuance that statement, and import some of your arguments!) ...at least a good percentage of the time... ...that is (and here's the import of some of your arguments!), at least, not when edge-cases and other special circumstances and caveats apply (of which you've given many that could potentially apply!) So is any global OS object -- the same as a global variable? The short answer might be "a good percentage of the time, yes". The longer answer might be "a good percentage of the time, yes -- but it can depend on many other factors..." And the longest, most nuanced answer, might start something like this: "a good percentage of the time, yes, but it can depend on many other factors -- and what follows is a list of all of those potential factors..." Anyway, you make a whole lot of very excellent, interesting, and certainly thought-provoking points! I appreciate your engagement in this discussion! (You genuinely broadened my perception in this area!)