[Top][All Lists]

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

[Axiom-developer] RE: Cannot Rename The File Erlib To NRLIB

From: Page, Bill
Subject: [Axiom-developer] RE: Cannot Rename The File Erlib To NRLIB
Date: Wed, 30 Aug 2006 13:03:25 -0400

On Wednesday, August 30, 2006 5:13 AM I wrote:
> Camm Maguire wrote:
> > 
> > I though you had problems renaming, not deleting?  I have
> > not done anything here (yet).
> > 
> You are right. So in addition to your change to
> 'gcl-2.6.8pre/o/unixfsys.c' in delete_file:
>         if (unlink(filename) < 0 && rmdir(filename) < 0)
>                 FEerror("Cannot delete the file ~S: ~s.", 2,
>                   path, make_simple_string(strerror(errno)));
> and I added the following to rename_file:
> #ifdef HAVE_RENAME
>         /* Make sure we can rename */
>         if (unlink(newfilename) < 0) rmdir(newfilename);
>         if (rename(filename, newfilename) < 0)
>                 FEerror("Cannot rename the file ~S to ~S.",
>                         2, vs_base[0], vs_base[1]);
> #else
>         sprintf(command, "mv %s %s", filename, newfilename);
>         system(command);
> #endif
> ...
> I am testing the build now.

My tests of re-compiling a SPAD function still failed. :-(

Unfortunately my patch to rename_file is not sufficient for Axiom.
Axiom really does seem to expect that rename is as destructive
as the 'mv' shell command. But the semantics of 'rename' is

int rename (const char *oldname, const char *newname)

"If oldname is a directory, then either newname must not exist
or it must name a directory that is empty. In the latter case,
the existing directory named newname is deleted first."

It seems that to simulate the behaviour of 'mv' with the Gnu C
library one must write a simple recursive routine to hit all of
the files and subdirectories of a given directory, etc. etc.


But wait a minute! Does hacking away at GCL really make any
sense? Let's take a look at exactly what Axiom is doing with
this ... dig dig dig ... Aha:


Ok, here is the offensive coding in Axiom!


;; ($ERASE filearg) -> 0 if succeeds else 1
(defun $erase (&rest filearg)
  (setq filearg (make-full-namestring filearg))
  (if (probe-file filearg)
#+:CCL (delete-file filearg)
      (if (library-file filearg)
          (delete-directory filearg)
          (delete-file filearg))

(defun library-file (filename)
; (format t "library-file: ~a~%" filename)

(defun delete-directory (dirname)
   (system (concat "rm  -r " dirname)))

(defun $REPLACE (filespec1 filespec2)
    ($erase (setq filespec1 (make-full-namestring filespec1)))
    (rename-file (make-full-namestring filespec2) filespec1))


Elsewhere Axiom calls $REPLACE to replace xxx.NRLIB with the
contents of xxx.erlib. This used to work. What has changed?

The only thing I see here that I know has changed around about
gcl-2.6.7pre is 'probe-file'. The change was the 'probe-file'
returning nil for directories.

Yes, indeed! So now Axiom only deleted files but not directories!
It used to do both. I think what it wants to know is whether
the file or directory exists.

I should have remembered this:

Although the lisp spec is a horrible mish-mash, as near as I
can figure it

 (directory (truename filearg))

will test of a particular file or *directory* exists, although it
seems to do some kind of "wild card" since it also finds files
or directories that have something after a dot (.). So

 (directory (truename "xxx"))

returns a list of all files or directories of the form "xxx.*"
Contrary to the documentation at


Anyway it seems the following patch replacing (probe-file filearg)
with (directory (truename filearg)) should work (for Axiom's purposes
at least):


;; ($ERASE filearg) -> 0 if succeeds else 1
(defun $erase (&rest filearg)
  (setq filearg (make-full-namestring filearg))
  (if (directory (truename filearg))
#+:CCL (delete-file filearg)
      (if (library-file filearg)
          (delete-directory filearg)
          (delete-file filearg))


Any comments? Does anyone see how to do this a better way?

Bill Page.

reply via email to

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