bug-textutils
[Top][All Lists]
Advanced

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

Re: TODO list


From: Jim Meyering
Subject: Re: TODO list
Date: 18 Apr 2001 12:50:44 +0200
User-agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.103

Thanks for volunteering.
That TODO list is pretty old.
Several items have been done or removed.
The latest test release is here:

  ftp://alpha.gnu.org/gnu/fetish/fileutils-4.0.43.tar.gz

Something that I would really appreciate is if someone would run the
Open Group's VSC-lite test suite against the fileutils and textutils
and report the failures.

  http://www.opengroup.org/testing/downloads/vsclite.html

I've been meaning to do it myself for months, but haven't found the time.
There's a bit of set-up required, some of which requires root access, e.g.,
to create a few test user accounts and some test groups.

more below...
Jim

Gracjan Ziolek <address@hidden> wrote:
| Is anything from fileutils TODO file being currently developed? If not, what
| would be the first to be made? I have some spare time and I think I could do
| something. Please give details on it.
|
| [things from TODO that I could possibly take]

For this, you'd have to read some specs on what chown and cp are
supposed to do regarding symlinks, and then try to match that up
with the current behavior

| chown, cp, etc: don't use chown on symlinks

I'm not sure that this behavior is allowed by the standard,
so again, you'd have to read about it to be sure, then implement
accordingly, if necessary.

Here are some test cases to consider:

  ln -s no-such-file dangling
  touch f
  cp -f f dangling

After the cp command, should `dangling' be a regular file or a symlink?
(currently cp leaves the symlink intact).
What if you create the symlink like this instead:

  ln -sf /no-such-dir/this-will-fail dangling

With the latter, we get this:

  $ cp -f f dangling
  cp: cannot create regular file `dangling': No such file or directory

which seems like it could easily be misleading, or even wrong,
since cp --help says this:

  -f, --force                  if an existing destination file cannot be
                                   opened, remove it and try again

In interpreting the POSIX spec (as the --help output),
the question comes down to whether a dangling symlink
constitutes an existing destination file.

Then, consider the above cases with -R and one of the
-P (the new, POSIX meaning, not --parents), -L, and -H, options.

And what about with --backup, -R, or without -f, etc.?

| cp -f (and install, etc.) fail when the destination is a dangling symlink

I already have a patch for this -- waiting until after the 4.1.0 release.

| make ls's size field wider, so files of size > 9,999,999 don't cause
|     misalignment

This won't happen -- it's a bad idea.

| all programs that accept --verbose: accept `-v' as an abbreviation

This is done.

| make sure we don't allow `mv '' /tmp' to do anything on systems that
|     let us stat the zero-length string



reply via email to

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