Re: Patch for bash to support PATHEXT in Windows

2007-09-06 Thread Eric Blake
-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.c2007-09-04 16:19:46.019666300 +0100
 +++ bash-3.2.new/findcmd.c2007-09-06 13:40:19.17225 +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.
 */
 +
 +#definePATHEXT_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.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG4FES84KuGfSFAYARAk7QAJ0bEfXqMAVbuqCTcLZWBd9Yx3i5/ACfY4X9
YoLzIK00vQclYtwDU7JfgSQ=
=VC3V
-END PGP SIGNATURE-

--
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/



Re: Patch for bash to support PATHEXT in Windows

2007-09-06 Thread Christopher Faylor
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.c2007-09-04 16:19:46.019666300 +0100
 +++ bash-3.2.new/findcmd.c2007-09-06 13:40:19.17225 +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.
 */
 +
 +#definePATHEXT_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/



RE: Patch for bash to support PATHEXT in Windows

2007-09-06 Thread Buchbinder, Barry (NIH/NIAID) [E]
Christopher Faylor wrote on Thursday, September 06, 2007 3:15 PM:

 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.c2007-09-04 16:19:46.019666300
 +0100 +++ bash-3.2.new/findcmd.c2007-09-06 13:40:19.17225
 +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. */
 +
 +#definePATHEXT_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

I don't understand what is the real problem.  If I understand permissions 
correctly, all one has to do is to set them.  Would something like the 
following work for you if you ran it periodically or once when you switch from 
MKS to cygwin?

for F in $(echo $PATH | \
tr : \\n | \
grep -v -e '^\.\?$'
)
do
find $F \! -perm 777 -type f \( -iname \*.ksh -o -iname \*.sh 
\) -print0 2 /dev/null
done | \
xargs -0r chmod -v 777

Good luck,

- Barry

--
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/