>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!)
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!)