Another bash variable is BASH_SUBSHELL. An example of descending subshells by command grouping.

1 members found this post helpful.

In that case I would think if you add the -l option on the third one, that will become your current shell, or?

no
-l means login shell. see man page about invocation, that will explain what is the difference between a login and non-login shell.
and you can also check the importance of interactive (and non-interactive) shells

That makes another interesting point actually. Assuming you are already root, if it is possible to force /bin/login on a third subshell of bash before you can use it

I'll have to look closer into login too. On first glance, that doesn't seem to be possible (recursive login). What should be possible is to replace it with a simple private login facility.

bash -l will not invoke login again, it will just work differently [again] with -l and without -l

Then what is it that actually determines which shell I end up in/viewing.

better to read the man page. Different invocations usually mean different setup, at the end a new environment is created. All the subshells and subprocesses will inherit this environment, and the behavior can be also altered (like where is the DISPLAY), but it doesn't really matter how it was created.

It is indeed so in Slackware too, but even so the execution context of /usr/bin/bash and /bin/bash is different, like bash and /bin/bash in my first post.

the location of the binary is usually completely irrelevant, so /usr/bin/bash, /bin/bash and <any_other_location>/bash will behave exactly the same. And does not depend on the distro too (but how it was invoked and what was the actual name of it).

Yeah, ofcourse, you would think so, but these things aren't exactly common use cases or easy to figure out either. I could ofcourse just search it online too, but past experience have shown me time and time again that uncommon use cases and solutions to them are nearly impossible to find good documentation on with search engines, and that you rather find common use cases that will not help you understand or accomplish what you actually need.

I was actually reading the online bash manual the other day:
https://www.gnu.org/software/bash/manual/bash.html

And I don't agree it's better to read the man pages.
They certainly don't cover many different ways to invoke or execute bash, not even just the few I mentioned.
And while it does cover subshells extensively, it's not exactly useful in answering my question either. That's kind of why you have teachers in similar situations in learning institutions. If there is something you don't understand, you can ask the teacher and they can try to help explain it in a way that you can understand. Two way communication, questions and all.

But hey, if you don't know either, it's ok to say so.

So, different contexts, yet again, even with the manual. And subshells is just a subquestion too, they aren't really THAT important. The main question is about different ways to invoke and execute bash. I mentioned quite a few, and I'm interested in some other (simple) ways that other people might know (that I don't).

I don't want to be snarky here, but please do fire up auditd, give the examples above a try and have a look at the differences. They most certainly ARE different, and in the security context that is highly relevant.

yes, the security context can be different. But if you can execute them the result will be exactly the same.

Well, the question in my post is quite simple actually, so the background doesn't/shouldn't matter anyway and would just be a waste of time and overcomplicate everything.

But, just briefly an example. My username can't do anything in bash at all, except launch Wayland and..
Which means my user can use sh, but the only thing the user can do in sh is execute that "secret" file. And even though the file just contains /bin/bash, my user can't execute /bin/bash without that file. And if it was another file /folder/file2 containing the exact same thing, my user wouldn't be able to execute bash that way either, nor can the user /bin/bash /folder/file1.

Because it's all different contexts. Anyways, where things get more interesting and complicated is root, because you could/want to do much more. So context is absolutely super important in creating say 10 different instances (unique execution context) of /bin/bash that can only do certain things. But also if you want a "secret bash" that isn't that strict.

Anyways, that's not the only reason, but some of the background for the weird questions. But also in further understanding some non typical bash stuff that isn't included in standard documentation, but rather things that people "find out" with experience. Anyways, I do think we all know a bunch of different stuff that isn't easy to learn or understand, and that we can all learn from each others and draw from the experiences of eachother as well.

So I guess subshells might be a dead end in regards to "different ways to execute bash".. And thanks to everyone for contributing, it has been immensly helpful in experimenting further and trying to understand how bash actually works, looking at it from outside of bash, and how shells work together. I still think I would have a bit of an issue drawing a diagram with the difference between subshells and nested shells though

Anyways, back to the different ways to execute bash, is not only interesting to me in the context of bash, but also interesting in regards to different ways to execute anything, outside of exec/fork, like forcing executions through certain binaries, and what kind of binaries are actually able to do simple executions in a simple way.

there is no other way to start a process, but clone/fork and exec.
Subshell is just a new [bash] process started by the parent process.