root folder 'C' in the variable 'PATH'

[Pat Guano]

Good evening,

I have not used any Windows-system in years and dare ask you for an information which will help rather a user of my own software than myself. My free utility that does platform-independently convert EML-files to PDF may use other tools if they are installed on the same computer. For this purpose, my program looks for the executables in the folders which are referenced in the PATH-variable.

Now, one user tells me that the folder 'C' is reported to be inexistent on his system, while it is obviously named in the PATH-variable. I have to deduce the meaning of this observation myself, which is as good as impossible. Can you tell me a few things, which may help me understand how I must modify my utility ?

• Does it make sense to reference C: in the PATH-variable? I remember Autoexec.bat but also, that programs are usually installed elsewhere.
  
• Which rules exist nowadays, that may melp me identify root-folders and exempt them from my search for executable files? Are they still named with 1-letter designators or are there other possibilities?
  
• Is there a different, maybe more straight-forward explanation for my inability to *use* C: as a directory like any of the others, which are referenced in PATH?
  

Thank you in advance and do not hesitate, if you have some non-MS-specific questions. My utility-program is here:

Crème Fraiche.

The current version is flawed in the way that you must have an environment-variable 'LANG', else the program crashes miserably . A correction is due to be released tomorrow.

[ɹəuəllıʍ ʇɐb]

Welcome to the Windows Forum.

No, the C:\ root should not be in the PATH environment variable; in fact, modern Windows systems will not let users to put anything into the C:\ root.

And yes, devices are still addressed with a single-character letter, followed by a colon.

[Pat Guano]

No, the C:\ root should not be in the PATH environment variable; in fact, modern Windows systems will not let users to

put anything into the C:\ root.

Thank you Pat.

I have already decided, that the PATH-settings are none of my business and will just ignore any folders which I cannot find useful (nonexistent, unreadable), provided a quick-fix and will now publish yet another bugfix-release on Sourceforge... What had occupied me may be the influence of the "root"-directory on Unix/Linux-systems, while, in fact, the problem at hand is quite simply my inability to open an arbitrary directory...

But I had to post the question on this and another forum, to actually overcome the paradigm of the mighty "root".

[Pat Guano]

Guess what,

my problem is not solved. I spare you the details but my user is still not able to use my program as the Ruby-routines to split the values from PATH into directory-names appear to be dysfunctional. I have written a short Ruby-script to test nothing but the treatment of the PATH-variable and would like to ask anybody with access to a Ruby-interpreter under Windows, to maybe run this script once.

The command-syntax should be something like this:

C:\> ruby path_test.rb

Just tell me, if the result looks familiar to you or if the output is garbage. Here is the entire script for you to scrutinize or to save under a name like "path_test.rb" (the original indentation is not preserved upon paste) :

#encoding: UTF-8
# This script shall verify that the Windows PATH can
# be read and its values be split using Ruby
require "logger"
$LOG = Logger.new(STDOUT)
# set log-level or disable logging
$LOG.level = Logger::INFO
def test_path
pathdirs = ENV['PATH'].split(File::PATH_SEPARATOR).collect do |d|
# BUGFIX: PATH may contain just anything!
pdir = nil
if(Dir.exist?(d) )
if(File.readable?(d) )
# create a non nil entry for pathdirs.
begin
	 pdir = Dir.new(d)
rescue Exception => ex
	 # "Trust nobody" (Herod V)
	 $LOG.error('Cannot search for executables in ' << d << ': ' << ex.message )
end
else
$LOG.warn('The path-variable references an unreadable directory: ' << d)
end
else
$LOG.warn('The path-variable contains an invalid value: ' << d)
end
pdir.path if pdir
end
pathdirs.join(', ')
end
if __FILE__ == $0
$LOG.info( test_path)
end

Thank you anyway.

[ɹəuəllıʍ ʇɐb]

Sorry, I never heard of Ruby, and at first glance I don't understand what your script is doing.

What output do you get when you run it?

P.S. I use Python if I need any scripting done.

[Pat Guano]

Sorry, I never heard of Ruby, and at first glance I don't understand what your script is doing.

An object oriented programming language, much used for web-applications ('Ruby on Rails', 'Sinatra' and other frameworks), invented in Japan around 1992, if I am not erring,

What output do you get when you run it?

It just prints the folders from my own PATH-variable, like this

I, [2012-12-16T11:46:09.874157 #2463] INFO -- : /usr/local/sbin, /usr/local/bin, /usr/sbin, /usr/bin, /sbin, /bin, /usr/games, /usr/local/games, /usr/local/script

The output on a Windows-system should be quite similar, just with the MS-specific path- and directory-separators, i.e. semicolon and backslash. All the routines should be platform-independent, but if the user who reports problems is right, they are not. And that would be a bug in Ruby. Else, it could also be a bug in my software that I try to find. But not owning a bunch of machines with a bunch of operating systems to choose from, makes it difficult. For the time, my bet is that the user's system is either not typical or something else is odd. It probably has nothing to do with Ruby or my program. Alas, I have no proof.

P.S. I use Python if I need any scripting done.

That is the language the syntax of which comes closest to Ruby. In the meantime, both languages have converged a little as regards functionality and syntax.

[Pat Guano]

In the meantime, I have positive feedback from the ruby mailing-list. My routines appear to be correctly programmed and functional on at least 1 Windows-machine out there. I will in consequence just exclude the call to external programs, if reading the PATH-variable leads to any arbitrary failure and not further try to elaborate the code.

Sorry for the slight off-topic tendency. I call the issue closed.

Cheerio.

[ɹəuəllıʍ ʇɐb]

I will move your topic to the programming section of the forum.