0

I recently stumbled upon applications that apparently are run purely through the command line. One of such applications is Git.

When I run it in cmd.exe, bash or powershell I usually first specify the path leading to git.exe and then type in my commands. Git then does something and the next time I have to do the same thing again.

I have always thought that what happens is that with every command git.exe is called, retrieves the user commands through the function parameters in main(int argv, *char[] argc) does it's thing and terminates, meaning that between each user command it actually closes.

But is that true? And is that generally the case?

2
  • 1
    It's true for git but not in general. there are many command line programs that will stay open until closed by the user and will keep processing input. cmd is one of the them. it will run until you type exit.
    – DavidPostill
    Sep 24 at 16:41
  • The answer is that it depends. Frankly, more programs run without a UI than with. For every program running on your computer that has a GUI, there's 10 or more. That are running all the time without one. There's nothing inherent in a program that requires it have a GUI, just that it do what's intended. Sep 26 at 3:50

3 Answers 3

1

Generally, yes. Every new command run from the shell is a whole new process that is spawned or fork/exec'd (except for those built-in to the shell), and whenever you return to the shell's prompt, this means the previous process has exited1. (Indeed once the shell forks, its main process usually does nothing else but call waitpid() and wait specifically for the child process to exit, before printing a new prompt to stdout.)

The OS doesn't provide any built-in continuity between those invocations; each new git.exe starts fresh at main() and has to read the repository's state from the .git folder again.

Though, the opposite also applies: if a command doesn't return to the shell's prompt, but instead shows its own prompt (such as python.exe showing a >>> or diskpart.exe showing DISKPART>), then that means it is still running – everything that you enter at the >>> will be read by the same python.exe instance, until you finally exit back to the shell.

One way to find out is by looking at the process list – tasklist or Task Manager's "Details" will show the basics, but Process Hacker and Sysinternals ProcExp both provide a much clearer tree view of all processes currently running. (Meanwhile, Sysinternals ProcMon on Windows – or forkstat on Linux – can show process start/exit events.)


1 Also note that this is only about the initial process that the shell has spawned – it doesn't necessarily mean that its children have exited. (For example, Git operations will sometimes start a "git gc" process for background maintenance.)

One particularly relevant example would be the "git fsmonitor" process that Git might auto-start on Windows, which acts as a persistent in-memory cache for filesystem metadata – so by design it's meant to continue running after the first command and to allow further Git commands to connect to it somehow (e.g. via local sockets).

Another similar example found on Linux is GnuPG (the "gpg" command), which will start a "gpg-agent" process the first time you run it, and the next "gpg" invocation may connect to the existing instance of gpg-agent when it needs the agent's services.

So although your shell doesn't "reconnect" to the app but spawns a fresh git.exe process every time, the app itself may use some form of IPC to connect to a previously started background service.

3
  • "everything that you enter at the >>> will be read by the same python.exe instance, until you finally exit back to the shell." So when I run python in cmd.exe and see a >>> I am actually interacting with python.exe and no longer with cmd.exe? Does python.exe essentially hijack cmd.exe?
    – Aiko
    Sep 29 at 16:16
  • Hijack how? No, it doesn't interact with cmd.exe at all. The window where you're entering text isn't part of cmd.exe in the first place; it's displayed by a separate OS component (the "terminal") which relays input directly to whichever process is currently trying to read input, be it cmd or python.
    – user1686
    Sep 29 at 17:23
  • In particular, when cmd.exe spawns a child python.exe process, cmd then voluntarily waits for the python process to exit before using the console for itself again. When programs don't take turns gracefully (e.g. using & on a linux shell command to "background" the process) the resulting display can be very interesting.
    – Ben Voigt
    Sep 30 at 21:20
0

You are confusing two types console commands.
Some commands run a action and are done others open there own console. In the dos world a console example is diskpart. Has its own console commands to manage partitions on a disk and ends with an exit command.

There is no one hard and fast rule as to the behaviour of a console command. It depends on the complexity of the new console and if you want to make sure the user does not use the DOS command during the session or if your console command are the same as the DOS command but have completely different options.

0

It is unclear what you mean by 'it closes'.

If you have a simple program (f.e. the famous "Hello, world"), when you run it, the shell you're in typically forks&execs the program. At the end of the program, it ends. That is true for many utilities (such as ls, netstat et cetera).

A program can also wait for STDIN. If you don't provide a file name, grep, sed, cat and many others will sit and wait for STDIN. When the STDIN reaches end-of-file (^D in UNIX/Linux, ^Z in MS-dos etc.), the program ends its processing and ends the same way as the simple utilities.

Under MS-Dos, you could keep a program in memory, reacting to specific events. You would hook-up some interrupt-vectors to it and, instead of letting the program just end, you'd call a terminate-stay-resident. The most famous was the Sidekick editor.

Under Unix/Linux, a program may fork-off another program. So, a program can fork-off some infinite loop, and terminate while the infinite loop in the other part of the fork continuous to run. This is (very simply described) what many daemons do.

I'd expect Windows to have some similar construction as daemons, but I'm not really qualified to comment on that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.