Return to Answer

Using exec is an implementation detail -- if it's not documented, then the behaviour is not guaranteed in any version. Maybe it's useful to go a little over why we tend not to document these kinds of things based on my experience developing other widely used software (the Linux kernel).

In general, for any widely used piece of software, one generally tries to only describe the features, operation, and standard behaviors. One typically avoids delving into the specifics of internal optimisations for fear of creating downstream dependencies on that behaviour.

As one example from my own field of work, I work on kernel memory management, and we don't seek to document in great detail (for example) exactly how reclaim prioritisation internals work, or exactly when things like LRU scanning is performed. Documenting that would make future decisions on optimisations and other changes much more complicated to make, because now we have to consider if we are breaking some intangible, unknown downstream dependency.

Similarly, in the case of Bash or any other complex software system, internal mechanisms like the decision to use exec instead of forking a new process can be subject to change, even at very short notice. Imagine if there are new performance optimisations, security considerations, or compatibility issue that requires not using exec suddenly. Do we really want to be bound by contract to continue operating in that way? Of course not.

In bash, and most other widely used projects, there's a strong emphasis on maintaining a stable and well-defined external interface that contains only the things deemed necessary to be exposed, allowing the internal implementation to evolve as needed. This approach ensures that the software remains robust, secure, and efficient, without sacrificing the ability to innovate and improve.

So to answer your question, no, this isn't documented, and you shouldn't rely on it. It's also highly unlikely that this or other similar cases would be documented, because adding constraints on internals would make development a lot more rigid.

Using exec is an implementation detail -- if it's not documented, then the behaviour is not guaranteed in any version. Maybe it's useful to go a little over why we tend not to document these kinds of things based on my experience developing other widely used software (the Linux kernel).

In general, for any widely used piece of software, one generally tries to only describe the features, operation, and standard behaviors. One typically avoids delving into the specifics of internal optimisations for fear of creating downstream dependencies on that behaviour.

As one example from my own field of work, I work on kernel memory management, and we don't seek to document in great detail (for example) exactly how reclaim prioritisation internals work, or exactly when things like LRU scanning are performed. Documenting that would make future decisions on optimisations and other changes much more complicated to make, because now we have to consider if we are breaking some intangible, unknown downstream dependency.

Similarly, in the case of bash or any other complex software system, internal mechanisms like the decision to use exec instead of forking a new process can be subject to change, even at very short notice. Imagine if there are new performance optimisations, security considerations, or compatibility issues that requires not using exec suddenly. Do we really want to be bound by contract to continue operating in that way? Of course not.

In bash, and most other widely used projects, there's a strong emphasis on maintaining a stable and well-defined external interface that contains only the things deemed necessary to be exposed, allowing the internal implementation to evolve as needed. This approach ensures that the software remains robust, secure, and efficient, without sacrificing the ability to innovate and improve.

So to answer your question, no, this isn't documented, and you shouldn't rely on it. It's also highly unlikely that this or other similar cases would be documented, because adding constraints on internals would make development a lot more rigid.

Using exec is an implementation detail -- if it's not documented, then the behaviour is not guaranteed in any version. Maybe it's useful to go a little over why we tend not to document these kinds of things based on my experience developing other widely used software (the Linux kernel).

In general, for any widely used piece of software, one generally tries to only describe the features, operation, and standard behaviors, but they do not typically delve into the specifics of internal optimisations for fear of creating downstream dependencies on that behaviour.

As one example from my own field of work, I work on kernel memory management, and we don't seek to document in great detail (for example) exactly how reclaim prioritisation internals work, or exactly when things like LRU scanning is performed. Documenting that would make future decisions on optimisations and other changes much more complicated to make, because now we have to consider if we are breaking some intangible, unknown downstream dependency.

Similarly, in the case of Bash or any other complex software system, internal mechanisms like the decision to use exec instead of forking a new process can be subject to change, even at very short notice. Imagine if there are new performance optimisations, security considerations, or compatibility issue that requires not using exec suddenly. Do we really want to be bound by contract to continue operating in that way? Of course not.

In bash, and most other widely used projects, there's a strong emphasis on maintaining a stable and well-defined external interface that contains only the things deemed necessary to be exposed, allowing the internal implementation to evolve as needed. This approach ensures that the software remains robust, secure, and efficient, without sacrificing the ability to innovate and improve.

So to answer your question, no, this isn't documented, and you shouldn't rely on it. It's also highly unlikely that this or other similar cases would be documented, because adding constraints on internals would make development a lot more rigid.

