* tests/CuTmpdir.pm (chmod_tree): Do not run chmod on undefined
argument, can happen when the build path contains spaces.
---
Hi Jim,
this fixes a regression of "make check" when source and build tree live
in a directory with spaces in the name. The regression was introduced
some time after I po
Hi Jim, all,
in a recent commit you write
| * HACKING: describe how to find a misplaced change-set
| --- a/HACKING
| +++ b/HACKING
| @@ -360,6 +360,22 @@ Miscellaneous useful git commands
|you an interface with which you can reorder and modify arbitrary
|change sets on that b
mkdir -p does not play nice when the directory (/home in this case) has
a default ACL.
22:57 Kiste:/home # strace -e mkdir mkdir test1
mkdir("test1", 0777)= 0
22:57 Kiste:/home # strace -e mkdir mkdir -p test2
mkdir("test2", 0755)= 0
22:57 Kiste:/home # l
Ondřej Vašík <[EMAIL PROTECTED]> wrote:
...
> Where should I document current the changes? In gnulib getdate.texi
> only? Or in both gnulib and coreutils documentation?
Hi Ondřej,
Documenting in getdate.texi will be enough, because that file is
included by coreutils.texi. Thanks!
_
Kamil Dudka <[EMAIL PROTECTED]> wrote:
...
>> Move this cap_free call "up". Then you can remove
>> the repeated call below.
>>
>> > +return false;
>> > + }
>> > +
>> > + /* check if human-readable capability string is empty */
>> > + hasCap = *result;
> I am not sure about this change. libc
Thank you for patience. I have made improvements you suggested.
On Saturday 19 July 2008 06:16:20 pm you wrote:
> Thanks for working on this.
> Sounds worthwhile, though maybe worth
> giving it a separate attribute rather than
> sharing the one currently used for set-user-ID programs.
Ok, added ne
Hello,
Jim Meyering wrote:
> I'm a little leery of this patch, because it makes interpretation
> of UTC+dd and UTC-dd dependent on the value of dd. For dd <= 14, dd
> represents hours. Otherwise, it represents minutes. That would have
> to be documented, but seems odd enough that my reflex is to
On Friday 18 July 2008 03:54:41 pm you wrote:
> As for the new name, iflag=block would be my preference if it weren't
> for the existence of conv=block/unblock and iflag=nonblock. Too much
> room for misunderstanding.
>
> I'd be happy with either of the following, with a slight preference for
> th
