Eric Blake wrote: > Eric Blake <ebb9 <at> byu.net> writes: > >> The test is still running. > > misc/stdbuf hangs (cygwin still has some fifo issues that might be at play, > but
That should not run if stdbuf is not built. Here's a patch: >From 6c077c1633e31c36d17253ee7c946b47791dfd8e Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyer...@redhat.com> Date: Wed, 12 Aug 2009 23:05:17 +0200 Subject: [PATCH] * src/remove.c (rm_fts): Handle --one-file-system. --- src/remove.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/src/remove.c b/src/remove.c index 80be530..ea9e78c 100644 --- a/src/remove.c +++ b/src/remove.c @@ -519,6 +519,20 @@ rm_fts (FTS *fts, FTSENT *ent, struct rm_options const *x) case FTS_NSOK: /* e.g., dangling symlink */ case FTS_DEFAULT: /* none of the above */ ; + /* With --one-file-system, do not attempt to remove a mount point. + fts' FTS_XDEV ensures that we don't process any entries under + the mount point. */ + if (ent->fts_info == FTS_DP + && x->one_file_system + && FTS_ROOTLEVEL < ent->fts_level + && ent->fts_statp->st_ino != fts->fts_dev) + { + mark_parent_dirs (ent); + error (0, 0, _("skipping %s, since it's on a different device"), + quote (ent->fts_path)); + return RM_ERROR; + } + bool is_dir = ent->fts_info == FTS_DP || ent->fts_info == FTS_DNR; s = prompt (fts, ent, is_dir, x, PA_REMOVE_DIR, NULL); if (s != RM_OK) -- 1.6.4.357.gfd68c > more importantly, dd appears to be stuck trying to write to a fifo that never > gets filled because stdbuf isn't working). I had to kill two different dd > processes to get the testsuite to resume. > > Another suspicious failure: > > tests/misc/test-pwd.log > /home/eblake/coreutils/src/pwd.exe: error while loading shared libraries: ?: > cannot open shared object file: No such file or directory > pwd-long: does not contain old CWD > > It looks like the test removes PATH from the environment; but this has the > unfortunate side effect of crippling cygwin, which requires both /bin and > Windows directories to be in PATH at all times for .dlls to be found and > usable > in running an executable, even when you don't otherwise use the PATH for the > programs that you are invoking. In other words, you should be doing something > similar to 'command −p getconf PATH' to determine the bare minimum PATH rather > than nuking it altogether; unfortunately, command -p getconf PATH is probably > not portable. If you'd like to write a cygwin-specific patch, to work around that, or even to skip the test, that'd be fine. No pressure, of course.