when attempting to install Anaconda 2.2.0 Linux x86-64 after I accept the
license it gets into what looks like a terminal loop where each line just say
“y” over and over for minutes and minutes - left for up to a half an hour and
it was the same thing
Sent from Windows Mail
2015-06-17 10:24:13 +, Ed Avis:
% mkdir foo
% rmdir foo/.
rmdir: failed to remove ‘foo/.’: Invalid argument
% rmdir --version
rmdir (GNU coreutils) 8.23
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html.
This
Stephane Chazelas stephane.chazelas at gmail.com writes:
Solaris 10 behaves like linux (EINVAL for ., EEXIST for ..).
The rmdir utility there is more explicit:
$ rmdir D/. D/..
rmdir: directory D/.: Can't remove current directory or ..
I think that error message would be an improvement on GNU
On 17/06/15 12:03, Ed Avis wrote:
Thanks Pádraig Brady for your reply. You mentioned the manual page for
rmdir(2) and the POSIX spec. But isn't that POSIX spec talking about the
rmdir(2) system call - not the rmdir(1) executable?
As far as I know there is no requirement that rmdir(1) be an
POSIX documents that EINVAL be returned for rmdir('foo/.') but as far as I
can see from the link you sent it does not document the error status for
rmdir('foo/..') beyond saying that it shall fail. As it happens, it returns
ENOTEMPTY on Linux.
OK, you point out that foo/. might not always be the
% mkdir foo
% rmdir foo/.
rmdir: failed to remove ‘foo/.’: Invalid argument
% rmdir --version
rmdir (GNU coreutils) 8.23
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and
tag 20835 notabug
close 20835
stop
On 17/06/15 11:24, Ed Avis wrote:
% mkdir foo
% rmdir foo/.
rmdir: failed to remove ‘foo/.’: Invalid argument
% rmdir --version
rmdir (GNU coreutils) 8.23
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
Thanks Pádraig Brady for your reply. You mentioned the manual page for
rmdir(2) and the POSIX spec. But isn't that POSIX spec talking about the
rmdir(2) system call - not the rmdir(1) executable?
As far as I know there is no requirement that rmdir(1) be an exact wrapper
for rmdir(2); rather its
