[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] attach
From: |
David Levine |
Subject: |
Re: [Nmh-workers] attach |
Date: |
Sat, 15 Sep 2012 12:34:18 -0500 |
Oliver wrote:
> Ralph Corderoy wrote:
> > > David Levine <address@hidden> writes:
> > > > Note that whatnow's attach will continue to allow attachment of
> > > > directories because it expands those out to their contents. It
> > > > doesn't check what the contents are, though. That's why we needed
> > > > to add this check.
> >
> > I wonder if whatnow's `attach foo' attaching foo/* when it's a
> > directory is surprising and it would be better to error, forcing
> > the user to
>
> Does it actually do that? From my tests, it seemed more broken:
>
> % mkdir foo
> % touch foo/{one,two}
> % comp
> ...
> What now? attach foo
> What now? list
> From:
> ...
> Nmh-Attachment: /home/opk/one
> Nmh-Attachment: /home/opk/two
>
> The files are actually /home/opk/foo/one etc. This occurs because of the
> use of ls: ls isn't prefixing the current directory so presumably that's
> done by nmh.
That's right, and you're right.
Maybe this is another argument for adding -d to the ls command.
But -d conflates not descending into directories with not
dereferencing symbolic links, so the display (alist) will show
links. Though I can't get ls to dereference symlinks on Linux,
anyway. -H or -L should, but /bin/ls -HL still shows me the
link.
send(1) will still dereference symlinks, in effect, because it
uses fopen(3) when attaching.
David