What does the bash option -i actually do when bash is invoked from Python?

If I run following Python script on Linux Mint 21 Cinnamon edition with Python 3.11.2:

import os
T = "gnome-terminal"
os.system(f'{T} -- python -ic"import os; os.system(\'resize -s 5 32\')"')
os.system(f'{T} -- bash   -ic "resize -s 5 32"')

it creates following two Terminal windows:

UPDATE as reaction to a comment by Cyrus requesting to provide text instead of an image: if I replace the image with the text it would give in case of the first window:

COLUMNS=32;
LINES=5;
export COLUMNS LINES;
>>> 

and in the case of the second window:

The child process exited normally with status 0.

making it as good as not possible to directly see what the question is about. Images are sometimes the much better option.

Notice that both of the script lines are doing the same job and are using the same command line options. The line using Python does not require a space between -ic and the string. The line with bash does. In this context a question:

What is wrong with my expectation that both lines should give an interactive Terminal window?

The first line results as expected in an interactive Python session, but the second line fails to give an interactive session and wouldn't rise a Terminal window at all when in the Terminal settings the option to stay opened after the child process exits wouldn't be checked.

I would be glad if someone in course of giving an answer to my question could also explains why the line with bash needs the space where the Python line doesn't and how to tweak the code creating the interactive Python session so that it will fall back to a bash shell prompt instead of exiting the Terminal window if Python exits.

UPDATE as reaction to comment by Charles Duffy:

The info bash command gives as an explanation of the -i option for bash: -i If the -i option is present, the shell is interactive. and man bash gives the same explanation. Interactive when not running??? Has the word interactive another meaning? Which one?

After reading the details of the bash -i option as suggested in the comments it turns out that the word interactive is severe misused here and means the opposite of what I would expect from it. So if I want the shell to respond to the provided code I have to run the shell NON-interactive. OK. In this context it seems that my actual question should be:

