I am having some trouble implementing the handling of Windows drive letters that I would like because of how search and file-info behave.
If I try the following program:
define variable chPath as character no-undo initial "ap\1099\1099mn.p".
define variable chFullPath as character no-undo.
propath = "c:\work\IS\ISrel\src," + propath.
message substring(propath,1,70) view-as alert-box.
chFullPath = search(chPath).
message "Search" chFullPath view-as alert-box.
file-info:file-name = chFullPath.
message "File-info" file-info:full-pathname view-as alert-box.
And include the drive letter in the initial entry in the propath where the indicated file is found, then both search and file-info will return full paths which include the drive letter. However, if the drive letter is missing in that propath entry, then both return full paths which are missing the drive letter.
I want the drive letter always, as long as it exists on the operating system in question.
So, what to use ... hopefully not some .NET component.
The full pathname delivered by input from os-dir does seem to provide the drive letter consistently, but that seems like a very obtuse way to get there.
I am having some trouble implementing the handling of Windows drive letters that I would like because of how search and file-info behave.
If I try the following program:
define variable chPath as character no-undo initial "ap\1099\1099mn.p".
define variable chFullPath as character no-undo.
propath = "c:\work\IS\ISrel\src," + propath.
message substring(propath,1,70) view-as alert-box.
chFullPath = search(chPath).
message "Search" chFullPath view-as alert-box.
file-info:file-name = chFullPath.
message "File-info" file-info:full-pathname view-as alert-box.
And include the drive letter in the initial entry in the propath where the indicated file is found, then both search and file-info will return full paths which include the drive letter. However, if the drive letter is missing in that propath entry, then both
return full paths which are missing the drive letter.
I want the drive letter always, as long as it exists on the operating system in question.
So, what to use ... hopefully not some .NET component.
The full pathname delivered by input from os-dir does seem to provide the drive letter consistently, but that seems like a very obtuse way to get there.
Flag this post as spam/abuse.
The point is that I prefer to write transportable code, not code bound to an operating system. If I introduce that kind of stuff, then I am stuck doing tests on what operating system that really have nothing to do with the simple tasks I am trying to perform.
The point is that I prefer to write transportable code, not code bound to an operating system. If I introduce that kind of stuff, then I am stuck doing tests on what operating system that really have nothing to do with the simple tasks I am trying to perform.
Flag this post as spam/abuse.
No. The code works fine as is on Windows or *nix as long as the drive letters are in the propath so that search and file-info provide drive letters in Windows and not in *nix. One option is to simply require that any user of ABL2DB include drive letters in the supplied propath, but I would rather have something else because the side-effects when they are missing are complicated.
The point is that I prefer to write transportable code, not code bound to an operating system. If I introduce that kind of stuff, then I am stuck doing tests on what operating system that really have nothing to do with the simple tasks I am trying to perform.
Flag this post as spam/abuse.
No. The code works fine as is on Windows or *nix as long as the drive letters are in the propath so that search and file-info provide drive letters in Windows and not in *nix. One option is to simply require that any user of ABL2DB include drive letters in the supplied propath, but I would rather have something else because the side-effects when they are missing are complicated.
Flag this post as spam/abuse.
If I have to, I have to, but if I can avoid it, then I would much rather not be maintaining multiple branches ... especially for such a stupid reason. There are times when one wants to interact with the outside in a very operating system specific way ... but this isn't one of them, by a long shot.
Well, perhaps, but it still requires a test for the operating system. It would be one solution, but doesn't it seem like there should be a way to get the drive letter predictably in Windows? Or, is the idea that, if you left the drive letter out of the the propath, then it must all be on the same drive so drive letter shouldn't matter.
What is getting me is the inconsistency between input from os-dir and the other two.
Did you consider opening a case with tech support? When file-info:full-pathname does not include the drive letter on Windows dependent on how the propath is defined – that may might deserve their attention…
I've considered it, but having read the documentation and seeing that there is search()-like behavior in file-info I wasn't previously aware of, I strongly suspect that the answer is going to be "behaving as designed".
Just out of interest, can you see what the following line of code returns?
System.IO.Path:GetFullPath(chFullPath)
That does of course include the drive letter. ;-)
Yes ... but it is Windows specific, of course.
As are drive letters
Yes, but the point is that I want the utility to work on either Windows or *nix. If I sprinkle System,IO.Path around the application, the application will be platform specific.
Read my yesterdays advice… You don’t sprinkle it around. You encapsulate it in a single class. And you have another version of a class that implements the same interface for Unix.
Now you just need to make a decision:
-
Clean code and get over your windows hating and encapsulate that API call as you’d recommend others to do
- Not that clean code but the warm feel of belonging to the group of windows haters
It doesn't have to do with hating Windows ... although there certainly are reasons enough to do so. It has to do with wanting consistent results and, having the problem that the tool will necessarily be obtaining file paths in multiple ways and these need to produce comparable results. The cleanest solution I have seen here is the idea of simply putting a top level test for the OS and checking that the propath has drive letters since, if nothing else, that is a one-time setup annoyance, but I'm not happy about it since there is nothing wrong with Windows propaths that don't include drive letters. Of course, given that Windows doesn't even observe the propath environment variable, perhaps I should just throw up my hands and accept that one has to do silly things to get around Windows behaviors at times.
But it seems that you need to pick one:
Don’t care about the OS or implement special handling for the OS that the majority of Progress development tools run exclusively on.
Given the nature of the tool, it may or may not be run on the platform that the developer is using. In an environment with Windows development and *nix production for the DB, it is likely to be desirable to run the tool on the *nix platform so that the DB is equally available to all developers. But, one would hardly want to require that.
Clearly, simply requiring the propath to contain drive letters is a workable solution and the top level test to enforce that is simple enough to create. But, doesn't it bother you that if one is asking multiple language features for the full path of a file that one consistently includes the drive letters on Windows while the other does not? As I said, I am sure that if I ask about this that the language in file-info which parallels search() will mean that I will be told "performing as designed", but that doesn't keep me from thinking it is wrong and hoping there is something I have overlooked .... but it is appearing that I haven't.
the underlying windows api's we use may also be "performing as designed".
OK, now I'm really going nuts. In test programs, input from os-dir consistently includes the drive letter. In the context of the tool, it does not. Nothing I have tried can explain the difference.
OK, finally found that. If the input from os-dir does not include the drive letter, the full path returned also doesn't and vice versa. The same appears to apply to file-info, i.e., if the file-name has the drive letter, the full-pathname does and otherwise not. So, it isn't the propath, but what is passed in.
It seems that if you have a relative path starting with ".\" or "..\" then file-info returns the full path including the drive letter. But, if the file path begins like "\work\IS\..." then the drive letter is not included.
Maybe a simple solution would be to check if the full-pathname begins with "\" (and NOT with "\\") and if so, add the drive letter (= the drive of the working directory) in front of it?
Add which drive letter? The utilities should be telling me where the file is, not I telling them.
Drive letter of the working directory (using e.g. FILE-INFO:FILE-NAME = "."). But, you are of course right, it shouldn't be programmer's task to figure out the drive letter.
resistance is futile ...
looks like your best bet is to use System.IO.Path:GetFullPath(chFullPath)
I have taken the path of telling the user of the tool that they need to create directory lists like Propath with explicit drive letters when in Windows. This is a minor annoyance at setup, but makes the whole problem go away with the code then being platform independent.