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

[Paul Leder <sa212+mingw@xxxxxxxxxxx>]

I've had a lot of useful help here, so I shouldn't be rising to the 
bait. But...

Keith Marshall wrote:
> On Thursday 07 February 2008 22:55, Paul Leder wrote:
>> 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.
> 
> Then you need to remove your blinkers, and broaden your horizons.  Let's 
> see; just off the top of my head: for MS-DOS, there were 4DOS, DJGPP 
> and the proprietary MKS Toolkit, all of which replaced command.com; the 
> latter two provided Unixy shells.  On Woe32, besides Cygwin, there is 
> Microsnot's own SFU, (a.k.a. Interix), MSYS, AT&T's UWIN, DJGPP and MKS 
> again, and also several native ports of various Unix shells; there is 
> also the non-Unixy 4NT, as an alternative to cmd.exe.

My day job is (Electronic) Engineering. The people who will, or may, use 
this software are EE's. They don't have "blinkers"; they have real jobs. 
I'm afraid that they couldn't care less about this stuff, which makes it 
pointless for me to support it or even know about it. I do know 
*exactly* what a lot of EEs use for their work, though.

>> Just parsing PATH is useless to me. I could look for a
>> host of shells in all locations in PATH,
> 
> You don't have to parse the PATH; spawnlp or spawnvp will take care of 
> that for you...

As does CreateProcess. But, if Cygwin isn't in the path, and there's no 
reason that it should be, then it's pointless for me, or any program, to 
parse the path looking for a list of shells.

>> but (1) if it's a Cygwin PATH then it's no use because it won't make
>> sense to 'CreateProcess' 
> 
> You don't tell spawnlp or spawnvp what the PATH is; they get it for 
> themselves, from the environment, and they shouldn't ever see a Cygwin 
> PATH, in a native executable, so...
>> until it's been through 'cygpath -m' anyway,
> is completely irrelevant.  

One of us is getting confused. 'cygpath -m' turns an internal Cygwin 
path into something that can be understood by MS. CreateProcess does not 
  find something specified Cygwin-style. My understanding of MSYS is 
that it gets around this problem, but unfortunately MSYS is not used by 
the people who might use this software.

>> and (2) the 'shell' may turn out to be a completely irrelevant
>> Windows program called, for example, ksh.exe.
> 
> Huh?  Any program called ksh.exe *should* be a Korn shell; 

In *Windows*?? I pick up PATH, on a Windows machine, search the entries, 
and find a program called ksh.exe? Surely it's not exactly prudent to 
execute that program, in the hope that it's a Korn shell? *Thats* why 
'cygpath' is so useful. If cygpath understands /bin/sh, then I can be 
almost ceratin that the return value is a proper shell.

> that is more 
> than capable of handling any Bourne shell commands you pass to it, and 
> if it isn't a Korn shell, then the user who installed it *deserves* all 
> the grief which ensues.  

These guys work for a living; they run the hardware and software that 
they're given. I can't guarantee that there's nothing on a Windows 
machine that offends the sensibility of *nix users, and they can't 
either. They don't deserve "grief"; what they do deserve is that I've 
done my job properly, and I don't deliberatly mess them up because they 
don't agree with my, or your, world view.

> Yet you started out by asking about bash, which you now reject.  

I don't reject it; I've got no problem with it. I prefer /bin/sh because 
it appears that any *nix system should have it, which would make a 
search for bash redundant. 'system' doesn't run /bin/bash; it runs 
/bin/sh. Of course, this is not my day job; correct me if I'm wrong.

> I really couldn't care less what you do; I shall 
> not be using your software.  The code in the exec wrappers works fine 
> for me, and for the Woe32 port of GNU troff, in the MinGW port of man, 
> and probably in other projects, of which I am unaware.

I don't actually have an issue with that. As I said, I'm grateful for 
the advice I got; I weighed up the information I got about the exec 
wrappers, and adopted a different solution, with the benefit of 
additional advice. I am still confused about the execwrappers, though. 
Do they really start by looking for SHELL in the environment? Are they 
meant to run on Cygwin? Cygwin doesn't export SHELL, the user has to do 
it himself. How is this meant to work? If the end-user has to export 
SHELL for the benefit of execwrappers, then why can't the user just 
manually tell the software what shell to run anyway? And how does all 
this impact the naive user who simply wants to run their application?

Go back and look at your 1-2-3 process for locating shells. If my 
end-user is running my program from a DOS box, then the search procedure 
does *not* work. It will use cmd.exe even if there is a Cygwin /bin/sh 
on the system. Even worse, it may attempt to use the "ksh.exe" Windows 
program we talked about above.

The end-user may then decide to double-click the Cygwin icon, and run my 
program from the "Cygwin box". It makes no difference. SHELL is not 
exported. PATH contains the normal *nix paths, followed by a cyg-ified 
Windows PATH. How is your 1-2-3 going to find

> the first of bash, ksh, pdksh, zsh, ash, sh, tcsh or csh 

The only conceivable way it could do it is with the help of cygpath, and 
even then you have no idea whether you're running a rogue Windows 
program or a proper shell.

-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