On 18/11/2013 20:04, Eric Blake wrote:
On 11/18/2013 06:20 PM, Linda Walsh wrote:
>>> However, "find dir/. -type d -empty -delete" works, but exits with
>>> a failure code causing scripts to break.
>>>
>> This behavior is required by POSIX. Sorry.
POSIX requires that whatever you pas
On 11/18/2013 05:25 PM, Linda Walsh wrote:
> They don't require it for the case of "find ."?
>
> or cp -al a/. b/.
>
> ?
I couldn't parse this question.
>
>
> Are you saying we need an alternate core utils?
Nothing is stopping you from writing your own software that behaves the
way you want.
On 11/18/2013 06:20 PM, Linda Walsh wrote:
>>>
>>> However, "find dir/. -type d -empty -delete" works, but
>>> exits with a failure code causing scripts to break.
>>>
>>
>> This behavior is required by POSIX. Sorry.
POSIX requires that whatever you pass on the command line ("dir/.") be
pass
On 18/11/2013 16:15, Eric Blake wrote:
On 11/18/2013 04:55 PM, Linda A. Walsh wrote:
In coreutils 8.21-7.1.3.
It has been standard to use "." in a directory to mean it's contents
on a recursive or copy (compare cp -al src/. dst/.).
However, "find dir/. -type d -empty -delete" works, but
On Mon, Nov 18, 2013 at 03:55:52PM -0800, Linda A. Walsh wrote:
> In coreutils 8.21-7.1.3.
>
> It has been standard to use "." in a directory to mean it's contents
> on a recursive or copy (compare cp -al src/. dst/.).
>
> However, "find dir/. -type d -empty -delete" works, but
Does it?
$ mkd
They don't require it for the case of "find ."?
or cp -al a/. b/.
?
Are you saying we need an alternate core utils?
On 11/18/2013 04:55 PM, Linda A. Walsh wrote:
> In coreutils 8.21-7.1.3.
>
> It has been standard to use "." in a directory to mean it's contents
> on a recursive or copy (compare cp -al src/. dst/.).
>
> However, "find dir/. -type d -empty -delete" works, but
> exits with a failure code causin
In coreutils 8.21-7.1.3.
It has been standard to use "." in a directory to mean it's contents
on a recursive or copy (compare cp -al src/. dst/.).
However, "find dir/. -type d -empty -delete" works, but
exits with a failure code causing scripts to break.
Surprisingly, if one could cd to the d
