Why do many applications come with their own terminal instead of using the native shell?

[fog37]

Hello,

I recently started a thread about shell programs (CMD and Powershell for Windows, bash and else for Linux and Mac).

I noticed that many applications, like Git or Anaconda, VS Code, come with their own terminal...Why? Those "terminals" are really different shells or instances of the native shell but with some configuration setting already launched?

For example, Anaconda has the Anaconda terminal (which starts in the Anaconda base environment)...Git has Git bash, VS code has its terminal window...What advantage does this bring instead of using the native shell on our system?

Also, I have to say that it is getting confusing to learn commands from different shells....do you guys stick with just one shell and its scripting language? But it seems very useful to know both bash and Powershell so we can work with different OS...

Thanks!

 

[Filip Larsen]

The

instances of the native shell but with some configuration setting already launched

This. The general idea is to launch a shell window (command prompt) with the proper set of environment variables for a particular kind of work (git, python, etc.). Most commonly you would like the path variable set to allow the shell interpreter to find the desired executables without you have to type long path prefix every time. This pattern is quite universal across all shell interpreters and operating systems based on the POSIX standard and ties into how to launch processes with a known environment.

 

[fog37]

Thank Filip. Just to make sure, the environment variables are set (unless we change them). So launching this or that shell does not change the values assigned to the environment variables...But starting with a specific shell is like starting directly in a specific folder or virtual environment from the get go without having to type extra commands...

Is that correct?

 

[Filip Larsen]

I am not exactly sure what you are asking. You originally asked about starting a command prompt associated with some environment (e.g. Anaconda or git) and in that case the command interpreter is typically launched and given some specific environment settings (e.g. in a resource file) that will make sense in that particular work case, including current working directory. So in that sense, yes, launching a shell will typically modify the system environment a bit for that shell so that the shell has what it needs and so that additional executables started from that shell gets relevant environment variables set as well.

Note that environment variables set in a parent process is by default inherited by child process when it is started by that parent. For example, a git shell may setup git specific environment variables that will allow subsequent programs (i.e. typically the git executable itself) adapt relevant behavior based on those variables. This is a bit in contrast to having an application-specific configuration or project file (typically used for larger UI applications) that you then specify to all the executables that needs it (or it looks for one relative to the current working directory or using a search path environment variable). For example, the Visual Studio command line build system is an example of a set of executables that are highly configurable using a mix of both environment variables and configuration/project files.