[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #17, bug #15718 (project make): Okay, I've found the culprit: setting SHELL from the command-line arguments wasn't handled as setting it from the Makefile. I think that's a bug (the Unix version doesn't handle SHELL in any special way when it comes from the command line), so I

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #16, bug #15718 (project make): Thanks. Does it work if you put SHELL=cmd inside the Makefile? That does work for me. The fact that it doesn't work with setting SHELL from the command line might mean there's another place in the code where the special treatment of cmd shoul

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #18, bug #15718 (project make): OK, I've applied Eli's patch. This bug/thread has gotten way out of control: I can't determine what's actually a real problem and what's just a misunderstanding. Can one or more of the principles followup with a comment clarifying what the real

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #19, bug #15718 (project make): The real bugs wrt SHELL that still need to be worked on are: 1. When the Windows port searches along PATH for a shell whose name is not cmd, it does not try to append the executable extensions, so SHELL=foo would not find foo.exe 2. If the value

Re: [bug #15718] Weird behavior of the SHELL variable on Win32

> Date: Sat, 4 Mar 2006 20:17:20 +0200 > From: Eli Zaretskii <[EMAIL PROTECTED]> > > The fact that it doesn't work with setting SHELL from the command line might > mean there's another place in the code where the special treatment of cmd > should be added. Hmmm... Fixed thusly: 2006-03-04 Eli

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #15, bug #15718 (project make): Hmm...here is the screen-shot: D:\Agent2002\AISystem1.0\SVK\de\UniSimu\Methodology>win32-make SHELL=cmd test dmd -quiet binary_tree_set3.d Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. D:\Agent2002\AISystem1.0\S

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #13, bug #15718 (project make): Well, you can't assume that just because _on UNIX_ make forcibly adds a -c to every $(SHELL) invocation, that it also does the same thing in the other ports. There's a lot of special code to handle different types of "shell" on Windows; Eli etc.

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #14, bug #15718 (project make): Paul is right: the Windows port does not invoke cmd.exe with the -c switch. So there's no bug here and nothing to fix. Here are the gory details: If you look closer at job.c:construct_command_argv_internal, you will see that, in the `slow' case

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #12, bug #15718 (project make): > P.S. In general, I think that setting SHELL to anything but a > shell, either cmd.exe or some version of Unixy shell, is > playing with fire If I'm not misunderstanding you, the Win32 build of GNU make 3.81rc is supposed to work with cmd.exe, r

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #11, bug #15718 (project make): Well, Perl is not a simple-minded shell with simple quoting rules, as one example. The entire point of SHELL is that you can set it to a command which can handle lines that are as complex as you like, and with a completely arbitrary syntax. Mayb

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #10, bug #15718 (project make): I'm not sure it's a bug in the Windows port that an arbitrary value of SHELL does not immediately "goto slow"; after all, it's hard to imagine radically different quoting rules for the relatively simple-minded shells we have on WIndows. But I wil

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #9, bug #15718 (project make): Just a note: changing SHELL _shouldn't_ be dangerous in the way you mention, Eli. On UNIX, at any rate, if SHELL is not set to an acknowledged value for a Bourne shell then make doesn't even try to use the fast path: all invocations of commands ar

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #8, bug #15718 (project make): Here's a response to Comments #2 and #5: It's not true that ``SHELL variable assignment within Makefile doesn't work for Win32 port of GNU make''. It's just that it's a bit tricky, and also your test Makefile was too simple to force Make to invok

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #7, bug #15718 (project make): Let me clarify: Comment #6 is for Doug Konrad. ___ Reply to this item at: ___

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #6, bug #15718 (project make): Please try the pretest version of Make 3.81 (beta4). This problem should be fixed in that version. ___ Reply to this item at:

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #5, bug #15718 (project make): I was just trying to get the native W32 build to work, as I'm upgrading our build systems from 3.74 to 3.80. We use cmd.exe almost exclusively, and the W32 build broke the system because it refused to use cmd.exe. I examined the source, and in va

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #4, bug #15718 (project make): Hi, Paul~ Everything you said is very true. I'm a Perl programmer and I know what `perl foo' and `perl -e foo' do. And I know GNU make always sends `-c' to the shell as well. Furthermore, I also quite agree the idea of SHELLFLAGS and the current w

[bug #15718] Weird behavior of the SHELL variable on Win32

Follow-up Comment #3, bug #15718 (project make): If you want to have Perl execute a program on the command line you have to give it the -e option (see the Perl manual). Running "perl foo" causes Perl to try to execute the file named "foo". If you want to run a Perl script on the command line, w