Detect Environment

igoryonya has asked for the wisdom of the Perl Monks concerning the following question:

Hi, I was wondering if it's possible to detect where the script was launched from. I need to be able to detect if the script was launched from the console window or from the window environment by using a shortcut or some GUI file manager.

The purpose is: If the program was launched from the console, it will be outputting directly to console. I mean, running with it's text version interface, but if it was launched from the GUI by a file manager or a shortcut, or whatever (NOT console), it will be launched in it's GUI Window (not text) interface with buttons etc.

I can't use ENV variable to test if it's console, because perl says that it's console, unless it's ran as a CGI.
And no, I don't want to pass parameters in the shortcut or the command line, to specify that it's GUI. I just want to be able to type or double-click on the script file.

I know that it's possible, because, a long time ago, a Creative sound card came with a music player with the drivers installation. It could launch a text version of the player in the dos window when you type it's executable from the dos window, but when it was launched from the file manager by double-clicking on the executable, it launched it's GUI version.

So, in other words, when the script detects that it was being typed in the console to launch, it will use console interface subroutine (STDIN/OUT, etc.), but when it detects that it was launched not from the console, it will go to the Tkx subroutine for the GUI interface.
Thanx.

Comment on Detect Environment

Replies are listed 'Best First'.
Re: Detect Environment by almut (Canon) on Dec 09, 2009 at 16:49 UTC
Maybe check `-t STDIN` (would test if STDIN is opened to a tty) — see filetests	[reply] [d/l]
Re^2: Detect Environment by Crackers2 (Parson) on Dec 09, 2009 at 17:01 UTC
Another option is to check if the DISPLAY env var is set, and open up graphical if it is. I think that's the behaviour things like emacs use for example. It does mean that if you open a console from your GUI and then start the program from there, it'll open up with the GUI, which seems to be slightly different from what you describe although more intuitive. (Update: "You" in the above means the OP of course, not almut)	[reply]
Re^3: Detect Environment by roboticus (Chancellor) on Dec 09, 2009 at 18:18 UTC
Crackers2: FYI: It's a frequent case where you have a console window open on an XTerm. Then you'd be on a console, but you'd still have DISPLAY set. ...roboticus	[reply]
Re: Detect Environment by ikegami (Patriarch) on Dec 09, 2009 at 17:32 UTC
If your make your two programs, one being `#!/bin/sh program --gui $*` [download] Then you can just click on it, it's never ambiguous, and you let the user control which one he wants if he wants to be specific. Altenatively, you could accept --console and --gui to force one, and use heuristics if neither is specified.	[reply] [d/l]
Re^2: Detect Environment by JadeNB (Chaplain) on Dec 10, 2009 at 01:14 UTC
There's also the popular “hard-links that investigate `$0` approach”. While we're chatting about shell scripting, I think `"$@"` (in Bash, not Perl!) gives a more robust approach to grabbing command-line arguments.	[reply] [d/l] [select]
Re: Detect Environment by cdarke (Prior) on Dec 09, 2009 at 17:58 UTC
Assuming that you are running on Microsoft Windows. The Creative sound card software could have inspected the STARTUPINFO structure used to create the process by calling the Win32 API GetStartupInfo. Processes started by Windows Explorer appear to have the dwFlags member set to (at least) STARTF_USESHOWWINDOW. Trouble is that Win32::Process does not expose that interface.	[reply]
Re: Detect Environment by GrandFather (Saint) on Dec 09, 2009 at 22:45 UTC
Long ago the 'DOS Window' was really and truly a DOS box and applications running in it had no access to the Win32 API. Windows Executables have a DOS stub that often simply generates an error message and exits. It's pretty likely that the Creative application provided the DOS interface in the stub and didn't do any detection of context at all - Windows did that for it and applied a little DWIMery. That solution doesn't work now because the since Windows 2000 the console is not a DOS box and the stub doesn't get executed. True laziness is hard work	[reply]