Re: [Mingw-users] How can I tell whether my prog is running on cmd.exe or bash?

[Paul Leder <sa212+mingw@xxxxxxxxxxx>]

Keith Marshall wrote:

>> if(
>>     (system(uname) looks sane) &&
>>     (system(cygpath -m /bin/sh) returns success))
>>       use CreateProcess with /bin/sh path returned by cygpath;
>>   else
>>       use CreateProcess with cmd.exe /c
> 
> Yuck!!!  That has to do a PATH search anyway, to find first uname, and 
> then cygpath.  

That's Ok, I think. I'm expecting the user to have crud in their PATH (I 
do, anyway, going back over an eternity of obsolete apps) but, if 
they're using Cygwin at all, then *that* should be in their PATH. If it 
isn't, then that's their problem; I fall back to cmd.exe.

> Furthermore, it *only* works when the Unixy shell is of 
> the Cygwin variety; what if your user has some other Unixy shell, and 
> would expect that to be used?

I have to confess that I didn't know that there were any other Unixy 
shells on Windows (I haven't looked at MSYS). Besides, I've worked in 
the industry I'm writing this app for for ~20 years, and I've never 
heard of anyone using anything other than Cygwin or plain DOS. The smart 
ones are on Solaris or Linux; the cash-strapped ones are on Cygwin; the 
amateurs are on Windows GUI apps.

Besides, I've got to draw the line somewhere at supporting obscure 
shells. It's hard work. Anything which is even vaguely Unixy must have a 
/bin/sh.

It's true that only Cygwin will have a cygpath, but I can't see how to 
get rid of that. Just parsing PATH is useless to me. I could look for a 
host of shells in all locations in PATH, but (1) if it's a Cygwin PATH 
then it's no use because it won't make sense to 'CreateProcess' until 
it's been through 'cygpath -m' anyway, and (2) the 'shell' may turn out 
to be a completely irrelevant Windows program called, for example, ksh.exe.

In short, I can't take the risk of executing some arbitrary Windows 
program just because it has the right name and happens to be on the 
path. Either it's /bin/sh, or nothing. Actually, the more I think about 
it, the less sense the exec wrappers stuff makes. Feel free to correct 
me... :)

> If you are trying to support a native Woe32 build, (which would appear 
> to be the objective when using MinGW), why bother.  Unless you *really* 
> need some Unixy shell feature, what is the point in looking for one; 
> just use `system( "command to be executed by cmd.exe" )' 
> unconditionally.

That's an option. The full story is rather complex and not related to 
what I asked, so I didn't go into it. But, in short, this program is a 
server that talks to a remote client, and the remote client will 
normally expect to execute a series of fairly noddy Unix-like commands 
on the server (a lot of them are just 'echo', for example). If this 
Windows program is running on Cygwin, I can oblige. If it's stuck with 
cmd.exe, then the remote client must manually adjust its expectations; 
even the humble 'echo' is next to useless on DOS.

> OTOH, if you *do* need a Unixy shell, then why require it to be 
> Cygwin's?  If you do that, then why use MinGW at all?  Just build your 
> application entirely with, and for Cygwin.

This end purpose of this program is to pay my mortgage, and get a large 
yacht with the change, so Cygwin isn't an option.

> If you need a Unixy shell, 
> *and* you want native behaviour *without* insisting on Cygwin, then the 
> code you need is already in MinGW's exec wrappers library.

I haven't looked at it because of the GPL issue you mentioned. Besides, 
my native-Windows code already works for the /bin/sh case; the issue is 
just knowing (reliably, or not, as it turns out) when I should use 
cmd.exe instead.

On the issue from your other post about exporting SHELL: it's probably 
obvious by now, but I don't have control of what the end-user does; the 
problem I'm having now is in my own testing. I can't ask the user to 
export $SHELL; I might as well just ask them to give me a command-line 
parameter telling me what their shell is. It did surprise me that the 
output of 'set' wasn't what I saw in environ, though; I use tcsh normally.

-Paul

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users