www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/02/12/11:20:36

From: Andy Eskilsson <x-aes AT telelogic DOT se>
Newsgroups: comp.os.msdos.djgpp
Subject: Make using bash instead of 4dos.. does it work?
Date: 12 Feb 1997 09:19:11 +0100
Organization: Telelogic AB, Sweden
Lines: 78
Sender: x-aes AT ping
Message-ID: <ksiv3yxwqo.fsf@telelogic.se>
Reply-To: x-aes AT telelogic DOT se
NNTP-Posting-Host: ping.telelogic.se
Mime-Version: 1.0 (generated by tm-edit 7.101)
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Well here we go again, I asked previously about getting make to use
bash as shell, have explored a bit, but it still seems to use
4dos/command.

Lets walk through the readme.dos file for the make source.. 

   2. "SHELL=/bin/sh" -- or is it?

      Many Unix Makefiles include a line which sets the SHELL, for
      those versions of Make which don't have this as the default.
      Since many DOS systems don't have `sh' installed (in fact, most
      of them don't even have a `/bin' directory), this port takes

Well mine does! it has a directory /bin/ on all drives, containing
both sh and sh.exe (copies of bash.exe)

      such directives with a grain of salt.  It will only honor such a
      directive if the basename of the shell name (like `sh' in the
      above example) can indeed be found in the directory that is
      mentioned in the SHELL= line (`/bin' in the above example), or
      in the current working directory, or anywhere on the $PATH (in
      that order).  If the basename doesn't include a filename
      extension, Make will look for any known extension that indicates
      an executable file (.exe, .com, .bat, .btm, .sh, and even .sed
      and .pl).  If any such file is found, then $SHELL will be
      defined to the exact pathname of that file, and that shell will
      hence be used for the rest of the processing.  But if the named
      shell is *not* found, the line which sets it will be effectively
      ignored, leaving the value of $SHELL as it was before.  Since a
      lot of decisions that this port makes depend on the gender of
      the shell, I feel it doesn't make any sense to tailor Make's
      behavior to a shell which is nowhere to be found.

I also have a sh and sh.exe neighbour to bash.exe in the djgpp/bin
dir.

      Note that the above special handling of "SHELL=" only happens
      for Makefiles; if you set $SHELL in the environment or on the
      Make command line, you are expected to give the complete
      pathname of the shell, including the filename extension.

      The default value of $SHELL is computed as on Unix (see the Make
      manual for details), except that if $SHELL is not defined in the
      environment, $COMSPEC is used.  Also, if an environment variable
      named $MAKESHELL is defined, it takes precedence over both
      $COMSPEC and $SHELL.  Note that, unlike Unix, $SHELL in the
      environment *is* used to set the shell (since on MSDOS, it's
      unlikely that the interactive shell will not be suitable for
      Makefile processing).

Hmm I set the SHELL environment variable to point to my (complete
path) bash.exe, when I type $SHELL on a line by itself it starts a new
shell. Haven't tried comspec though.. 

      The bottom line is that you can now write Makefiles where some
      of the targets require a real (i.e. Unix-like) shell, which will
      nevertheless work when such shell is not available (provided, of
      course, that the commands which should always work, don't
      require such a shell).  More important, you can convert Unix
      Makefiles to MSDOS and leave the line which sets the shell
      intact, so that people who do have Unixy shell could use it for
      targets which aren't converted to DOS (like `install' and
      `uninstall', for example).

Well even after my hard tries, the makefile works best when I change
the line SHELL=/bin/sh to SHELL=bash in the makefile :-( (I get errors
like unexpected end of file, it doesn't expand commands and so on)

ARRGH!

	/Andy

--
 Bill Gates should limit his salary to the number of bytes 
 addressable by the latest version of MS-DOS, and be taxed 
 based on the number of bytes of RAM needed by the latest 
 version of MS-Windows

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019