Unix-head needs to Windows-ize his Python script (II)

[Nobody]

No, we're not talking about whether apps invoke GUI functions or not.
That's completely orthogonal to the issue at hand. We're talking
about whether desktop manager should run the program with
stdin/stdout/stderr connected to /dev/null or connected to a terminal
emulator.

The windows desktop determines that (like it determines other things)
by looking at the filename. Other desktops generally have that
information associated with the icon/button/menu-entry, not with the
executable's filename.

Windows executables contain an embedded type field which distinguishes
between GUI and console executables (as well as those for the POSIX
subsystem, "native" executables, etc).

python.exe is a console executable, pythonw.exe is a GUI executable. Hence
python.exe automatically gets a console window, while pythonw.exe doesn't.
That's the whole reason why Windows has separate python.exe and
pythonw.exe programs, while Unix can use a single /usr/bin/python program
for both GUI and console usage.

The Windows approach makes it easier to Do The Right Thing automatically,
but it's a nuisance if you have a program which doesn't really fit into
either of the "console" or "GUI" pigeonholes.

 

[Lawrence D'Oliveiro]

python.exe is a console executable, pythonw.exe is a GUI executable. Hence
python.exe automatically gets a console window, while pythonw.exe doesn't.
That's the whole reason why Windows has separate python.exe and
pythonw.exe programs, while Unix can use a single /usr/bin/python program
for both GUI and console usage.

The Windows approach makes it easier to Do The Right Thing automatically
...

Except it provides no easy way to capture the contents of that “consoleâ€,
for when you’re trying to track down problems, because it disappears as soon
as the program exits.

It would be a stretch indeed to call this “doing the right thingâ€,
automatically or otherwise.

 

[Lawrence D'Oliveiro]

(The Amiga made it simple -- a shell invocation received a non-zero
argc, with command line parameters in argv; a "clicked" invocation
received argc of 0, and argv pointed to a structure containing the
information from the associated .info file [Workbench only displayed
icons from .info files, unlike Windows displaying everything]).

Why would you want both CLI and GUI functions in one program? The *nix
philosophy is that a program should do one thing, and do it well.

That means a command-line tool should concentrate on being a good command-
line tool. For users who want to access that functionality through a GUI,
you build a GUI front end which makes use of that tool, and possibly others
as well, at the back end.

That way, you end up with a minimum of complexity and duplication of
functionality, and a maximum of flexibility and power.

 

[Nobody]

Why would you want both CLI and GUI functions in one program?

An obvious example was the one which was being discussed, i.e. the Python
interpreter. Depending upon the "script", it may need to behave as a
command-line utility (read argv, do stuff, exit), a terminal-based
interactive program, a GUI program, a network server, or whatever.

Forcing a program to choose between the two means that we need both
python.exe and pythonw.exe.

A less obvious example is a program designed to use whatever interface
facilities are available. E.g. XEmacs can use either a terminal or a GUI
or both.

 

[Dave Angel]

Except it provides no easy way to capture the contents of that “console”,
for when you’re trying to track down problems, because it disappears as soon
as the program exits.

It would be a stretch indeed to call this “doing the right thing”,
automatically or otherwise.

Once I realized you had no objective other than Windows bashing, I
dropped out of this thread. If the answer to this present
pseudo-complaint isn't obvious to you, you clearly don't know Windows.

DaveA

 

[Lawrence D'Oliveiro]

Once I realized you had no objective other than Windows bashing, I
dropped out of this thread.

And yet here you are back again, like a bad smell.

If the answer to this present pseudo-complaint isn't obvious to you, you
clearly don't know Windows.

I was just going by what was said in another thread:

As you've noticed, many times a program started from the start menu
doesn't leave its command window open long enough to read the messages.

Maybe it was the write of this who “clearly doesn’t know Windows�

 

[Lawrence D'Oliveiro]

An obvious example was the one which was being discussed, i.e. the Python
interpreter.

But the Python interpreter has no GUI.

Depending upon the "script", it may need to behave as a command-line
utility (read argv, do stuff, exit), a terminal-based interactive program,
a GUI program, a network server, or whatever.

For all the sense your argument makes, you might as well say the same thing
about the C run-time library.

Forcing a program to choose between the two means that we need both
python.exe and pythonw.exe.

And yet we get by just fine without this dichotomy on more rationally-
designed operating systems.

A less obvious example is a program designed to use whatever interface
facilities are available. E.g. XEmacs can use either a terminal or a GUI
or both.

And yet it manages this just fine, without Amiga-style invocation hacks, on
more rationally-designed operating systems. How is that?

 

[Dave Angel]

And yet here you are back again, like a bad smell.

I was just going by what was said in another thread:

As you've noticed, many times a program started from the start menu
doesn't leave its command window open long enough to read the messages.

Maybe it was the write of this who “clearly doesn’t know Windows”?

Gee, maybe when "you're trying to track down problems", you might try
starting the application in a console?

 

[Nobody]

But the Python interpreter has no GUI.

It may have one if you use wx, tkInter, etc. So far as the OS is
concerned, it's all python.exe or pythonw.exe.

And yet we get by just fine without this dichotomy on more rationally-
designed operating systems.

For some definitions of "fine". A GUI-based launcher doesn't know whether
the program it's being asked to run actually needs stdin/stdout/stderr.
Either it spawns an xterm (etc) even if it's not necessary, or it doesn't
and the user can't communicate with the program, or it uses some arbitrary
set of heuristics ("does the program link against Xlib?", which fails if
the GUI portion is loaded dynamically).

And yet it manages this just fine, without Amiga-style invocation hacks, on
more rationally-designed operating systems. How is that?

Typically by not letting you usefully run terminal-based programs from
the GUI without first having to explicitly configure the invocation
options (e.g. creating a shortcut with "Use terminal" enabled).

 

[Gregory Ewing]

You mean “GUI consoleâ€. So non-GUI apps get a GUI element whether they want
it or not, while GUI ones don’t. That’s completely backwards.

The "G" in GUI stands for "Graphical". I wouldn't call a window that
displays nothing but text "graphical".

 

[Gregory Ewing]

I see how clicking directly on these files would obviate the need
to specify the path of the interpreter, but it's still not clear
to me how the interpreter would know where to look for the myscript.py
module that both the GUI scripts require.

If it's in the same directory as the GUI script, or in some
known location relative to it, you should be able to locate
it based on the fact that sys.path[0] starts off containing
the pathname of the directory containing the running script.

 

[Lawrence D'Oliveiro]

The "G" in GUI stands for "Graphical". I wouldn't call a window that
displays nothing but text "graphical".

And yet it takes a GUI to display it.

 

[Lawrence D'Oliveiro]

Gee, maybe when "you're trying to track down problems", you might try
starting the application in a console?

On a rationally-designed OS, I have a choice. I can do that, but that’s not
really my first resort: the first thing I can do is check in ~/.xsession-
errors to see if there are already some useful messages that might
illuminate the issue.