Mark Paulus wrote:
When I do an ls -F, I get expected results: $ ls -F / bin/ cygwin.bat* home/ run.groff tmp1/ xfer/ cron_diagnose.sh* cygwin.ico* lib/ sbin/ usr/ cygdeb/ etc/ mountem* tmp/ var/
However, when I do ls -F //, then I get bad results: $ ls -F // ls: //bin: No such file or directory ls: //cron_diagnose.sh: No such file or directory ls: //cygdeb: No such file or directory ls: //cygwin.bat: No such file or directory ls: //cygwin.ico: No such file or directory ls: //etc: No such file or directory ls: //home: No such file or directory ls: //lib: No such file or directory ls: //mountem: No such file or directory ls: //run.groff: No such file or directory ls: //sbin: No such file or directory ls: //tmp: No such file or directory ls: //tmp1: No such file or directory ls: //usr: No such file or directory ls: //var: No such file or directory ls: //xfer: No such file or directory
Wasn't sure if this is also intricately intertwined with the pathname/dots/spaces thing, but wanted to mention it, as I am having another problem where rmdir() is not finding a file called "//usr/share/doc/cygwin-base/README". (should probably return ENOTDIR instead of ENOENT)
In general, in Cygwin, "//" == "\\" which introduces a UNC path. So, in a Windows CMD a "pushd \\server\share" is equivalent to "pushd //server/share" in a bash shell. Therefore a path of //user/share/doc/cygwin-base/README is saying "I want the file on the machine 'usr' under the share point of 'share' with a path of 'doc/cygwin-base/' and a filename of 'README'". I doubt that you have a machine named "usr" hanging around... ;-)
--
Everywhere is walking distance if you have the time.
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
