lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

On 9/28/2013 3:47 PM, Sean Conner wrote:

....
   2. I was unaware that $HOME/bin was a common Unix idiom.  And why are you
checking for $HOME/bin (or /usr/local/bin)?
Including $HOME/bin is (or was in the early 1980s) a common idiom among Unix users. Where else would you put your personally written scripts and programs on a timesharing system? Only the sysadmin had write access to /usr/local, which itself was not necessarily present on early BSD and System 3 Unix systems that I personally remember coming in contact with.
I remain surprised that convention does seem to have fallen into disuse in Linux distributions. I guess it is no longer the case that a typical user actually writes any scripts or programs of their own (as distinct from installing things distributed as source), or if they do, they habitually use sudo to copy them to /usr/local/bin. Personally, my shell configuration always gets $HOME/bin added to my path. 


   3. I have an issue with your Windows version of an absolute path.  On
Unix, '/' as the start marks an absolute path, but that's only because Unix
does not have the concept of drive letters.  On Windows though, you have
	path/...
which is a relative path to the current location.  Then you have
	//...
which is an abolute path on the current drive, and then
No, just /.... is an absolute path on the current drive. With two slashes, the path represents either a network file share (i.e. //server/share/...), the internal device object namespace (i.e. //./HardDisk0, //./COM10, or the like but by exceedingly strong convention always specified with backslashes), and an escape mechanism to support pathnames with unusual length or makeup (//?/....). This is carefully documented at MSDN [1] but you have to parse the words carefully.
[1]: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx 


	C://
which is an absolute path on a particular drive.
Just C:/..., unlike Unix, doubling up the path separator is not uniformly supported in Windows. It does work when doubled at any place other than the start, but my reading of the docs indicates that is incorrect even though it has been true as long as Windows and DOS have supported directories at all. 


....
Heck, that leads me to ask (since I don't have a Windows system to test this
on)---is

	C:path

valid?  That is, relative to the current directory on the C: drive?  I seem
to recall that MS-DOS kept track of the current directory on each drive.
Yes, that is valid. Windows keeps a separate current working drive for each process, as well as a current working directory for each drive for each process. The current drive and directories are inherited by child processes in a generally sensible and obvious way. 


[1]	Yes, that *IS* a valid path in Windows.  The Windows kernel does not
	care if you use '/' or '\' as a path separator and will happily
	accept both.  It's just the default Windows command line that
	bitches, and only because Windows (and MS-DOS, the precursor to
	Windows) used '/' to mark command line options [2][3].
Valid though it may be, Windows users are not encouraged to know that there is a second choice. As a long time Windows developer, I'd argue that permitting both slashes in file names really was a mistake. It has led to a lot of complacency about path parsing in "portable" code that has caused a lot of pain. I suspect that just making Windows be different would have been less painful in the long run. Of course, if the future could have been predicted in the 1980s, then making DOS ignore CP/M, every DEC OS, and I believe IBM mainframe conventions to follow Unix and use / for path names and not for command line options would have been the best answer. But who would have predicted then that Unix and descendants would still be a live, viable OS in 2013? 


....
[3]	INT 21H, function 37H, Get/Set Switch Character
....
	It defaulted to '/' but could be changed.
I tried that once in DOS 3.2 after noticing the API existed. The resulting user experience was unpleasant because even then there were just enough assumptions made by other tools. And changing it broke every BAT file that used / for options. I put it back. 

--
Ross Berteig                               Ross@CheshireEng.com
Cheshire Engineering Corp.           http://www.CheshireEng.com/
+1 626 303 1602
+1 626 351 1590 FAX