主页 / unix / 问题 / 524035
Accepted
Harper - Reinstate Monica
Asked: 2019-06-11 07:26:42 +0800 CST

Unix 是否被多个 prunes 和 type f 淹没了？

  • 772

我在这个魔方上花了几天时间。我为解决一个问题所做的任何事情都会破坏另一个问题。

我在兼容 POSIX 的 MacOS X 10.5 到 10.14 上。我在 Perl 脚本的上下文中调用它

  system ("find blah blah > FILENAME");

我需要 Unix 'find' 同时做所有这些事情。

  • 从卷根开始，例如/Volumes/My HD
  • 不要跨文件系统
  • 仅打印文件，而不是目录或符号链接
  • 甚至不要进入多个目录，例如net dev system. （即不探索/Volumes/foo/dev/，但探索/Volumes/foo/Users/Jim/ dev /github/twonky/）
  • 起点可能包含空格

现在我正在做以下事情：（为了便于阅读，分成几行；实际上是一长行）

 Find -x '/Volumes/foo/' 
    -path '/Volumes/foo//dev/*' -prune
    -path '/Volumes/foo//net/*' -prune
    -path '/Volumes/foo//system/*' -prune
    -o -type f -print

双 / 的原因是find的打印输出包含 // 因为起点以 / 结尾。修剪路径必须一致，否则它们将不匹配。为什么起点以/结尾？因为如果没有，则find在名称中带有空格的任何起点上都会失败，例如“我的高清”。试过了。

现在， find 仅排除列表中的第一个目录。其余的，它只是忽略。我目前正在 OS X 10.5 上进行测试，但我需要在任何地方都可以使用的东西。

多个修剪 + 仅文件 + 文件名中的空格是否太过分了？我只是要求太多find吗？

find

3 个回答

  1. 您需要一个“或”来完成第二次匹配——没有一条路径可以同时匹配-path '/Volumes/foo//dev/*'和-path '/Volumes/foo//net/*'

    Find -x '/Volumes/foo/' 
    \( -path '/Volumes/foo//dev/*' 
    -o -path '/Volumes/foo//net/*' 
    -o -path '/Volumes/foo//system/*' \) -prune
-o -type f -print
    • 5
  2. Best Answer

    我的回答是纯 Perl 解决方案。

    使用此沙箱：

    $ tree -F Volumes/ 
Volumes/ 
└── My\ HD/
    ├── Users/
    │   └── Jim/
    │       └── dev/
    │           └── github/
    │               └── twonky/
    │                   └── i_there.txt
    ├── dev/
    ├── net/
    ├── start.bat
    └── system/
        └── hello

9 directories, 3 files

    以下 Perl 代码使用File::Find：

    #!/usr/bin/perl

use strict;
use warnings;
use feature 'say';

use File::Find;

my $start = 'Volumes/My HD';
my $start_dev = (stat($start))[0];
my @exclude = qw/net dev system/;
my %skipdir;

sub wanted {
    my $name = $_;
    return if (stat($name))[0] != $start_dev;
    $skipdir{$File::Find::name} = 1 if $File::Find::dir eq $start && grep { $name eq $_ } @exclude;
    if (exists($skipdir{$File::Find::dir})) {
        $skipdir{$File::Find::name} = 1 if -d $name;
        return;
    }
    return if ! -f $name;
    say "Got: $File::Find::name";

}

my %args = (
    wanted => \&wanted,
    follow => 1,
    follow_skip => 1,
);


find(\%args, $start);

    给出预期（如果我理解正确的话）：

    Got: Volumes/My HD/start.bat
Got: Volumes/My HD/Users/Jim/dev/github/twonky/i_there.txt

    它是一个 POC，它可以被增强。

    另请注意，您拥有find2perl记录在案的工具，该工具能够使用相同的标准将特定find调用转换为关联的 Perl 代码。File::Find

    现在Path::Class代码可能看起来更简单/更容易阅读（对于相同的结果）：

    #!/usr/bin/perl

use strict;
use warnings;
use feature 'say';

use Path::Class;

my $start = Path::Class::Dir->new('Volumes/My HD');
my @exclude = qw/net dev system/;

$start->recurse(callback => sub {
    my $node = shift;
    if ($node->is_dir) {
        return $node->PRUNE if $node->parent eq $start && grep { $node->dir_list(-1) eq $_ } @exclude;
        return;
    }
    return $node->PRUNE if $node->stat()->dev != $start->stat()->dev;
    say 'Got: ', $node->stringify();
}, preorder => 1)
    • 2

  3. 在您的帮助下，我得以稳定“查找”。然而，将代码从 OS X 10.5 移动到 10.10再次破坏了它。最后的机会。'find' 实在是太迟钝了，文档不足且不一致，而且它是一个 unix 核心功能，看在 Pete 的份上！这个。这就是为什么我讨厌别人的代码。我开始埋头学习 File::Find，然后想“我在做什么？我可以在 20 分钟内自己编写代码”。

    我总结了一下。 

    sub iterate {
  my ($mydir, $ref_FH, $homevol, $ref_excludes) = @_;  # last is ref to hash

  return if (defined ($ref_excludes -> {$mydir}));   # No excludes

  my $thisvol = (stat($mydir))[0];    # What's my volume?
  return if ($thisvol != $homevol) ;  # No crossing volumes

  opendir (my $DIR, $mydir);
  while (defined (my $file = readdir($DIR))) {
    next if ($file eq '.' or $file eq '..');
    my $full = "$mydir/$file";   

    if (-l $full) {                                   # symlink
                                                         # nope
    } elsif (-f $full) {                              # file
      print {$$ref_FH} "$full\n";                        # print it
    } elsif (-d $full) {                              # dir
      &iterate($full, $ref_FH, $homevol, $ref_excludes); # iterate
    }
  }
}

    而且速度很快。而且很轻——这段代码的大小是格式化“find”的arg列表的代码的一半（并且更易于维护）！

    • 1

相关问题