[Top][All Lists]

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

Re: mv dumps core in RH7 (fileutils 4.0x)

From: Jim Meyering
Subject: Re: mv dumps core in RH7 (fileutils 4.0x)
Date: 20 Jan 2001 23:18:17 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.96

Alessandro Suardi <address@hidden> wrote:
|   I wanted to put back in place the symlink to the IBM 1.1.8 JRE coming
|   with the Oracle distribution after trying to see how Oracle Java tools
|   behaved if pointed to Sun's 1.2.2 JDK, so I ran 'mv JRE118 JRE' - thus
|   committing the 2nd mistake of this night (one was to mix JRE and JDK,
|   quite stupid yeah right :) -- in fact 'mv' began copying over the
|   whole tree pointed by the symlink. Well, it didn't complete since it
|   bombed out with this:
| address@hidden 8.1.7]$ mv JRE118/ JRE
| mv: basename.c:67: base_name: Assertion `all_slashes || *(p - 1) != '/'' 
failed.Aborted (core dumped)

Thanks for the report.
That (failed assertion problem) is fixed in the latest test release.

Regarding the fact that `mv symlink-to-dir/ some-other-name'
now moves the dir, ... that behavior is certainly surprising,
but it is consistent with the standards.  There's a new option you
may want to use:

       Remove any trailing slashes from each SOURCE argument.  *Note
       Trailing slashes::.

And here's the section on that topic from the info documentation:

  Trailing slashes

     Some GNU programs (at least `cp', `install', `ln', and `mv') allow
  you to remove any trailing slashes from each SOURCE argument before
  operating on it.  The `--remove-trailing-slashes' option enables this

     This is useful when a SOURCE argument may have a trailing slash and
  specify a symbolic link to a directory.  This scenario is in fact rather
  common because some shells can automatically append a trailing slash
  when performing file name completion on such symbolic links.  Without
  this option, `mv', for example, (via the system's rename function) must
  interpret a trailing slash as a request to dereference the symbolic link
  and so must rename the indirectly referenced _directory_ and not the
  symbolic link.  Although it may seem surprising that such behavior be
  the default, it is required by POSIX.2 and is consistent with other
  parts of that standard.

reply via email to

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