Using exec is an implementation detail -- if it's not documented, then the behaviour is not guaranteed in any version. Maybe it's useful to go a little over why we tend not to document these kinds of things based on my experience developing other widely used software (the Linux kernel).

In general, for any widely used piece of software, one generally tries to only describe the features, operation, and standard behaviors. One typically avoids delving into the specifics of internal optimisations for fear of creating downstream dependencies on that behaviour.

As one example from my own field of work, I work on kernel memory management, and we don't seek to document in great detail (for example) exactly how reclaim prioritisation internals work, or exactly when things like LRU scanning is performed. Documenting that would make future decisions on optimisations and other changes much more complicated to make, because now we have to consider if we are breaking some intangible, unknown downstream dependency.

Similarly, in the case of Bash or any other complex software system, internal mechanisms like the decision to use exec instead of forking a new process can be subject to change, even at very short notice. Imagine if there are new performance optimisations, security considerations, or compatibility issue that requires not using exec suddenly. Do we really want to be bound by contract to continue operating in that way? Of course not.

In bash, and most other widely used projects, there's a strong emphasis on maintaining a stable and well-defined external interface that contains only the things deemed necessary to be exposed, allowing the internal implementation to evolve as needed. This approach ensures that the software remains robust, secure, and efficient, without sacrificing the ability to innovate and improve.

So to answer your question, no, this isn't documented, and you shouldn't rely on it. It's also highly unlikely that this or other similar cases would be documented, because adding constraints on internals would make development a lot more rigid.

Using exec is an implementation detail -- if it's not documented, then the behaviour is not guaranteed in any version. Maybe it's useful to go a little over why we tend not to document these kinds of things based on my experience developing other widely used software (the Linux kernel).

In general, for any widely used piece of software, one generally tries to only describe the features, operation, and standard behaviors, but they do not typically delve into the specifics of internal optimisations for fear of creating downstream dependencies on that behaviour.

As one example from my own field of work, I work on kernel memory management, and we don't seek to document in great detail (for example) exactly how reclaim prioritisation internals work, or exactly when things like LRU scanning is performed. Documenting that would make future decisions on optimisations and other changes much more complicated to make, because now we have to consider if we are breaking some intangible, unknown downstream dependency.

Similarly, in the case of Bash or any other complex software system, internal mechanisms like the decision to use exec instead of forking a new process can be subject to change, even at very short notice. Imagine if there's some new performance optimisations, security considerations, or compatibility issue that requires not using exec suddenly. Do we really want to be bound by contract to continue operating in that way? Of course not.

In bash, and most other widely used projects, there's a strong emphasis on maintaining a stable and well-defined external interface that contains only the things deemed necessary to be exposed, allowing the internal implementation to evolve as needed. This approach ensures that the software remains robust, secure, and efficient, without sacrificing the ability to innovate and improve.

So to answer your question, no, this isn't documented, and you shouldn't rely on it. It's also highly unlikely that this or other similar cases would be documented, because adding constraints on internals would make development a lot more rigid.

Using exec is an implementation detail -- if it's not documented, then the behaviour is not guaranteed in any version. Maybe it's useful to go a little over why we tend not to document these kinds of things based on my experience developing other widely used software (the Linux kernel).

In general, for any widely used piece of software, one generally tries to only describe the features, operation, and standard behaviors, but they do not typically delve into the specifics of internal optimisations for fear of creating downstream dependencies on that behaviour.

As one example from my own field of work, I work on kernel memory management, and we don't seek to document in great detail (for example) exactly how reclaim prioritisation internals work, or exactly when things like LRU scanning is performed. Documenting that would make future decisions on optimisations and other changes much more complicated to make, because now we have to consider if we are breaking some intangible, unknown downstream dependency.

Similarly, in the case of Bash or any other complex software system, internal mechanisms like the decision to use exec instead of forking a new process can be subject to change, even at very short notice. Imagine if there are new performance optimisations, security considerations, or compatibility issue that requires not using exec suddenly. Do we really want to be bound by contract to continue operating in that way? Of course not.

In bash, and most other widely used projects, there's a strong emphasis on maintaining a stable and well-defined external interface that contains only the things deemed necessary to be exposed, allowing the internal implementation to evolve as needed. This approach ensures that the software remains robust, secure, and efficient, without sacrificing the ability to innovate and improve.

So to answer your question, no, this isn't documented, and you shouldn't rely on it. It's also highly unlikely that this or other similar cases would be documented, because adding constraints on internals would make development a lot more rigid.