delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2007/09/06/15:15:48

X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Thu, 6 Sep 2007 15:15:18 -0400
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Patch for bash to support PATHEXT in Windows
Message-ID: <20070906191518.GC19860@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <46E026B9 DOT 4060703 AT mmpintl DOT demon DOT co DOT uk> <46E05113 DOT 6030004 AT byu DOT net>
MIME-Version: 1.0
In-Reply-To: <46E05113.6030004@byu.net>
User-Agent: Mutt/1.5.16 (2007-06-09)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Thu, Sep 06, 2007 at 01:12:19PM -0600, Eric Blake wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>A mailing list is more appropriate for this than me personally -
>http://cygwin.com/acronyms/#PPIOSPE
>
>According to Mike Parker on 9/6/2007 10:11 AM:
>> Eric;
>> 
>> Apologies if you are not the "Volunteer BASH Maintainer"; if not can you
>> point me in the right direction to get it submitted properly?
>> 
>> I have seen many postings about "default" extensions defined by PATHEXT.
>> I have done a patch to support this.
>> 
>> e.g.
>> 
>> export PATHEXT=".ksh;.sh"
>
>PATHEXT is a cmd.com feature, and does not have much precedence in Linux.
>
>> 
>> will add file types .ksh (e.g. xx.ksh) and .sh as a found file. This is
>> personally helping me migrate away from MKS Korn Shell.
>> 
>> The Patch
>> ==============================================================================
>> 
>> 
>> diff -Nur bash-3.2.postpatch/findcmd.c bash-3.2.new/findcmd.c
>> --- bash-3.2.postpatch/findcmd.c    2007-09-04 16:19:46.019666300 +0100
>> +++ bash-3.2.new/findcmd.c    2007-09-06 13:40:19.172250000 +0100
>> @@ -50,6 +50,7 @@
>> static char *_find_user_command_internal __P((const char *, int));
>> static char *find_user_command_internal __P((const char *, int));
>> static char *find_user_command_in_path __P((const char *, char *, int));
>> +static char *find_user_command_in_path_orig __P((const char *, char *,
>> int));
>> static char *find_in_path_element __P((const char *, char *, int, int,
>> struct stat *));
>> static char *find_absolute_program __P((const char *, int));
>> 
>> @@ -525,12 +526,55 @@
>>       FS_EXISTS:        The first file found will do.
>>       FS_NODIRS:        Don't find any directories.
>> */
>> +
>> +#define    PATHEXT_SEP    ";:"    /* Separators for parsing PATHEXT */
>
>I'd rather use just :, as in PATH, rather than defining PATHEXT_SEP; but
>that may imply also patching cygwin1.dll to treat PATHEXT similarly to PATH.
>
>> static char *
>> find_user_command_in_path (name, path_list, flags)
>>      const char *name;
>>      char *path_list;
>>      int flags;
>> {
>> +  char *found_file;
>> +  char *pathext;
>> +  char *file_type;
>> +  char *trial_name;
>> +  int name_length;
>> +  SHELL_VAR *var;
>> +
>> +/* Use original lookup to find "name" and "name.exe" */
>> +  found_file = find_user_command_in_path_orig(name, path_list, flags);
>> +  if(found_file) return (found_file);
>> +
>> +/* Not found, step through file types in PATHEXT */
>> +/* PATHEXT follows the Windows format - e.g. ".ksh;.sh;.cmd" */
>> +  var = find_variable_internal("PATHEXT", 1);
>> +  if(var)
>> +  {
>> +    pathext = strdup(value_cell(var));
>> +    name_length = strlen(name);
>> +    file_type = strtok(pathext, PATHEXT_SEP);
>> +      while(file_type)
>> +      {
>> +        trial_name = malloc(name_length + strlen(file_type) + 1);
>> +        strcpy(trial_name, name);
>> +        strcat(trial_name, file_type);
>> +        found_file = find_user_command_in_path_orig(trial_name,
>> path_list, flags);
>> +        free(trial_name);
>> +        if(found_file) break;    /* Found - break out of loop */
>> +        file_type = strtok((char *)NULL, PATHEXT_SEP);
>> +      }
>> +    free(pathext);
>> +  }
>> +  return (found_file);
>> +
>> +}
>> +
>> +static char *
>> +find_user_command_in_path_orig (name, path_list, flags)
>> +     const char *name;
>> +     char *path_list;
>> +     int flags;
>> +{
>>   char *full_path, *path;
>>   int path_index, name_len;
>>   struct stat dotinfo;
>> 
>> End Patch
>> ==============================================================================
>> 
>> 
>> Hope this helps
>> 
>
>Thanks for the idea.  However, I'm not sure I want to incorporate this
>into cygwin at this time, without more support from cygwin1.dll, or at
>least without more discussion on the list.

I'm impressed with the patch but I don't think it really adheres to the
philosophy of Cygwin or Linux.

Also, the Cygwin DLL already has enough code to deal with extensions
specially.  We're not going to add more and feed the "Cygwin is slow"
fodder.

I really am sorry to have to reject the idea when the OP has already
gone to some effort but I just don't see this happening.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


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