> If your real question is ("how do I get bash to run some arbitrary code and then drop to an interactive shell?", then maybe ask that directly. – Charles Duffy

Below my attempt to use subprocess:

from subprocess import run
run([f'{T}', '--', 'python', '-ic', '"import os; os.system(\'resize -s 5 32\')"'])
run([f'{T}', ' -- bash ', '-i' , '-c', '"resize -s 5 32"'])

The code above does not resize the first window and gives following Error message on the second one:

# Failed to parse arguments: Unknown option -i

Corrected the code for the second window to:

run([f'{T}', '--', 'bash ' , '-i' , '-c', '"resize -s 5 32"'])

Now both windows are created without resize and the second one gives:

# Error: Failed to execute child process “bash ”: Failed to execve: No such file or directory

As described in the duplicate at https://stackoverflow.com/questions/4584736/bash-execute-command-but-continue-with-interactive-session, --rcfile can be used to pass bash code to run on startup:

import tempfile, subprocess

with tempfile.NamedTemporaryFile(prefix='bash-rcfile') as tf:
  tf.write(b'resize -s 5 32\n')
  tf.flush()
  subprocess.run(['gnome-terminal', '--', 'bash', '--rcfile', tf.name, '-i'])

In the world of programming where you need your code to have been written exactly according to the maybe hard to understand rules, you can use another approach to achieve your goal relying only on the user interface GUI of the applications instead of their API exposed for usage in programming.

This way you just start a Terminal and then use an automation tool like for example pyautogui to start Python in the already running interactive Terminal with a bash prompt.

It is a very simple to go path and will work the same way for any shell in any system environment, so you don't need to cope with cases where the software has bugs in the programming or command-line API or does not implement expected internal standards focusing only on providing a well functioning user interface.

An apparent advantage of this approach is that you can SEE yourself on the screen what is done on the path to the result.

Try the code below to obtain the required window size and a running Python shell session which if finished will end up with still opened Terminal window and a ready to use shell:

import os
import pyautogui
import time
from subprocess import run
run(["gnome-terminal","--geometry=32x5"])
time.sleep(0.25)
pyautogui.write("python\n")

Sure ... such approach CAN and will fail if exposed to some conditions like fast user multitasking or system based reasons.

Actual it seems that a 0.25 sec. time span (on my machine 0.1 is already enough) between starting a window and sending it keystrokes is sufficient to make the code work as expected.
And if not ... just increase this value ... hoping to not face weird circumstances. And avoiding switching to another windows within tenths of a second .

Let's summarize what was said in the comments and what was provided as answers and along with doing that actually answer your prime question phrased as What is wrong with my expectation that both lines should give an interactive Terminal window?

The problem with your expectations is twofold. The first aspect of your (failing facing the facts) expectation is to expect that in a Terminal started Python session will fall back to a bash prompt if exited. The Terminal can't fall back into the bash session in that case just because when the Terminal starts the Python session bash isn't involved at all and the Terminal communicates directly only with Python. So there is no bash here to fall back to when Python exits.

The second aspect is to expect that a -i option of the bash command short explained in ~ $ man bash and ~ $ info bash as If the -i option is present, the shell is interactive will make the bash started with this option not exiting but staying interactive. In other words the core of experienced confusion is to expect that a word in a software manual mirrors its intuitive and usual spoken language meaning.

In the world of software if running into confusion it may be necessary to look at the very details in the user manual to see what a used word actually means. This is here the case for the -i option of the bash shell and the reason for this is most probably of historical nature and can be short nailed down to the fact that a started bash when given something to do just does the job and exits.

To keep the shell alive when given some preliminary commands it is necessary to use its -i option along with providing the preliminary commands as content of a bash script which file name is to specify using the long --rcfile option followed by the short -i option as the other way around just does not work probably because of the necessity to fulfill some POSIX standards. By the way: you may (haven't tested it yet) set a BASH_ENV environment variable before starting the shell instead of using the --rcfile option.

While what is stated above already fully answers your question let's give here as nice add-ons and for the sake of completeness also the Python code from the answer to your question provided by Charles Duffy and some further explanations given in the comments:

The code below is able to get the bash shell to do some preliminary work and then still stay alive in the Terminal when its job of resizing the terminal window and/or starting a Python session is done.

The code uses the more modern subprocess module instead of an os.system() call which (saying it with words by Charles Duffy) "creates an extra copy of /bin/sh, with all the extra complexities that come from needing an extra layer of escaping on top of your command (instead of being able to just pass the argument vector directly)". The code requires also the usage of the in Python distribution available tempfile module as a work around for creating an actual file bash then can get its preliminary commands from:

import tempfile, subprocess

with tempfile.NamedTemporaryFile(prefix='bash-rcfile') as tf:
  tf.write(b'resize -s 5 32\npython\n')
  tf.flush()
  subprocess.run(['gnome-terminal', '--', 'bash', '--rcfile', tf.name, '-i'])

The code above creates a Terminal window with an in it running interactive Python session and the special coded feature here is that when the Python session is exited, the Terminal window stays alive and open providing a bash shell prompt.

For the sake of completeness here also the explanation how it comes that the one line in your code runs ok without a space and the other does not (provided in the comments to the question by Socowi):

> Short answer: Every program decides how to interpret its options. Longer answer: Because every program decides on its own what to do with its options, -i can have an entirely different meaning between two different programs. They don't even have to accept options like -i but could even decide to use things like °:#§i__. Same goes for (optional) spaces. Complete Answer: The actual meaning of python -i and bash -i options can be found using ~ $ man python and ~ $ man bash. –
Socowi

By the way: instead of using resize to set the geometry of started Terminal window you can directly use the --geometry parameter supported by gnome-terminal setting at the same time not only the size, but also the position of the created Terminal window:

from tempfile   import NamedTemporaryFile as ntf
from subprocess import run
with ntf() as tf:
  tf.write(b'python\n') # commands for the job to be done by the shell
  tf.flush()
  run([ 'gnome-terminal', '--geometry=32x5+200+200', '--', 
            'bash', '--rcfile', tf.name, '-i'])

NOTICE in the code above that X,Y (i.e. width and height) specified in the --geometry option should be swapped compared to their order in resize -s

FINALLY The question What does the bash option -i actually do when bash is invoked from Python? would need much of further text for accurate explanations. One is sure: the -i alone isn't enough to make bash interactive. The code above provides a usage case for this option which does what was requested in the question. This should be enough as an answer.