#! /bin/bash

# $Header: /c/data/rcs/w2kpf.sh,v 1.3 2005/08/01 21:14:18 LongPhil Stab $

# This file is used to fix up the Win2K PATH environment variable.  I think that
# MIS is the culprit, if U will, that added this list to the PATH variable:
#        W:.;V:.;Z:.;Y:.;X:.;
# When this is converted to a CYGWIN PATH variable, the data is not converted
# correctly, so this script was written to rectify the path before BASH is in-
# voked in /cygwin.bat.
#
# So what, U may ask, is `correct?'  Good question!  In DOS/Win-land, the cur-
# ent directory is always in the path, while in U*IX-land, it is not unless it
# is explicitly added to the PATH variable.  Just in case this has changed in
# Win2K, I tested this by setting PATH to the empty string, then running a local
# .BAT file.  The .BAT file ran as expected, so explicitly adding `.' for each
# mapped drive would be pointless; therefore, the current directory on each
# drive must be what MIS intended to add to the PATH.
#
# To address this issue, I originally added a line to /cygwin.bat that echoed
# the PATH variable (in DOS/Win format) to a GAWK script that parsed out the
# current directories for each drive and replaced it with the actual directory
# name in CYGWIN format.  Unfortunately, since the pipe used to accomplish this
# was a DOS pipe, the data actually went to a file before going to the GAWK
# script.  The method was functional, but crude.  Since BASH pipes are real
# pipes, not temporary files, using them is the better solution.  Unfortun-
# ately, I forgot that although the PATH length is (apparently) unlimited in
# MSland, the command-line LENGTH is not, and when I passed it on the command
# line after pcNowhere added its path to the PATH in the registry (the 'system'
# environment settings), the maximum command-line length was exceeded, and
# this script failed to execute.  One would think that examining the PATH in
# the environment would be the answer, but CYGWIN _changes_ the PATH to be
# POSIX-compliant, so that won't work.  Therefore, we pass the PATH in an en-
# vironment variable which CYGWIN doesn't touch:  XJX (see /cygwin.bat).
#
# The first thing to do is to look for a file (/wPATH) which is assumed to
# hold the FIXED-UP DOS path.  If this file is not present, it must be created
# AFTER fixing the DOS path.  Next, the contents of /wPATH are compared to the
# current DOS path, which is passed in XJX.  If the two are the same, we exit
# with SUCCESS so that BASH may be invoked by CYGWIN.BAT; otherwise, fix up
# the path and compare to the contents of /wPATH again.  If they are the same,
# exit with SUCCESS so that BASH may be invoked; otherwise, overwrite /wPATH
# with the fixed-up path.
#
# In some cases, it may not be desirable to overwrite /wPATH.  To accomodate
# these cases, argument 2 is examined; if it is present (any value), and there
# is a conflict in the contents of /wPATH and the fixed-up PATH, the former
# prevails and /wPATH is NOT overwritten.  Thus, the default behavior ($2 NOT
# present) is to overwrite /wPATH.
#
# Finally, one of the problems I had before the last Heidelberg Client (HC)
# update was the things like "%SYSTEMROOT%," which appeared on the environment
# tab, showed up LITERALLY in the PATH string, which meant that most DOS/WIN
# utilities were unavailable to any program started from a CommandPrompt box.
# At the time, I echoed the PATH string to a .BAT file, which thus replaced
# any such literal environment variables with their contents, no matter WHICH
# variables were giving me problems.  The problem with this method was that,
# like the relative-path fix, a DOS pipe/tempfile was involved.  Since the
# PATH string is now passed as an environment variable, the SAME replacement
# as before occurs, and NO tempfiles are involved.
#
# ---------------------------------------------------------------------------- #
#
# $Log: w2kpf.sh,v $
# Revision 1.3  2005/08/01 21:14:18  LongPhil
# 	o Changed header comment to mention XJX environment variable
# 	  instead of first command-line argument so that it reflects
# 	  what actually happens, rather than the older method.
#
# Revision 1.2  2005/04/29 21:58:12  LongPhil
# 	o Changed method of passing in PATH from command-line argu-
# 	  ment number 1 to inside XJX environment variable so that
# 	  CYGWIN doesn't change its value, as it would were we to
# 	  examine the contents of PATH, and so that the PATH is not
# 	  restricted in length, as it was when passed in on the com-
# 	  mand line (NT command line is limited in length - STILL!).
# 	o Since we are no longer looking on the command line, it no
# 	  longer makes sense to check for the number of arguments,
# 	  so removed that check.  We only need to check what is in
# 	  XJX, and if XJX is missing or zero-length, since we have
# 	  the same effect, put out the `zero-path-length' warning
# 	  message, which was already there.
# 	o As a minor efficiency matter, it is quicker to check the
# 	  value of a condition than to check its iiverse, so switched
# 	  the `/wPATH' if/else code and removed the inverse from the
# 	  conditional.
#
# Revision 1.1  2002/11/06 23:59:01  LongPhil
# Initial revision
#
# ---------------------------------------------------------------------------- #
#



