help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Is this an elisp bug, or is it intended?


From: Andreas Ames
Subject: Is this an elisp bug, or is it intended?
Date: 25 Mar 2002 19:46:04 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Hi all,

I'm running 'GNU Emacs 21.1.1 (i386-mingw-nt5.0.2195) of 2001-10-29 on
FR102060'.  It's built under cygwin and it runs on w2k sp 2.

I have a problem with the elisp statement (is 'statement' a valid
syntactic unit within elisp?):

(split-string (getenv "PATH") path-separator)

as found, for example, in eshell/em-cmpl.el, line 403.

My 'path-separator' evaluates to ";", as expected.

The above statement evaluates to

("C:\\cygwin\\home\\ama2fr\\bin;C:\\cygwin\\usr\\local\\bin;C:\\cygwin\\bin;C:\\cygwin\\bin;c:\\jdk1.3.1\\bin;c:\\texmf\\miktex\\bin;c:\\WINNT\\SYSTEM32;c:\\WINNT;c:\\WINNT\\SYSTEM32\\WBEM;C:\\cygwin\\bin;c:\\Program
Files\\Microsoft Visual Studio\\Common\\Tools\\WinNT;c:\\Program
Files\\Microsoft Visual Studio\\Common\\MSDev98\\Bin;c:\\Program
Files\\Microsoft Visual Studio\\Common\\Tools;c:\\Program
Files\\Microsoft Visual Studio\\VC98\\bin;c:\\emacs\\bin;c:\\Program
Files\\Python21;c:\\texmf\\miktex\\bin;c:\\emacs\\bin;C:\\cygwin\\usr\\X11R6\\bin;c:\\aspell;C:\\cygwin\\bin;")

Rather I would have expected it to result in the list that is returned
by the statement

(split-string (getenv "PATH") (eval path-separator))

which gives me

("C:\\cygwin\\home\\ama2fr\\bin" "C:\\cygwin\\usr\\local\\bin"
"C:\\cygwin\\bin" "C:\\cygwin\\bin" "c:\\jdk1.3.1\\bin"
"c:\\texmf\\miktex\\bin" "c:\\WINNT\\SYSTEM32" "c:\\WINNT"
"c:\\WINNT\\SYSTEM32\\WBEM" "C:\\cygwin\\bin" "c:\\Program
Files\\Microsoft Visual Studio\\Common\\Tools\\WinNT" "c:\\Program
Files\\Microsoft Visual Studio\\Common\\MSDev98\\Bin" "c:\\Program
Files\\Microsoft Visual Studio\\Common\\Tools" "c:\\Program
Files\\Microsoft Visual Studio\\VC98\\bin" "c:\\emacs\\bin"
"c:\\Program Files\\Python21" "c:\\texmf\\miktex\\bin"
"c:\\emacs\\bin" "C:\\cygwin\\usr\\X11R6\\bin" "c:\\aspell"
"C:\\cygwin\\bin")

I have some minor issues with the 'PATH'-handling here and I suspect
the above mentioned behaviour to be the reason.  For example I have a
'cvs.exe' as well in ~/bin (which is 'C:\cygwin\home\ama2fr\bin' in
windows terms) as in /usr/bin (which is actually 'C:\cygwin\bin').  As
far as I can say, the ~/bin executable should be used, given the above
PATH.  Unfortunately, pcl-cvs uses sometimes this one and sometimes
the other.  I have to setq 'cvs-command' to
'c:/cygwin/home/ama2fr/bin/cvs.exe' to make pcl-cvs behave as I want.

Is this a bug or am I missing something?

Furthermore I just wanted to send in a small code snippet.  Eshell,
which is BTW a great addition to emacs, doesn't recognize cygwin shell
scripts (which is reasonable, I think) when completing commands.  The
following functions make eshell recognizing these scripts (only if
they are in the PATH, obviously).

; get file type
(defun aa-show-file-type (file)
  "Print the mime-type of FILE, according to the `file' command."
  (with-temp-buffer
    (call-process "file" nil '(t nil) t "-Lib" file)
    (when (bolp)
      (backward-delete-char 1))
    (buffer-string)))

; is given file a shell script
(defun aa-shellscript-p (file)
  "Return `t', if FILE is a shellscript.
Uses `aa-show-file-type'."
  (string= (aa-show-file-type file) "application/x-shellscript"))

; this is only executed if cygwin is known to be available
(defun file-executable-p (FILENAME)
    "Return t if FILENAME can be executed by you.
For a directory, this means you can access files in that directory."
    (or (orig-file-executable-p FILENAME)
        (aa-shellscript-p FILENAME)))

I put that in my .emacs.

You need the 'file.exe' from cygwin in your PATH for this to work.
Note that 'file' doesn't report 'application/x-shellscript' if your
shebang reads '#!/usr/bin/bash' or '#!/usr/bin/sh' etc.  Use
'#!/bin/{ba}sh' instead.

I understand that this code is horrible when it comes to performance.
For me it is worth it.  Perhaps the emacs maintainers could include a
better solution in a forthcoming release for this (quite special)
situation.  I know that there already are discussions about porting
emacs to cygwin, which I would appreciate.


cheers,

andreas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]