# First, make sure that something (hopefully %path%) was passed in XJX in the
# environment.  If not, that's YOUR choice, but warn the user.
if [ ".$XJX" == "." ];then
   echo -e -n "\n\tUH-oh"'!'"  PATH string is ZERO-LENGTH"'!'"  No Win" > /dev/stderr
   echo -e "dows utilities will\n\tbe available"'!'"\n"                 > /dev/stderr
fi

# Next, check for presence of /wPATH.
if [ -f /wPATH ];then
   # Set `wpath' to contents of /wPATH file and clear create flag.
   createWP=0
   wpath="$(/usr/bin/cat /wPATH)"
else
   # /wPATH is missing, so set a flag to create it.
   echo -e "\tWARNING:  File /wPATH is missing and will be created."    > /dev/stderr
   createWP=1
   wpath=""
fi



# Now fix up the path.

# X will contain the fixed-up PATH string.  It will be in DOS format (back-
# slashes and drive letters), except that all relative paths (W:., etc.) will
# be replaced with their CYGWIN equivalents.  When BASH starts up, all these
# will remain unchanged ... and CORRECT.

x="$(echo "$XJX" | /usr/bin/gawk -f /fixWin2Kpath.awk)"

# Check for unchanged PATH string.
if [ "$x" == "$wpath" ];then
   # PATH unchanged since last check; exit with SUCCESS.  Since we are touching
   # neither /wPATH nor /bin/x.BAT, expecting the latter to be executed next,
   # we need to delete the former above (no PATH passed in) so that BOTH will
   # be re-created when the problem is fixed.
   exit
fi



# UH-oh; PATH has changed since last check!

# If /wPATH isn't there, create it and exit, so long as PATH is NOT zero-length.
if [ $createWP -gt 0 ];then
   if [ ${#x} -le 0 ];then
      # UH-oh; zero-length PATH string!  Return with SUCCESS, but DON'T write
      # /wPATH.  No WinX utilities will be available, but CYGWIN will be (see
      # first line of /etc/profile).
      echo -e "\tWARNING:  PATH is zero-length, so /wPATH will NOT be created." > /dev/stderr
      # By copying /dev/null over it, /bin/x.BAT becomes a NOP.
      /usr/bin/cat /dev/null > /bin/x.BAT
      exit
   fi
   # PATH is not empty, so create /wPATH and /bin/x.BAT, then exit.  /bin/x.BAT
   # will be executed next.
   echo "$x" > /wPATH
   (echo -n "path $x";echo -e "\x0d") > /bin/x.BAT
   if [ $? -eq 0 ];then echo -e "\tFile /wPATH successfully created." > /dev/stderr;fi
   exit
fi



# Now resolve the conflict between /wPATH and the passed-in PATH string.

if [ ! -z "$2" ];then
   # $2 IS present, so let /wPATH prevail.
   exit
fi

# $2 is NOT present, so overwrite /wPATH (AND /bin/x.BAT).
echo "$x" > /wPATH
(echo -n "path $x";echo -e "\x0d") > /bin/x.BAT